On Thu, Feb 16, 2023 at 12:00 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Alex Henrie <alexhenrie24@xxxxxxxxx> writes:
>
> > GitHub and GitLab have features to create a branch using the web
> > interface, then delete the branch after it is merged. That results in a
> > lot of "gone" branches in my local clone, and I frequently find myself
> > typing `git branch -v | grep gone`. I don't want `git branch --merged`
> > because that would include branches that have been created for future
> > work but do not yet have any commits.
>
> I can see why it is a useful feature to filter or group branches by
> its remote tracking status, but I do not know if the design
> presented here is what we want. "--has-upstream" (yes/no) is
> understandable, but "--no-has-upstream" is quite a mouthful and an
> awkward way to say "no configured upstream" ("--has-no-upstream"
> might be more palatable). "--gone" does not even hint it is about
> the precense or absense of upstream ("Are we looking for a branch
> that is gone? Perhaps in a future we may have logs of branches that
> have been deleted?") and will not "click" in readers' mind that it
> is about branches configured to track some branch at the remote that
> has been removed.
>
> Perhaps something like
>
> --upstream=(configured|unconfigured|gone)
>
> may be easier to explain, understand, and possibly more extensible
> but I dunno.
>
> If most people use a single remote and track branches from the
> single remote, then --upstream=origin to select branches with
> upstream configured somewhere in origin would allow users who
> interact with multiple remotes to further limit by remote. Or we
> could even go --upstream=refs/remotes/origin/* using ref matching
> rules to specify that chosen branches must have upstream configured
> to refs that match the pattern (your "--has-upstream" becomes a mere
> special case of doing "--upstream=*"), with a special token, e.g.
> "--upstream=no", that never matches a real ref, to select ones
> without any upstream configured.
>
> I do not know offhand how that line of UI design that allows future
> enhancement would mesh with the concept of "configured upstream no
> longer exists", but whatever UI we pick that is understandable,
> explainable and extensible, it should be made to work well with
> "gone", too.
Hi Junio, thank you for the feedback.
I intentionally avoided naming the new option --upstream to avoid
confusion with the -u and --set-upstream-to options. And as you
pointed out, --upstream=(configured|unconfigured|gone) would preclude
adding an optional argument to search for branches with a particular
upstream.
I don't know how we could make the negative options sound better. The
inverses of --merged and --contains are --no-merged and --no-contains
(which also sound a little weird, but are perfectly understandable),
and I think there's value in following the same pattern.
You have a good point that --gone makes it sound like the option
searches for locally deleted branches. How about --upstream-gone
instead?
-Alex
