Re: Question about 'branch -d' safety

From: Will Palmer <wmpalmer@gmail.com>
Date: Jul 19, 2010, 07:12 UTC
Message-ID: <1279523523.3077.8.camel@dreddbeard>
In-Reply-To: <201007190119.04873.jnareb@gmail.com>

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

Show 14 quoted lines

> 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