also sprach Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> [2007.10.23.1940 +0200]:
> > > 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.
> 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.
[...]
> 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?
> 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.
> 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@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
