On Mon Oct 21, 2024 at 21:14, Jeff King <peff@xxxxxxxx> wrote:
> 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..
That particular one will break if you have something like
refs/remotes/origin/foo/bar, but I get your point.
>
> And possibly we could make it easier to just grab the remote name with a
> single command.
As I was running this patch through my head yesterday I sort of distilled my
argument in favour to "writing remote agnostic scripts are unnecessarily
complicated", but I do agree, that if there were a git command that could
return the remote for a branch without any extra scripting hacks would easily
get you the same result, and may even be useful elsewhere.
I'm not sure where this would be the best. Maybe:
git branch --show-current-remote
?
Thanks for the feedback!
Best,
Bence
--
bence.ferdinandy.com
