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

["Bence Ferdinandy" <bence@ferdinandy.com>]

On Sun Oct 20, 2024 at 22:40, Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> wrote:
> Good evening
>
> On Sun, Oct 20, 2024, at 22:24, Bence Ferdinandy wrote:
>> The HEAD of the remote is useful in many situations, but currently one
>> would need to know the name of the remote to perform something like
>> "git log origin/HEAD..", which makes writing remote agnostic aliases
>> complicated. Introduce the new shorthand "@{upstreamhead}" which returns
>> <remote>/HEAD for the same <remote> "@{upstream}" would yield.
>>
>> Signed-off-by: Bence Ferdinandy <bence@ferdinandy.com>
>> ---
>>
>> Notes:
>>     RFC v1: Testing and documentation is completely missing, I'll add those
>>             in a v2 if people think the patch has merit.
>
> Do you have some concrete examples?  I’m not well versed in using
> remote HEAD.

N.b. I was intending to write s/many situations/some situations.

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 also use remote/HEAD in CICD, i.e. with `git rev-list origin/HEAD..` you
  can run checks on a commit-by-commit bases instead of the end result of
  a patch series or pull request. It's really useful to check have basic checks
  for commit messages for example. In a CICD of course for a _specific_ project
  you know what HEAD is, but still, using HEAD makes a step portable across
  repos. And again of course, I think in CICD you almost certainly will always
  end up with the remote being called "origin", so this change might not be
  quite so useful there.

But so the long story short here is that for
(origin|upstream)/(master|main|trunk) we can already have agnostic code with
HEAD for the second part and with a patch like this we could have agnostic code
for the whole thing.

Best,
Bence

-- 
bence.ferdinandy.com