Re: Question about 'branch -d' safety

On Mon, 2010-07-19 at 01:19 +0200, Jakub Narebski wrote:

On Sun, 18 Jul 2010, Will Palmer wrote:

quoted

On Sun, 2010-07-18 at 13:55 +0200, Jakub Narebski wrote:
having any kind of suffix like refs~/heads~/bar is just asking for
someone to delete a branch twice.

I don't understand what you wanted to say here.  Using the

  $GIT_DIR/logs/refs~/heads~/bar

(and not $GIT_DIR/refs~/heads~/bar) as a reflog for a deleted branch
'bar' is an implementation detail.  You wouldn't see refs~/heads~/bar
when listing branches... well, perhaps 'git branch --list-deleted'
could be used to list deleted branches (by scanning for reflogs).
 

git branch -d integration
# git renames refs/heads/integration to refs~/heads~/integration
git co -b integration sometopic
# git creates refs/heads/integration, unrelated to the old one
(do some work)
(merge into the main branch)
git branch -d integration

Now what?
git renames refs/heads/integration to ... what?
- does the old refs~/heads~/integration get clobbered? If that's ever
okay, why are we even having this discussion?
- does the "old reflog" stuff get combined? If that's ever okay, why
even have an extra reflog, instead of just using the reflog we already
have?
- do we move everything else one step down, so refs~/heads~/integration
becomes refs~2/heads~2/integration? (ie: 2-dimensional reflog, which
sounds rather too fancy, to me)


-- 
-- Will