Johannes Schindelin wrote:
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@xxxxxx> 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.
Your don't need to change the commit object, create some repository
specific, local, auxiliary information. Overflow should not be a problem
until a path length to a root commit exceeds the machine word size.
But is it really worth the work? Does it help anything other than
merge-base?
[*] 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.
If grafts in your repository create a cycle, the misbehavior of
merge-base should be among the least of your concerns.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html