Re: unmerging feature branches

From: martin f krafft <madduck@madduck.net>
Date: Oct 23, 2007, 18:08 UTC
Message-ID: <20071023180825.GA20343@piper.oerlikon.madduck.net>
In-Reply-To: <alpine.LFD.0.999.0710231026011.30120@woody.linux-foundation.org>

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

Show 6 quoted lines

> > > 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!
> 
> Well, it's not necessarily "Ouch".

I said "ouch" only because I can foresee the confusion this may cause in collaborative package maintenance. One party merges the feature branch, another reverts it, and a third (or the first) wonders why the feature isn't present despite having merged the branch and must go through history to find the reverting commit, which is tied to the commit it reverts through nothing else than a log message, at best.

Show 5 quoted lines

> In other words, think of what happens when you merge some
> development branch, and then "git revert" a single commit from
> that branch - the exact same thing will happen - future merges of
> that branch will *not* re-do the commit, because you "already have
> it", and you reverted it after-the-fact.

[...]

Show 6 quoted lines

> When you revert the data from a merge, the exact same issue
> happens. A revert (whether done by "git revert", or by the
> sequence of events I described) very fundamentally undoes the
> *data* part, but leaves the history intact, and that has
> implications for future events that think about history - which is
> mostly "git merge", but there are other thigns too.

While this makes perfect sense, I am a bit thrown off now wrt two earlier posts by you (in another thread), where you said:

  In other words, git never looks at individual commits when trying
  to merge. It doesn't try to figure out what the "meaning" of the
  changes are, it purely looks at the content.
    -- http://marc.info/?l=git&m=119198488411957&w=2

  Yes, history is interesting for historical reasons, and to explain
  what the context was, but in many ways, history is exactly the
  *wrong* thing to use when it comes to merging. You should look at
  the end result, since people can - and do - come to the same
  result through different ways.
    -- http://marc.info/?l=git&m=119204501428555&w=2

I master merged branch Foo, then reverted a commit introduced by Foo, and then Foo would be re-merged, the content *will* differ. So Git *has to* look at the list of commits in history to properly handle reverts and *not* redo commits which have since been reverted.

Is this correct?

Show 6 quoted lines

> As an example of "other things" that take history into account, think 
> about something like "git rebase". It's not a merge, but it also takes 
> history into account in certain ways: in particular, it may be effectively 
> a "series of cherry-picks", but it actually takes the history of both 
> branches into account, and will not re-apply a patch that already exists 
> in the target history.

In the light of the discussion in (http://marc.info/?t=119198137100002&r=1&w=2), I am now completely confused. Or well, not confused, but I simply don't know anymore what Git does, and I thought I did.

Show 10 quoted lines

> What does that mean? Let's say that both histories contain a patch X (not 
> the same commit, but the same patch), but one history also contains the 
> revert of X. Again, the revert reverts the data, but it does *not* revert 
> the history, so when you cherry-pick all the stuff from the other branch, 
> X will *not* happen - even if it would apply cleanly, and even if a plain 
> "git cherry-pick" would have redone it!
> 
> Why? History, again. Because "git rebase" sees that the commit already 
> existed, it won't even try to apply it again, never mind that it could 
> have worked. The "revert" didn't undo the history, just the data.

How can rebase know that the commit already existed when you're saying above that it's about patch X, *not* the same commit?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"a woman begins by resisting a man's advances and ends by blocking
 his retreat."
                                                        -- oscar wilde
 
spamtraps: madduck.bogus@madduck.net