Re: Subversion-style incrementing revision numbers

[Petr Baudis <pasky@suse.cz>]

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