Re: unmerging feature branches

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Oct 31, 2007, 21:34 UTC
Message-ID: <alpine.LFD.0.999.0710311429080.3342@woody.linux-foundation.org>
In-Reply-To: <20071031211658.GA5430@inspiron>

On Wed, 31 Oct 2007, Alejandro Martinez Ruiz wrote:

Show 5 quoted lines

> 
> So how about an "undo" command or a switch for revert with a special
> meaning like "hey, this one is a nice commit, but it ain't ready yet,
> I'd like you to ignore I ever committed the thing when merging or
> rebasing again, thanks"?

There is only one undo command, and that one we've had since day 1:

	git reset --hard <state-you-want-to-go-back-to>

will happily undo anything at all (including an earlier undo, apart from uncommitted dirty tree state, which is gone, gone, gone after that "undo" and can not be retrieved).

That's the only real true "undo" with clear semantics - it actually does undo the whole history.

But the kind of "undo" you wish for is not really possible. It implies a level of semantics that the system just doesn't know or care about. It also implies that anything else than the shape of history would matter for merging, which is just anathema to everything that makes git good in the first place.

That said, in practice, this really seldom does come up. You can often use "git revert" as that kind of undo, and when you later do the merge, and the other side has fixed up the code, it's (a) likely going to be obvious in the conflicts and (b) if the fixes were to infrastructure and you had no conflicts, it's really easy to just revert the revert too!

			Linus