"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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.
