On Sun, Oct 20, 2024 at 11:42:38PM +0200, Bence Ferdinandy wrote:
> 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
