Re: merge time

On Sun, 29 Jul 2007, Matthew L Foster wrote:

The data exists, but there is nothing to make "C" special. Or rather, the two "sides" of C that got merged are 100% equivalent.

You'd probably have to read a lot of old emails (from very early in the git process) to see the whole picture. But the fact is, in a distributed environment, the parents to a merge C are totally equivalent.

So thus when you talk about merge new code into an old repository (and giving those new commits the same date as the merge), that is actually technically 100% equivalent to merging the other way around, and thus you'd have to give all the *old* commits that new merge date too!

And yes, this does happen. It's not at all the case that I always merge other peoples tree: quite often other people merge _my_ tree, and the end result really is that they pulled in the changes _I_ had done.

[ Side note: we do actually try to avoid that, just because it makes the 
  history harder to read, and the resulting criss-cross merges, while 
  technically not a problem at all, can confuse people. But when I say 
  "try to avoid that", I mean just that: it's not a hard rule, and the 
  reverse merging _does_ happen, and there are good reasons for why it 
  happens.

  So *most* of the time, the history looks like it's me merging other 
  peoples code, but then every once in a while, the merge is done by the 
  other side. And from a pure technical standpoint, the two cases are 
  totally equivalent, and git is very fundamentally designed to *not* 
  care. ]

So there is never really any way to say that one side of a merge is special. The closest you can get is saying

 - the first parent is special.

   This is "see merges from the viewpoint of the merger", but as 
   mentioned, the person who actually did the merge isn't necessarily me, 
   so while this is a totally self-consistent view, it's not really the 
   view you are looking for.

   You can get some of this view by using "git log --first-parent", which 
   basically follows commits preferentially using the first parent, and 
   thus "prefers" history as seen by whoever did the merge.

or

 - the *local* repository is special (but this is a purely repository- 
   local viewpoint).

   This is what "reflogs" give you, and what "git log -g" shows. It shows 
   the history not as it pertains to parenthood, but as the tip-of-tree 
   has changed in *that* repository.

but neither of those are really "sensible" (the first one will give *wildly* different results if the repository is ever "switched around" because it's not merged by a single person, and the second one is a purely local thing and has no meaning for anybody else.

The fact is, distributed history isn't one-dimensional. You *cannot* linearize it as some one-dimensional time. Impossible. Any system that tries is broken. Fundamentally.

		Linus