feature request: set remote/HEAD with fetch

feature request: set remote/HEAD with fetch

[Bence Ferdinandy]

Hi,

this comes after a bit of discussion on #git. The current behaviour of git is
that when cloning, `refs/remotes/[remote]/HEAD` is set, but if you use `git
init` and `git remote add`, then you must manually run `git remote set-head -a`
to arrive at the same state. Having origin/HEAD set is pretty useful for
scripting and aliases, because you don't need to remember what the current
project uses (origin/[master|main|trunk|etc]).

I would propose that running `git fetch` should also update remote/HEAD. In
case there is a possibility that it is useful in some cases that remote/HEAD is
actually different from whatever is set in the remote repository as the default
branch, I think a setting for opt-out would be better, and the default
behaviour should be essentially always running `set-head -a`.

My current workaround is an alias:
    fetchall = !git fetch --all && git remote | xargs -i git remote set-head -a {}

which works for me, but I think it would be more elegant not to have to do this.

A slight aside: if `refs/remotes/[remote]/HEAD` is set you still might have
a problem of easily accessing the current remote's HEAD, since @{upstream} will
point to the branch. It's again not something you can't script around, but
would be cool if there were an easy way of avoiding hardcoded "origin" in
aliases and scripts.

Thanks for considering!

Best,
Bence

Re: feature request: set remote/HEAD with fetch

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

On 2024-08-16 at 11:53:31, Bence Ferdinandy wrote:
> Hi,
> 
> this comes after a bit of discussion on #git. The current behaviour of git is
> that when cloning, `refs/remotes/[remote]/HEAD` is set, but if you use `git
> init` and `git remote add`, then you must manually run `git remote set-head -a`
> to arrive at the same state. Having origin/HEAD set is pretty useful for
> scripting and aliases, because you don't need to remember what the current
> project uses (origin/[master|main|trunk|etc]).
> 
> I would propose that running `git fetch` should also update remote/HEAD. In
> case there is a possibility that it is useful in some cases that remote/HEAD is
> actually different from whatever is set in the remote repository as the default
> branch, I think a setting for opt-out would be better, and the default
> behaviour should be essentially always running `set-head -a`.
> 
> My current workaround is an alias:
>     fetchall = !git fetch --all && git remote | xargs -i git remote set-head -a {}
> 
> which works for me, but I think it would be more elegant not to have to do this.

I believe this would be a valuable change.  I know a lot of other users
want this features as well.  However, I think it needs to be opt-in,
since there are some cases where you want `git fetch` to specifically
fetch only certain objects or don't want to modify the refs. For
example, I know some server-side implementations use `git fetch`
internally and require refs to be updated in a special way, and they
would not appreciate extra refs appearing.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: feature request: set remote/HEAD with fetch

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

>> My current workaround is an alias:
>>     fetchall = !git fetch --all && git remote | xargs -i git remote set-head -a {}
>> 
>> which works for me, but I think it would be more elegant not to have to do this.
>
> I believe this would be a valuable change.  I know a lot of other users
> want this features as well.  However, I think it needs to be opt-in,
> since there are some cases where you want `git fetch` to specifically
> fetch only certain objects or don't want to modify the refs. For
> example, I know some server-side implementations use `git fetch`
> internally and require refs to be updated in a special way, and they
> would not appreciate extra refs appearing.

Yeah, "remote set-head" implementation internally uses the same
"what's the current state of the refs on the other side?" query as
what "fetch" does when it contacts the other side, so it makes sense
for a new feature "git fetch --set-head ..." to internally do what
is done by "remote set-head".

What should *not* happen automatically without an opt-in is to
overwrite an existing refs/remotes/$remote/HEAD with a new value.
It might even make sense to allow it to happen, even if the
"--set-head" option is not given from the command line, if
"refs/remotes/$remote/HEAD" does not exist.

Thanks.

Re: feature request: set remote/HEAD with fetch

[Jeff King]

On Fri, Aug 16, 2024 at 09:55:00PM +0000, brian m. carlson wrote:

