On Tue, 23 Oct 2007, martin f krafft wrote: > > 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 This is still true. Git never looks at individual commits when merging, it looks at the *history*. So it does look at the commits only in the sense that it uses the "shape" of the history (which is obviously built up from many individual commits!) but it never looks at any individual commit per se. And the behaviour of "git revert" comes *exactly* from the fact that git never even bothers to look at the revert as a "revert" of history! A revert is a normal data commit, and has absolutely zero impact on history itself. So the reason a merge will never give "back" the data over a revert is that the data was already merged, since the history itself didn't change! > I master merged branch Foo, then reverted a commit introduced by > Foo, and then Foo would be re-merged, the content *will* differ. No. If you re-merge Foo, nothing at all happens! You're already merged. It's a no-op. If Foo has had *new* commits in the meantime, those new commits will show up, of course, but the old commits have absolutely zero effect, because they will be part of the common history. > 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? No, that's absolutely incorrect. You didn't understand what I meant. Git merge doesn't look at the revert at all, except (indorectly) when it builds up the history and it passes over it in order to find the common base for the history. > > 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. git-rebase is special. It really does look at each commit (obviously), since it needs to *move* each commit. So git-rebase has nothing at all to do with merges. They have similar behaviour (quite often the end result is identical in the *data* - at least that's the good case), but at the same time they are very different indeed. Git-merge *only* cares about the "shape of the history" (to find the common commit(s) to use as a merge base) and the actual data, while "git rebase" actually goes one commit at a time. > How can rebase know that the commit already existed when you're > saying above that it's about patch X, *not* the same commit? Git-rebase looks at the patch itself, using the "patch fingerprint", and when it goes through each commit, it skips commits that have already been applied. See the man-pages for "git-cherry" and "git-patch-id". 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
