Re: unmerging feature branches

From: martin f krafft <madduck@madduck.net>
Date: Oct 23, 2007, 17:16 UTC
Message-ID: <20071023171611.GA18783@piper.oerlikon.madduck.net>
In-Reply-To: <alpine.LFD.0.999.0710230922240.30120@woody.linux-foundation.org>

also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.10.23.1850 +0200]:

Show 9 quoted lines

> First off, let me say that to some degree, what you ask for is not 
> possible. Why?
> 
> Since you have pushed out the stuff, and don't want to rewrite history 
> (which would result in trouble for down-streams - and I heartily approve), 
> whatever you do will always have that merge in the commit history.
> 
> And that means that while you can certainly undo the *data* that the merge 
> brought in, git will always know that you already merged up that branch.

This is precisely what I meant, sorry for not being clear. This is what git-revert does...

> So you can revert the data, but then if you want to get it back, you'll 
> need to revert the revert - you cannot just merge the branch again.

Ouch!

Show 5 quoted lines

> 	# You now have the "temporary" branch that contains just the
> 	# diff that effectively undoes that one merge. Go back to the
> 	# tip of your development, and cherry-pick it to get git to
> 	# help you do a good job merging it with all the subsequent
> 	# development

Ah, that's a good idea.

Thanks for your time and input!

PS: this question of mine came out of a discussion on using Git for
Debian packaging: what happens when we actually need to remove
a feature from one package to the next:
  http://lists.madduck.net/pipermail/vcs-pkg/2007-October/000059.html

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
#define emacs eighty megabytes and constantly swapping.
 
spamtraps: madduck.bogus@madduck.net