git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
	git@vger.kernel.org, Jeff King <peff@peff.net>,
	Jonathan Nieder <jrnieder@gmail.com>,
	Dominik Salvet <dominik.salvet@gmail.com>
Subject: Re: [RFC/PATCH] Add fetch.updateHead option
Date: Wed, 18 Nov 2020 07:53:06 -0800
Message-ID: <xmqqwnyi3bml.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <87wnyjdnb3.fsf@evledraar.gmail.com> (=?utf-8?B?IsOGdmFyIEFy?= =?utf-8?B?bmZqw7Zyw7A=?= Bjarmason"'s message of "Wed, 18 Nov 2020 10:30:40 +0100")

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Wed, Nov 18 2020, Felipe Contreras wrote:
>
>> Users might change the behavior when running "git fetch" so that the
>> remote's HEAD symbolic ref is updated at certain point.
>>
>> For example after running "git remote add" the remote HEAD is not
>> set like it is with "git clone".
>>
>> Setting "fetch.updatehead = missing" would probably be a sensible
>> default that everyone would want, but for now the default behavior is to
>> never update HEAD, so there shouldn't be any functional changes.
>>
>> For the next major version of Git, we might want to change this default.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>>
>> This is just a RFC, the tests are missing.
>
> I haven't taken much time to re-think through the patch/implications of
> this, but I remember running into this and going through some pre-patch
> investigation at some point.
>
> It's really annoying in some cases that "clone" isn't creating the same
> state as "remote". IIRC I was doing some heuristics to figure out the
> remote branch name etc.
>
> Isn't this something we can just change without an option? There were a
> bunch of cases in clone/fetch that were different for no different
> reasons, IIRC I patched one or two of those in the past. But I haven't
> gone through the history of the feature and checked if it was
> intentional.

I think what Peff outlined earlier was reasonable.  "remote add -f",
since it talks with the remote, should be able to learn where their
HEAD points at and set it up.  "remote add" that does not talk to
the remote cannot do so and "fetch" could help but we should not
touch existing refs/remotes/$name/HEAD by default [*1*], as the
symref is meant to indicate the local choice of which one of their
branches is significant to _us_ and what "clone" does is merely to
give it the initial value.

But when interacting with a remote whose choice of HEAD is always
what the local user wants to follow, letting "git fetch" update
refs/remotes/$name/HEAD to a newly observed value would be a welcome
optional feature.

I haven't thought through what Jonathan (Nieder) said about an
option to fail a fetch when refs/remotes/$name/HEAD and the remote
HEAD "git fetch" observed do not match.  It may make sense in some
cases but not always, and I do not know what the right explanation
for the use case the mode is supposed to be a good match is.


[Footnote]

*1* This is important when you work in more than one repositories
with working tree and use fetch+rebase to keep them in sync.

  parent reply	other threads:[~2020-11-18 15:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-18  9:12 Felipe Contreras
2020-11-18  9:30 ` Ævar Arnfjörð Bjarmason
2020-11-18  9:43   ` Felipe Contreras
2020-11-18 15:53   ` Junio C Hamano [this message]
2020-11-18 19:04     ` Felipe Contreras
2020-11-20 23:52 ` Jeff King
2020-11-21  0:28   ` Junio C Hamano
2020-11-21  0:40     ` Jeff King
2020-11-21  1:18       ` Felipe Contreras
2020-11-24  6:58         ` Jeff King
2020-11-21  1:53     ` Felipe Contreras
2020-11-21  1:41   ` Felipe Contreras
2020-11-24  7:09     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqwnyi3bml.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=dominik.salvet@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git