Re: Subversion-style incrementing revision numbers

From: Petr Baudis <pasky@suse.cz>
Date: Sep 19, 2006, 22:00 UTC
Message-ID: <20060919220011.GD8259@pasky.or.cz>
In-Reply-To: <Pine.LNX.4.62.0609191525490.9752@joeldicepc.ecovate.com>

Dear diary, on Tue, Sep 19, 2006 at 11:42:20PM CEST, I got a letter where Joel Dice <dicej@mailsnare.net> said that...

Show 12 quoted lines

> On Tue, 19 Sep 2006, Petr Baudis wrote:
> >Also, multiple IRNs could refer to a single real commit if you do e.g.
> >cg-admin-uncommit, since revlog logs revision updates, not new revisions
> >created. This may or may not be considered a good thing. If you rather
> >want to just create a new IRN at commit object creation time, also note
> >that some tools _might_ validly create commit objects and then throw
> >them away, which would generate non-sensical (and after prune, invalid)
> >IRNs.
> 
> I'm not too worried about cg-admin-uncommit or git-reset, since the IRN 
> feature is intended mainly for shared repositories.  I would suggest that 
> such commands simply be disallowed for such repositories.

  What kind of shared repositories? You yourself said that IRNs are
local to a repository, thus they are not preserved over cloning/fetching
from a repository, if you mean that.

> The problem of temporary commits certainly needs to be addressed.  In this 
> case, may I assume nothing under $GIT_DIR/refs is ever modified?  If so, 
> perhaps I could somehow hook into the git-update-ref step.  Is that what 
> the revlog code does?

  Yes. But not every commit is always recorded to something in refs/.
The simplest case is if you fetch from a remote repository (or push to
your repository), only the latest commit is recorded.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam