Re: [PATCH] Additional merge-base tests

> Hi,
> 
> On Tue, 4 Jul 2006, A Large Angry SCM wrote:
> 
>> Johannes Schindelin wrote:
>>> Hi,
>>>
>>> On Tue, 4 Jul 2006, Junio C Hamano wrote:
>>>
>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>>
>>>>> We could introduce a time.maximumSkew variable, and just walk only that
>>>>> much further when traversing the commits.
>>>> We could have had "commit generation number" in the commit
>>>> object header, and use that instead of commit timestamps for
>>>> these traversal purposes.  The generation number for a commit is
>>>> defined to be max(generation number of its parents)+1 and we
>>>> prime the recursive this definition by defining the generation
>>>> number for the root commit to be one.
>>> Are you really, really sure this is a remedy? I, for one, am quite sure of
>>> the opposite. What you propose is just another time scale, only this time,
>>> it is not universally true (not even minus local incompetence to keep the
>>> clock accurate).
>> It works[*] and it does what using the timestamp was trying to do. Namely,
>> work from "more recent" (or "closer") commits toward "older" (or "farther")
>> commits until you've gone past the point you care about.
>>
>> It's a little late to be changing the structure of a commit and you'd have to
>> deal with some size/scale issues, but it's do-able. A better idea may be to
>> generate and keep the generation number on a per repository basis, and you'd
>> be able to work around changing grafts.
> 
> Like, inside the cache? I dunno. IMHO it is way too late to change the 
> structure of a commit in that particular manner, _plus_ you would get 
> overflow issues.

>> [*] Grafts do _really_ nasty things to this. Just like clock skew does now.
> 
> Grafts can do much nastier things to you, for example having a circular 
> history. _But_ they cannot do that nasty thing outside of your repo. Clock 
> skews can.