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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andy Parkins <andyparkins@xxxxxxxxx> wrote:
> 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.  :-)

-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]