Re: Question about 'branch -d' safety

[Jakub Narebski <jnareb@gmail.com>]

On Sun, 18 Jul 2010, Will Palmer wrote:
> On Sun, 2010-07-18 at 13:55 +0200, Jakub Narebski wrote:
> > On Sun, 18 Jul 2010, Jonathan Nieder wrote:

> > The same as with D/F conflict.  If you rename branch 'foo' to 'bar',
> > you also rename its reflog, but logs/refs/heads/bar would not conflict
> > with reflog for deleted branch, logs/refs~/heads~/bar (if you had 
> > deleted branch 'bar').
> 
> 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).
 
> Regardless of whether or not it would be difficult to implement, I think
> the ideal (for me) would be:
>
> 1) existing syntax should work as-is. I like my reflog and don't want
>    people screwing with it ;)

Nobody proposes anything different.

> 2) new syntax should be added for "some/ref@{..even if it's been
>    renamed or deleted..}", perhaps an entry in the reflog which points
>    to the "old name" / fact that it's been resurrected, for
>    moves/resurrections 

Here comes hard part: naming ;-)  Or rather chosing API for refering to
deleted branches and their reflogs.

> 3) getting rid of something "for real" should be a simple command away.
>    If the steps are getting too numerous (delete, expire, /then/ prune?
>    Anything else?) then perhaps we just need a "git shred <ref>" which
>    takes care of listing out what will be involved, giving you lots of
>    chances to abort, etc, and which maybe is less of a sledgehammer than
>    the current method.

Depending on default safety net, i.e. on default expire time for
reflogs of deleted branches (perhaps just 1 day, or at most 7 days?),
it could be as simple as 'git gc'.

> 
> From the discussion, I think the things we agree that we all want are:
>
> 1) For git to not lose data by accident. Maybe there is disagreement
>    as to whether or not this already happens. I think the information
>    currently lost is: 
>      a) the name (i.e. ease of finding the "lost" commit)

Usually HEAD reflog would be enough at least when "safely" deleting
with 'git branch -d' (and not '-D'), but it is not the case after
relaxing rules a bit.
      
>      b) the reflog (which I think is utterly lost on delete at the
>         moment?). 

Yes it is.  So even if you manage to resurrect branch thanks to HEAD
reflog or tools like contrib/git-resurrect.sh, the data in reflog would
be lost.

> Both of these are often useless after a delete, but sometimes wanted.

True.

> 2) A straightforward way to restore information which has not been
>    lost (again, perhaps there is disagreement as to whether this
>    already exists)

'git branch <old name> <old SHA-1>' is good, though it is perhaps not
quite that straighforward.

> 3) A way to distinguish between "the reflog entries of a deleted ref
>    with the same name as our new ref" and "the new ref's entries"
>    (these are the "attic" discussions, etc) (not applicable to the
>    current situation)

This is a problem of API design.  Probably overloading @{...} yet again
(@{<n>}, @{<time>}, @{-<n>}, @{upstream}), though using '~' as suffix
(or ~@{<n>} when refering to reflog of deleted branch) could be
a solution.

> 4) A way to really get rid of things which are no longer wanted. This
>    should be straightforward and have sane defaults so that, as mentioned,
>    adding then removing the wrong remote doesn't leave you with an extra
>    repos' worth of data for the next six months. (obviously this one
>    already exists)

Well, 'git -c gc.reflogexpire=0 -c gc.reflogexpireunreachable=0 gc --prune=now'
is a bit mouthfull ;-)

> 
> Did I miss anything?

-- 
Jakub Narebski
Poland