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

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