Re: [PATCH 2/2] branch: protect local upstreams from -d

[Junio C Hamano <gitster@pobox.com>]

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> A local branch may be fully merged into its own upstream while still
> serving as the base of a surviving stacked branch. Deleting it with
> "git branch -d" then leaves the surviving branch with a missing
> upstream.
>
> Use the existing stacked-branch protection after checking every
> requested deletion. This makes multi-branch deletion independent of
> argument order: a branch that fails its safety check remains available
> to protect its upstream. Allow -D to override the protection, and allow
> a complete stack to be deleted together.

It may be a good thing to optionally be able to do this, but
changing the long-established semantics of what the '-d' option
means would lead to serious breakage to the end-user workflows
people depend on, I am afraid, and...

> -test_expect_success 'branch -d other@{u}' '
> +test_expect_success 'branch -D other@{u}' '
>  	git checkout -t -b other main &&
> -	git branch -d @{u} &&
> +	git branch -D @{u} &&
>  	git for-each-ref refs/heads/main >actual &&
>  	test_must_be_empty actual
>  '

... having to adjust the test command sequence like this is a very
clear illustration of why it is not a safe thing to do.  Our change
just broke what the user wanted to do, i.e., removing the branch
@{u}, which they have happily been doing with '-d' while guarded by
the original safety feature '-d' already had.  Now they have to use
'-D' to remove it unconditionally without safety -- that is not
exactly progress.  In addition, depending on the version of Git, our
change makes 'git branch -d' behave differently, making it less
predictable.

And no, a configuration variable to tweak the behaviour of '-d' is
unwelcome here; it would make the behavior of the command and the
option even less predictable.