Re: unmerging feature branches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Wed, 31 Oct 2007, Alejandro Martinez Ruiz wrote:
> 
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux