On 07.09.24 22:00, Junio C Hamano wrote: > Stefan Haller <lists@xxxxxxxxxxxxxxxx> writes: > >>> 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 get the idea behind that statement, but I do not think it is > necessary to make Git second guess the end user is warranted in this > case. > > If refs/heads/master builds on top of refs/remotes/origin/master, > and if the user is worried about the former being not up to date > relative to the latter, then the user can say "'branch -d' is safe > if the commit is merged in refs/remotes/origin/master", instead of > telling the command to check with 'refs/heads/master'. Ah sure, if that configuration takes full refs, then yes, let the user configure exactly what they want. I thought it would take just bare branch names. (That's what we do in lazygit, we find this more convenient. It does take some heuristics to see which of these actually exist, and whether to use the upstream or local one, but it makes it easier for users. I'm not proposing to go this way with git.) -Stefan
