Re: Question about 'branch -d' safety

[Will Palmer <wmpalmer@gmail.com>]

On Mon, 2010-07-19 at 01:19 +0200, Jakub Narebski wrote:
> On Sun, 18 Jul 2010, Will Palmer wrote:
> > 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