Re: Question about 'branch -d' safety

[Will Palmer <wmpalmer@gmail.com>]

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.

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 ;)
 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
 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.


>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 (ie, ease of finding the "lost" commit)
b) the reflog (which I think is utterly lost on delete at the moment?).
Both of these are often useless after a delete, but sometimes wanted.
 2) A straightforward way to restore information which has not been lost
(again, perhaps there is disagreement as to whether this already exists)
 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)
 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)

Did I miss anything?

-- 
-- Will