Re: [RFC PATCH] object-name: add @{upstreamhead} shorthand

From: Jeff King <peff@peff.net>
Date: Oct 21, 2024, 19:14 UTC
Message-ID: <20241021191441.GD1219228@coredump.intra.peff.net>
In-Reply-To: <D50YLOBHJTLS.367TMAOLKL019@ferdinandy.com>

On Sun, Oct 20, 2024 at 11:42:38PM +0200, Bence Ferdinandy wrote:

Show 9 quoted lines

> I basically use it for two things:
> 
> - variations of `git log remote/HEAD..` for which I currently have an alias
>   with "origin" hardcoded. E.g. I'm on a feature branch I'm reviewing and
>   I want to know what commits are new compared to origin/(master|main|trunk),
>   but I use HEAD, because I never know (and don't really want to pay attention
>   to) what project uses what. And although "origin" is usually ok, but not
>   always if there are forks in play, so @{upstreamhead} would make it agnostic
>   to the remote's name.

I'm a little skeptical that this is useful. If a local branch has a particular remote branch configured as its upstream, then shouldn't your search for new commits be against that configured upstream branch, not whatever that remote's HEAD happens to be?

In many cases, of course, I'd expect that HEAD to also be the upstream branch. But then you could just use @{upstream}.

And in some cases, you really want to compare against a known base point, regardless of the configured upstream. But then you should use the full name of that base point, rather than the remote half of the upstream config.

It sounds more like a band-aid for scripts that are expected to be used across repos that may use other names for what is effectively "origin". In which case I question whether we really want new lookup syntax, versus having those scripts learn to query the remote name.

E.g., I think you could do:

  upstream=$(git rev-parse --symbolic-full-name @{upstream})
  git log ${upstream%/*}/HEAD..

And possibly we could make it easier to just grab the remote name with a single command.

-Peff