git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
From: Jeff King <peff@peff.net>
To: Christian Couder <christian.couder@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: Syncing HEAD
Date: Tue, 14 Aug 2018 17:47:24 -0400
Message-ID: <20180814214723.GA667@sigill.intra.peff.net> (raw)
In-Reply-To: <20180814210616.GA32367@sigill.intra.peff.net>

On Tue, Aug 14, 2018 at 05:06:16PM -0400, Jeff King wrote:

> On Tue, Aug 14, 2018 at 10:09:37PM +0200, Christian Couder wrote:
> 
> > When cloning with --mirror, the clone gets its HEAD initialized with
> > the value HEAD has in its origin remote. After that if HEAD changes in
> > origin there is no simple way to sync HEAD at the same time as the
> > refs are synced.
> > 
> > It looks like the simplest way to sync HEAD is:
> > 
> > 1) git remote show origin
> > 2) parse "HEAD branch: XXX" from the output of the above command
> > 3) git symbolic-ref HEAD refs/heads/XXX
> 
> How about:
> 
>   git remote set-head origin -a
> 
> ?

Reading your message again, I see you actually care less about the
refs/remote placeholder and more about the actual HEAD in a bare repo.

In which case "git remote" isn't going to help, though its underlying
code has the algorithm you would want.

> One tricky thing is that the name "refs/remotes/<remote>/HEAD" is only
> special by convention, and that convention is known on the writing side
> only by git-clone and git-remote. So obviously:

And so here the convention is simpler, because we're talking about the
main HEAD. But we still have know if you want to do that, and not update
some refs/remotes/ symref in a bare repo.

So all of this really implies to me that you want to be able to say
"take this symref on the other side and update this one on the local
side". I.e., some way to tell a refspec "don't update the value, update
the symref destination". So imagine we made "~" the magic character for
"just the symrefs" (I picked that because it's not allowed in a
refname).

Then you could do what you want with:

  git config --add remote.origin.fetch ~HEAD:HEAD

and these two would be the same:

  git remote set-head origin -a
  git fetch origin ~HEAD:refs/remotes/origin/HEAD

And it would allow more exotic things, too, like:

  # always update the remote notion of HEAD on every fetch
  git config --add remote.origin.fetch ~HEAD:refs/remotes/origin/HEAD

  # update a non-HEAD symref we track for our own purposes
  git fetch origin ~refs/tags/LATEST:refs/tags/LATEST

  # or the same thing but using the usual refspec "dst defaults to src"
  # rule and dwim lookup magic
  git fetch origin ~LATEST

In protocol v0 we don't get symref reports from the other side over the
git protocol (except for HEAD), but we could use the same logic we use
for determining HEAD for older versions of Git: find a ref that points
to the same tip. Though I would say that unlike the existing code in
guess_remote_head(), we'd probably want to treat an ambiguity as an
error, and not just default to refs/heads/master.

-Peff

  reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-14 20:09 Christian Couder
2018-08-14 20:58 ` Stefan Beller
2018-08-14 21:08   ` Brandon Williams
2018-08-14 21:06 ` Jeff King
2018-08-14 21:47   ` Jeff King [this message]
2018-08-15  5:49     ` Christian Couder
2018-08-17  1:47       ` Jeff King
2018-08-17 16:28     ` Junio C Hamano
2018-08-17 16:48       ` Jeff King
2018-08-14 22:05 ` Ævar Arnfjörð Bjarmason

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=20180814214723.GA667@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    /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)

Archives are clonable:
	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

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/

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