> > I would propose that running `git fetch` should also update remote/HEAD. In
> > case there is a possibility that it is useful in some cases that remote/HEAD is
> > actually different from whatever is set in the remote repository as the default
> > branch, I think a setting for opt-out would be better, and the default
> > behaviour should be essentially always running `set-head -a`.
> > 
> > My current workaround is an alias:
> >     fetchall = !git fetch --all && git remote | xargs -i git remote set-head -a {}
> > 
> > which works for me, but I think it would be more elegant not to have to do this.
> 
> I believe this would be a valuable change.  I know a lot of other users
> want this features as well.  However, I think it needs to be opt-in,
> since there are some cases where you want `git fetch` to specifically
> fetch only certain objects or don't want to modify the refs. For
> example, I know some server-side implementations use `git fetch`
> internally and require refs to be updated in a special way, and they
> would not appreciate extra refs appearing.

There was discussion a while ago that proposed a tri-state config
option: never update the remote head on fetch, always do so, or add it
only when missing:

  https://lore.kernel.org/git/20201118091219.3341585-1-felipe.contreras@gmail.com/

I think that is a good first step, as we could stop there and leave the
default at "never" without any compatibility issues (and/or contemplate
a change in the default as a separate step).

I don't think the patch in that thread is likely to go anywhere at this
point, but if somebody wanted to pick it up, I think everybody was
positive on the general direction.

-Peff

Re: feature request: set remote/HEAD with fetch

[Bence Ferdinandy]

> There was discussion a while ago that proposed a tri-state config
> option: never update the remote head on fetch, always do so, or add it
> only when missing:
>
>   https://lore.kernel.org/git/20201118091219.3341585-1-felipe.contreras@gmail.com/

Thanks for linking that, I didn't think about searching for old discussion
before writing ...

>
> I think that is a good first step, as we could stop there and leave the
> default at "never" without any compatibility issues (and/or contemplate
> a change in the default as a separate step).
>
> I don't think the patch in that thread is likely to go anywhere at this
> point, but if somebody wanted to pick it up, I think everybody was
> positive on the general direction.

My C skills aren't great (probably an overstatement), but if Felipe or somebody
else more qualified than me doesn't want to pick this up, I'm willing to give
it a shot based on the Felipe's patch. It will take some time though :)

Thanks,
Bence

Re: feature request: set remote/HEAD with fetch

[Johannes Schindelin]

Hi Bence,

On Sat, 17 Aug 2024, Bence Ferdinandy wrote:

>
> > There was discussion a while ago that proposed a tri-state config
> > option: never update the remote head on fetch, always do so, or add it
> > only when missing:
> >
> >   https://lore.kernel.org/git/20201118091219.3341585-1-felipe.contreras@gmail.com/
>
> Thanks for linking that, I didn't think about searching for old discussion
> before writing ...

A better link (in particular because it does not involve a now-banned
person) might be
https://lore.kernel.org/git/CANWRddN4R6AceeaOyZm1vs8AXBNv3J+cE5MOyrhKVhcqddjUOA@mail.gmail.com/

This discussion might not be about that mentioned tri-state, but about the
"take a step back" question: What is the best way to update a
remote-tracking `HEAD`.

> > I think that is a good first step, as we could stop there and leave the
> > default at "never" without any compatibility issues (and/or contemplate
> > a change in the default as a separate step).
> >
> > I don't think the patch in that thread is likely to go anywhere at this
> > point, but if somebody wanted to pick it up, I think everybody was
> > positive on the general direction.
>
> My C skills aren't great (probably an overstatement), but if Felipe or somebody
> else more qualified than me doesn't want to pick this up, I'm willing to give
> it a shot based on the Felipe's patch. It will take some time though :)

I dropped him from the Cc:, as a consequence of
https://lore.kernel.org/git/ZF%2F38DXNYMsZjvy4@nand.local/.

Since this leaves you in somewhat of a pickle because you probably should
not start from those patches, and since you seem to be in the same time
zone as I am, I'll offer you to pair with you on getting you started. If
you are interested, please just reply privately.

Ciao,
Johannes

Re: feature request: set remote/HEAD with fetch

[Bence Ferdinandy]

Hey,

On Mon Aug 19, 2024 at 18:40, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> https://lore.kernel.org/git/ZF%2F38DXNYMsZjvy4@nand.local/.

well, _that_ was definitely not something I searched for.

>
> Since this leaves you in somewhat of a pickle because you probably should
> not start from those patches, and since you seem to be in the same time
> zone as I am, I'll offer you to pair with you on getting you started. If
> you are interested, please just reply privately.

Sure, thanks, I'll reach out to you about the details in private.

Best,
Bence