Re: Question about 'branch -d' safety

Clemens Buchacher wrote:

I am not sure how to proceed with this.

Maybe: try out the patch locally for a while.  Such an experiment
would make it easier to see whether this feature because indispensible
and how the details should be to work best in practice.

But be careful!  Once you have learned to rely on the
master@{before.deletion} facility, you might end up trigger-happy with
‘branch -d’ and get into trouble when faced with copies of git without
the safety valve.

To respond to your philosophical points:

+ safety net

I consider it very good that git is willing to _lose_ information
rather than get overloaded with it.  On this laptop, if I try

 linux$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
 linux$ git checkout FETCH_HEAD
        ... hack away ...

in a repository with quickly-expiring HEAD reflog, then the pack size
stays barely comfortable.  Perhaps a person that regularly builds
short-lived topic branches off such an unstable branch would be
similarly grateful that the objects do not need to stay long.

So: this aspect is a minus for me.

+ less dependant on git branch -d

I have not find “log -g” too useful for protection against fat-finger
accidents (“fsck --lost-found” and “push” take care of that) so it
seems odd to see safety touted as its main benefit.  What the reflog
and HEAD@{4} syntax prevent me from losing is a train of thought.
After deleting a branch I have just merged, if I start to wonder about
“that branch I just deleted”, reading reflog entries to find it
is the last thing I want to be doing.

In other words, it is not enough that “branch -d” be safe.  Yes, the
old branch tip is an ancestor of origin/master, but that does not
bring me much closer to finding it.  To be able to refer to
master@{5.minutes.ago} directly would be much more convenient.

+.

+ automatically prune remote tracking branches

I’m not comfortable with the idea yet.

0.

- only a convenience
- implementation complexity

Your implementation seemed simple.  I don’t think implementation
complexity is the fatal flaw.

0.

- user interface complexity

Keeping the reflog would arguably make the syntax for specifying
revisions more consistent.

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

 * Should pre-deletion commits expire more quickly?

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

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

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

0.