Re: What's cooking in git.git (topics)

From: Shawn Pearce <spearce@spearce.org>
Date: Dec 18, 2006, 09:33 UTC
Message-ID: <20061218093339.GB9727@spearce.org>
In-Reply-To: <200612180917.46214.andyparkins@gmail.com>

Andy Parkins <andyparkins@gmail.com> wrote:

Show 7 quoted lines

> I'm daft.  I've realised, pruning doesn't remove the ref, it removes one of 
> the hashes in the reflog.  I withdraw my comment.
> 
> I'd imagined it' as the opposite of a creation.
> 
> 000000 abcdef  branch created
> abcdef 000000  branch deleted

Except that branch deletion also deletes the reflog. So yes, we could log it as you show above, but right after we appended it to the log we'd delete the log anyway. :-)

The immediate log deletion is necessary to support something like:

	git branch foo
	git branch -d foo
	git branch foo/bar

as foo switches from being a file to a directory, which means that .git/logs/refs/heads/foo also needs to switch from being a file to being a directory.

The only way to fix the above situation is to make the reflog a single log for the entire repository, rather than one log per ref. This may cause locking problems for us as we need to lock not only the ref but also the repository-wide reflog lock. Note that right now the reflog is also protected by the ref lock itself, killing two birds with one stone. :-)