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

From: Thomas Gleixner <tglx@linutronix.de>
Date: May 12, 2005, 20:47 UTC
Message-ID: <1115930845.11872.79.camel@tglx>
In-Reply-To: <7vvf5ogxdu.fsf@assigned-by-dhcp.cox.net>

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.

Show 8 quoted lines

> 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

Show 7 quoted lines

> 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

Show 6 quoted lines

> 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