Re: Subversion-style incrementing revision numbers

[Joel Dice <dicej@mailsnare.net>]

On Wed, 20 Sep 2006, Petr Baudis wrote:

> 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 scenario I envision is several developers, each with a clone of a 
shared repository.  The clones would not have IRNs turned on, only the 
shared repository.  So, when I do a "git push", I get an IRN back, and I 
am not confused, because I know that IRN only applies to the shared 
repository.  Then, when I mark a Bugzilla bug as fixed and attach the IRN 
to it, everybody knows that IRN refers to the shared repository.  After 
all, I wouldn't mark the bug fixed if I had only committed it to my own 
private repository.

I could also turn on IRNs on my clone if I really wanted, but not if I 
thought it would confuse myself or others.

>> 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.

That's what I figured.  I should be able to walk the commit chain to get 
at all the commits in a push or fetch, right?

  - Joel