Re: [PATCH 1/8] ahead-behind: create empty builtin

[Taylor Blau <me@ttaylorr.com>]

On Mon, Mar 06, 2023 at 10:48:45AM -0800, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > For example, we will be able to track all local branches relative to an
> > upstream branch using an invocation such as
> >
> >   git for-each-ref --format=%(refname) refs/heads/* |
> >     git ahead-behind --base=origin/main --stdin
>
> Stepping back a bit, this motivating example makes me wonder if
>
>  $ git for-each-ref --format='%(refname) %(aheadbehind)' refs/heads/\*

One disadvantage to using for-each-ref here is that we are bound to use
all of the ref-sorting code, so callers can't see intermediate results
until the entire walk is complete.

I can't remember enough of the details about the custom traversal we use
here to know if that would even matter or not (i.e., do we need to
traverse through the whole set of objects entirely before outputting a
single result anyway?). But something to think about nonetheless.

At the very least, it is quite a cute idea (especially something like
'%(aheadbehind:origin/main)') ;-).

> that computes the ahead-behind number for each ref (that matches the
> pattern) based on their own "upstream" (presumably each branch is
> configured to track the same, or different, upstreams), or
> overrriding @{upstream}, a specified base, i.e.
>
>  $ git for-each-ref --format='%(refname) %(aheadbehind:origin/main)' refs/heads/\*
>
> would be a more intuitive interface to the end-users.
>
> It would probably work well in conjunction with
>
>     git for-each-ref --format='%(refname)' --merged origin/main refs/heads/\*
>
> which is a way to list local branches that are already merged into
> the upstream, to have the feature appear in the same command,
> perhaps?

One thing that we had talked about internally[^1] was the idea of
specifying multiple bases. IOW, having some way to invoke the
ahead-behind builtin that gives some set of tips with a common base B1,
and another set of tips (which could--but doesn't have to--intersect
with the first) and a common base to compare *them* to, say, B2.

There are some technical reasons that we might want to consider such a
thing at least motivated by GitHub's proposed future use of it. But they
are kind of technical and not that interesting to this discussion, so I
wouldn't be sad if we didn't have a way to specify multiple bases.

OTOH, it would be nice to avoid painting ourselves into a corner from a
UI-perspective if we can avoid it.

Thanks,
Taylor

[^1]: ...and couldn't decide if it was going to be a nice future
addition or simply another case of YAGNI ;-).