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.
