Re: Thoughts on the "branch <b> is not fully merged" error of "git-branch -d"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07.09.24 18:59, Junio C Hamano wrote:
> Stefan Haller <lists@xxxxxxxxxxxxxxxx> writes:
> 
>> I frequently get this error when trying to delete a branch that was
>> merged on github, and the remote branch was deleted through github's UI too.
>>
>> When I then fetch and see that "git branch -v" shows it as "[gone]"), I
>> will want to delete it, but at that time it is pretty random which
>> branch I happen to have checked out. If it's some other unrelated branch
>> that I didn't rebase onto origin/main yet, or if it is main but I didn't
>> pull yet, then I get the error; but if I'm on main and I have pulled, or
>> I'm on an unrelated branch and I have rebased onto origin/main, then I
>> don't.
>>
>> This feels arbitrary to me. It would seem more useful to me if the error
>> only appeared if the branch is not contained in any of my local or
>> remote branches, because only then do I lose commits. Any thoughts on that?
> 
> I think we check against the @{upstream} as well as HEAD these days.

Yes I know, but in the example I gave, upstream is already gone (maybe I
should have added that I have fetch.prune set to true, that's why).

> Having said all that, I do not mind if somebody wanted to further
> extend builtin/branch.c:branch_merged() so that users can explicitly
> configure a set of reference branches.  "The 'master' and 'maint'
> are the integration branches that are used in this repository.
> Unless the history of a local branch is fully merged to one of
> these, 'git branch -d' of such a local branch will stop." may be a
> reasonable thing to do.

This makes sense to me (if you include the upstreams of master and maint
in that logic, because the local ones might not be up to date).

I should have added that I'm looking at all this from the perspective of
lazygit, again. Currently, lazygit tries "git branch -d" first, and if
that errors (yes, it parses the error output, gasp), it prompts the user
and then uses "git branch -D" if they said yes. Since lazygit already
has a config for what the main branches are, I'll probably change this
logic to do the check on our side, prompt the user if necessary, and use
-D right away.

Thanks for the input!

-Stefan




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux