All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	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 10:30:40 +0100	[thread overview]
Message-ID: <87wnyjdnb3.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20201118091219.3341585-1-felipe.contreras@gmail.com>


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.

  reply	other threads:[~2020-11-18  9:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-18  9:12 [RFC/PATCH] Add fetch.updateHead option Felipe Contreras
2020-11-18  9:30 ` Ævar Arnfjörð Bjarmason [this message]
2020-11-18  9:43   ` Felipe Contreras
2020-11-18 15:53   ` Junio C Hamano
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
  -- strict thread matches above, loose matches on Subject: below --
2024-08-19 17:06 khmer song and funny clip 855
2024-08-19 17:10 khmer song and funny clip 855
2024-08-19 17:10 khmer song and funny clip 855

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

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

  git send-email \
    --in-reply-to=87wnyjdnb3.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=dominik.salvet@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.