Re: [RFH] revision limiting sometimes ignored

From: Karl Hasselström <kha@treskal.com>
Date: Feb 6, 2008, 08:16 UTC
Message-ID: <20080206081641.GA19876@diana.vm.bytemark.co.uk>
In-Reply-To: <7vwspi4poh.fsf@gitster.siamese.dyndns.org>

On 2008-02-05 21:30:38 -0800, Junio C Hamano wrote:

Show 12 quoted lines

> I really wish this was still May 2005. Then I (actually, you) could
> just decree:
>
>       Sorry guys, but you all need to run convert-objects to update
>       your repo. What it does is to add a "generation" header to
>       each and every commit object. Then upgrade your git to this
>       version, that maintains the "generation" number, defined as:
>
>         (1) parentless commit gets generation #0;
>
>         (2) otherwise the generation number of a commit is max(its
>             parents' generation number)+1.

Would it be possible to start adding a generation header to new commits, so that this problem (and others -- I recall hearing this same wish a year or two ago regarding some gitk toposorting issue) will eventually fade away?

For old commits without an embedded generation number, git could conceivably compute their generation number once and store them in a (local) file somewhere.

I expect that this has been considered already, and I'd be interested in hearing why it doesn't work, if you (or someone else) have some time to waste. :-)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle