Re: Subversion-style incrementing revision numbers

From: Shawn Pearce <spearce@spearce.org>
Date: Sep 19, 2006, 22:39 UTC
Message-ID: <20060919223905.GE11601@spearce.org>
In-Reply-To: <Pine.LNX.4.62.0609191525490.9752@joeldicepc.ecovate.com>

Joel Dice <dicej@mailsnare.net> wrote:

Show 8 quoted lines

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

$GIT_DIR/refs is always modified. Its probably the most heavily modified part of a GIT_DIR, aside from the index. Simply because the ref files must be modified every time a commit, fetch or merge completes. Its also a directory you don't want to delete; I once did an `rm -rf .git/refs` in a repository with a many branches. That was no fun to recover.

git-update-ref is used by pretty much all non-C code to update a ref file. The APIs it calls invoke the reflog code to record the update being made to the ref if the user has enabled logging on that ref (not all users want all refs logged apparently). I don't think its a great idea to plug more complex logic into that part of the system. The reflog code already made it more complex then it needed to be; Linus apparently just found out how heavily we use static buffers down there...

-- 
Shawn.