Re: [PATCH] [RFD] Add repoid identifier to commit
- From
Sean <seanlkml@sympatico.ca>
- Date
- May 12, 2005, 19:35 UTC
- Message-ID
- <1510.10.10.10.24.1115926514.squirrel@linux1>
- In-Reply-To
- <7vy8akfdss.fsf@assigned-by-dhcp.cox.net>
On Thu, May 12, 2005 3:24 pm, Junio C Hamano said:
> That would not work if (1) you are using SHA1_FILE_DIRECTORY > mechanism to share object pool for multiple trees, or (2) you > git-*-pull'ed but did not merge for some time. The file > timestamps are the time of download but we want the time of
Surely you mean "GIT_OBJECT_DIRECTORY" <g> and you're right, if the local object is shared amongst several trees you'd have to store the timestamp separately. However, as for your second case, the merge process could set the timestamp on the file so that one really isn't a problem. I for one, would like the option to use this method when its appropriate, although I agree you'd need a timestamp-database for other situations.
Show 5 quoted lines
> merge for this applicaton. Also, that approach captures only > half the information necessary. The other half you missed is > "which ones are foreign commits from this tree's point of view", > and as you described that is something you cannot tell just by > looking at the order of parents in commit objects.
Right, but we're not talking about identifying foreign commits anymore! The point is just to list multiple parents in the correct "local" order. The timestamp information _is_ enough to identify the proper order for local viewing. And this has the very nice feature that it works for branches made in the same repository, where the repoid proposal would fail.
Show 7 quoted lines
> S> So it seems, that rather than a repository identifier, we > S> need each repository to record the time of each local commit. > S> Either in a separate file or just using the object file > S> timestamps directly. > > I think we are in agreement here, except that object file > timestamps is not something you can use.
You can use it, just not in every situation.
Sean