Re: [PATCH] branch: introduce --(no-)has-upstream and --(no-)gone options

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 16, 2023, 19:00 UTC
Message-ID: <xmqqa61dpha9.fsf@gitster.g>
In-Reply-To: <20230216041432.1668365-1-alexhenrie24@gmail.com>

Alex Henrie <alexhenrie24@gmail.com> writes:

Show 6 quoted lines

> 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.