Re: Question about 'branch -d' safety

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 19, 2010, 20:40 UTC
Message-ID: <201007192240.38681.jnareb@gmail.com>
In-Reply-To: <1279568744.3009.14.camel@dreddbeard>

On Mon, 19 Jul 2010, Will Palmer wrote:

> On Mon, 2010-07-19 at 11:16 -0600, Joshua Jensen wrote:

Show 19 quoted lines

> > My brain has become muddied with all the ~2 stuff.  Explain again why it 
> > can't be as simple as this?
> ...snip...
> > git checkout -b integration HEAD@{1}  (or 8000000)
> > 
> > -Josh
> 
> Because:
>  1) The HEAD reflog is the wrong place to stick things which weren't
> recently checked-out.
>  and 2) the previous tip is currently the easiest-to-recover part of a
> deleted branch. What's lost is all the reflog data: order of states, and
> how they were reached.
> 
> However, I /do/ think it's as simple as "don't delete the reflog right
> away when you delete a branch", and other edge-cases and niceties in
> terms of UI (such as ref renaming, resurrection of refs for tracking
> unrelated data, etc) can be taken care of later, if there's actually a
> need for them.

There are at least two issues, which are not niceties, but requirements:
1.) not deleting reflog for 'foo' when deleting 'foo' branch blocks
    creating reflog for 'foo/bar' branch because of D/F conflict.
2.) there is issue of 'git branch -m bar foo', i.e. renaming some other
    branch to 'foo', a branch which has its own reflog.

But you are right in that "moving reflog to attic" can be postponed till needed.

-- 
Jakub Narebski
Poland