[ipxe-devel] Can't revert 6324bd commit

Shao Miller sha0.miller at gmail.com
Wed Dec 5 01:17:21 UTC 2012

After your failed reversion, 'git status' shows you which files have

If you want to keep asking 'git' questions, such as how to find which
commits depend on a commit, I think you'll learn more:

  By learning about 'git': Reading about it, asking in 'git' forums, etc.

instead of asking the iPXE mailing-list about 'git'.  _Please_ consider

Having said that, if you perform a 'git rebase -i' all the way back to
before the "problem" commit, then delete the "problem" commit from the list
of commits that will be re-applied, you can deal with each dependency issue
as it arises.  I'd suggest learning about 'git rebase -i'.

That won't help you unless you can understand the conflicts...  So you'll
need to know at least git, and possibly C.  If you learn more about git, you
might find a way to automate some of this.  In general, in order to rewrite
history, you probably have to know how and what to write.

- Shao Miller

From: hai wu [mailto:haiwu.us at gmail.com] 
Sent: Tuesday, December 04, 2012 19:33
To: Thomas Miletich
Cc: Shao Miller; <ipxe-devel at lists.ipxe.org>
Subject: Re: [ipxe-devel] Can't revert 6324bd commit

Thanks Guys. There's new firmware for the NIC, and yes I agree that we
probably need to test again with latest release some time later. I just want
to have this option available in case some newer commit like this one would
causing additional issues and we have to revert that one. 

How difficult to find all the dependencies/commits on one commit I need to
revert in git? I assume those should be reverted if "git revert" is done in
a certain order? 
On Tue, Dec 4, 2012 at 5:53 PM, Thomas Miletich <thomas.miletich at gmail.com>
What Shao was trying to say is that this is sometimes impossible.

Code is built and extended on top of earlier code, with the
expectation of that code still being there to function. You can't
always remove some of the older code while still expecting the newer
code to work.

As a more specific example imagine this:
There is a commit that introduces IPv4 support to iPXE. Then there's
another commit that adds TCP support to iPXE while utilizing the
earlier IPv4 code. Then there's a third commit adding HTTP support
which in turn requires the TCP code from the previous commit.

Now if you try to revert the code that added IPv4 support obviously
the TCP and HTTP support will break also.

In your case some of the code that came after 6324bd needs the code
added in 6324bd to be in place. You can't revert 6324bd alone.

On another note reverting 6324bd is only a workaround and should not
actually be required. Is there a new firmware version available for
that card?


On Wed, Dec 5, 2012 at 12:30 AM, Hai Wu <haiwu.us at gmail.com> wrote:
> Yes, it would be nice to be able to revert one commit in ipxe, while
there's no confirmed solution available at the time. This would apply to all
commits in ipxe code, if that commit turns out to cause issue. There's nice
instruction in ipxe website on how to identify which commit is causing issue
using git bisect, but there's no instruction on how to revert that commit.
> Sent from my iPod
> On Dec 4, 2012, at 5:10 PM, "Shao Miller" <sha0.miller at gmail.com> wrote:
>> This seems like a 'git' question, to me.
>> Are you asking for someone to provide you with instructions for dealing
>> the conflicts that you've run into while trying to revert a commit that's
>> mainline iPXE?  If so, this might involve reviewing all of the code
>> involved, editing files, changing code, saving the changes, resolving the
>> conflicts.
>> - Shao Miller
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

More information about the ipxe-devel mailing list