Linus Torvalds <torvalds@xxxxxxxx> writes:
> It's entirely possible that the proper way to do branch deletion with
> packed branches is to simply re-pack without the old branch, rather than
> the negative branch model. I couldn't really decide.
After playing with branch deletion issues for some time, I
started to think it would be a lot simpler if we do not mark
a deleted branch with 0{40}.
I started rewriting git-branch in C, mostly reusing Kristian
Høgsberg's patch but taking care of the reflog issue still left
in the original thread:
Subject: [PATCH] branch as a builtin (again)
Date: Sun, 20 Aug 2006 17:22:18 -0400
Message-ID: <59ad55d30608201422h4a6d40f7y7782212637380438@xxxxxxxxxxxxxx>
We need to take care of two funny cases around packed-ref in
lock_ref_sha1_basic() where a creation of a new ref takes
place. It needs to deal with two issues.
* We should not allow frotz branch to be created when
frotz/nitfol branch already exists (packed and pruned).
Being able to create .git/refs/heads/frotz.lock file and
being able to rename it to .git/refs/heads/frotz is not
enough. The other way around has the same problem. So we
would need to have a for_each_ref() to check if the ref being
created is a prefix of an existing one or there is an
existing one that is a prefix of the one being created.
* When creating frotz branch, there may be a leftover
.git/refs/heads/frotz/ directory on the filesystem. If the
directory is empty (or contains only empty subdirectories),
we can rmdir recursively and make refs/heads/frotz file
there. Otherwise it means that a branch frotz/something
still exists there, but the above prefix check should have
taken care of it. So in practice we should always be able to
just do an equivalent of "rm -fr .git/refs/heads/frotz" when
creating a frotz branch.
But the latter falls apart if we use 0{40} convention to mark a
deleted branch. Removing .git/refs/heads/frotz/nitfol file which
has 0{40} and creating .git/refs/heads/frotz file resurrects
frotz/nitfol branch that is still packed. Not allowing frotz
branch to be created only because we had deleted frotz/nitfol
previously is not what we want either, so at that point we need
to repack without frotz/nitfol anyway.
Which makes me think that we would better repack when removing
any existing ref.
BTW, the second issue exists without packed ref; currently we
cannot do
git branch foo/bar
git branch -d foo/bar
git branch foo
-
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