On Sun, 29 Jul 2007, Matthew L Foster wrote: > > Is it possible for git and/or gitweb to know that commits X and Y are descendents of merge C and > use the time merge C happened locally for both instead of using the time commits X and Y were > created? 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 - 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
