Re: Question about 'branch -d' safety

On Sun, 18 Jul 2010, Jonathan Nieder wrote:

On the other hand, there are some hard policy questions:

 * Should pre-deletion commits expire more quickly?

I think you should have an option to configure expiration of reflogs
of deleted branches separately, just like there is currently a way to
configure longer expiration time of HEAD reflog, or for stash.

With this on low disk size / low quota machine you would be able to
turn this feature (this protection) off.
 

 * What happens when you rename one branch to take on the
   name of a deleted one?

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

 * What happens when you create a new branch to take the
   place of a deleted one?

It would either be the same as above, or it would get reflog from 
deleted branch.  The former would be better, if there was in git some 
command to resurrect deleted branch.
 

 * Should refs outside the refs/heads/ namespace
   (like refs/bisect/ and refs/original/) use the same
   policy as refs/heads/?

I guess that expire policy should be configured per ref, or per 
namespace.  Perhaps gc.<pattern>.reflogExpireDeleted ?  But then
gc.<pattern>.reflogExpireUnreachableDeleted would be long name, as
if compensating for two-letter section name ;-)

-- 
Jakub Narebski
Poland