From: Junio C Hamano Date: Thu, 12 May 2005 17:35:57 GMT Subject: Re: [PATCH] [RFD] Add repoid identifier to commit Message-ID: <7vvf5ogxdu.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <1115884637.22180.277.camel@tglx> >>>>> "TG" == Thomas Gleixner writes: TG> Rn o TG> | \ TG> Rn-1 o | TG> | o Mn TG> | o Mn-1 TG> Rn-2 o / TG> Rn-3 o TG> The correct display looking at R is TG> Rn TG> Mn TG> Mn-1 TG> Rn-1 TG> Rn-2 TG> Rn-3 TG> Looking from M it is TG> Rn TG> Rn-1 TG> Rn-2 TG> Mn TG> Mn-2 TG> Rn-3 Thanks for a very clear explanation. The situation is intriguing in that both R and M after converging end up with exactly the same HEAD with the same set of objects but still would want to see history leading to the HEAD differently. I wonder what happens to a third person S, who pulls from both R and M. What does S see? Does the commit order observed by S depend on which one S pulls from first? That is, if S pulls from R then at that point Mn-1 and Mn comes after Rn-1 in S's history? And after that what hapens if S pulls from M (which is obviously a no-op except that it would update .git/refs/heads/M)? Does the history for S change? IIRC, Cogito lets you "track" upstream branches. When S starts tracking R, does it see R's history and when S starts tracking M its history view changes to that of M? Let's further say R and M are both based on another upstream L, and R and M have converged at this point. S has been tracking L and it merged from R and M. If S did not have any local modifications since L, then that is just two fast forward merges. What does the history look like to S? Which comes first---Mn or Rn-1? The answer to the above could be "the merge order history is per tree and not something to be exported or given away to other trees", in which case it may make sense from S's point of view that Mn and Rn-1 are compares solely based on their commit timestamps. You will get consistent history and switching which tree is being tracked would not change the history. Is the goal here to give the merge order history from R and M to S? If that is not needed, then you can record in an auxiliary file that is local to each tree the timestamp of when merge happened in that tree along with set of foreign commit objects, and teach rev-tree or rev-list to read from that auxiliary file and use that timestamp for foreign commit objects instead of commit time recorded in them when sorting by time is needed.