"Harald Nordgren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> From: Harald Nordgren <haraldnordgren@xxxxxxxxx>
>
> 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.