Re: [PATCH] [RFD] Add repoid identifier to commit

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 2005-05-12 at 10:35 -0700, Junio C Hamano wrote:
> 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.

Yes, thats what I wanted to achieve first hand with the repository id. I
think my first attempt is far from perfect and I agree with hpa on
having a .git/repoid file. 

> 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?

That's an interesting question. Of course, if you change the head you
see the tree from a different POV, but you can detect this when S pulls
from M after a pull from R. So the tool can ask the user, if he really
wants to change the commit order or not. You might even argue that they
could refuse to do the head change

> 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?

The goal from my side is to preserve the merge order history of R, M and
S in the individual way of commit order per repository, which includes
the merge order R->S, M->S or the other way round. See above

> 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.

As I said before timestamps can be a horrid source of information. Also
if you keep a list of commits merges and head forwards in timed order it
is simple to read the repository history, but in case of corruption you
have to reconstruct it manually. There is no way to do so with the
information available.

Repository id's can be lost, but are simple to replace as they are
recorded in the commit blob.

tglx