Re: Question about 'branch -d' safety

Clemens Buchacher wrote:

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:

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.

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.

+.

I’m not comfortable with the idea yet.

0.

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

0.

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.