git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jay Soffian <jaysoffian@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, peff@peff.net, barkalow@iabervon.org
Subject: Re: [PATCH 4/4] builtin-remote: add set-head verb
Date: Fri, 13 Feb 2009 05:52:57 -0500	[thread overview]
Message-ID: <76718490902130252t18f4f9dav7aada6fe7bb6ab1b@mail.gmail.com> (raw)
In-Reply-To: <7vhc2yaak8.fsf@gitster.siamese.dyndns.org>

On Fri, Feb 13, 2009 at 5:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
> A few things I forgot (and before I go to bed).
>
> If remotes/<name>/HEAD already points at a branch frotz, and you peek the
> remote (i.e. you do not actually run "fetch" to download objects, but just
> "ls-remote" it) and find out that "HEAD" does not point at the same commit
> as "frotz" but it now points at the same commit as another branch
> "nitfol", you probably would want to update it to point at "nitfol", but
> it was unclear from the description in the documentation if this option
> was meant to perform this kind fo update, or only to set a missing HEAD.

- set-head -d <remote> deletes
- set-head -a <remote> sets HEAD to whatever remote it
- set-head <remote> <foo> sets HEAD to foo

I don't know how to be more explicit than that I think that's what the
documentation indicates.

> If you meant to do an update, there is one thing to watch out for when you
> reuse the logic used by clone.  It favors "master" if more than one
> branches point at the same commit as HEAD.

Yes, I know.

> You need to customize it to
> favor the one that the HEAD points at on the local side before you start
> (iow, try to keep the current value when you can).
>
> For example, if it points at "frotz" locally when the command was started,
> and you found out that HEAD now points at the commit at the tip of "frotz"
> and "master" branches by peeking, you do not want to repoint HEAD from
> "frotz" to "master".

I think that is an unnecessary complication for what is really a
corner case. And anyway, it is just hacking around the fact that we
don't really know what the remote side is if multiple branch heads
have the same SHA1 as HEAD.

You proposed a series a while back so that git could unambiguously
determine what a remote symref points to, and I think that's the
better way to fix this problem.

If the user runs "git remote set-head -a <remote>" they will get
whatever "git show <remote>" indicates is the remote HEAD. If they
don't like that, they can set their <remote>/HEAD explicitly using the
alternate syntax.

j.

  reply	other threads:[~2009-02-13 10:54 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-13  8:54 [PATCH 0/4] remote HEAD improvements take 2 Jay Soffian
2009-02-13  8:54 ` [PATCH 1/4] builtin-clone: move locate_head() to remote.c so it can be re-used Jay Soffian
2009-02-13  8:54   ` [PATCH 2/4] builtin-remote: move duplicated cleanup code its own function Jay Soffian
2009-02-13  8:54     ` [PATCH 3/4] builtin-remote: teach show to display remote HEAD Jay Soffian
2009-02-13  8:54       ` [PATCH 4/4] builtin-remote: add set-head verb Jay Soffian
2009-02-13 10:09         ` Junio C Hamano
2009-02-13 10:21           ` Jay Soffian
2009-02-13 11:42             ` [PATCH v2 4/4] builtin-remote: add set-head subcommand Jay Soffian
2009-02-13 10:35           ` [PATCH 4/4] builtin-remote: add set-head verb Junio C Hamano
2009-02-13 10:52             ` Jay Soffian [this message]
2009-02-14  0:22           ` Jeff King
2009-02-14  2:00             ` Junio C Hamano
2009-02-14  2:18               ` Jeff King
2009-02-14  2:48                 ` Jay Soffian
2009-02-14  2:59               ` Jay Soffian
2009-02-14  3:43                 ` Jeff King
2009-02-14 10:30                   ` [PATCH] builtin-remote: better handling of multiple remote HEADs Jay Soffian
2009-02-14 17:54                     ` Jeff King
2009-02-14 18:35                       ` Jay Soffian
2009-02-14 18:54                         ` Jeff King
2009-02-14 19:48                           ` Junio C Hamano
2009-02-14 20:21                       ` Daniel Barkalow
2009-02-14 21:15                         ` Jeff King
2009-02-15  6:08                           ` Jeff King
2009-02-15  6:10                             ` [PATCH 1/5] test scripts: refactor start_httpd helper Jeff King
2009-02-15  6:12                             ` [PATCH 2/5] add basic http clone/fetch tests Jeff King
2009-02-15  8:01                               ` Junio C Hamano
2009-02-15  6:12                             ` [PATCH 3/5] refactor find_refs_by_name to accept const list Jeff King
2009-02-15  6:16                             ` [PATCH 4/5] remote: refactor guess_remote_head Jeff King
2009-02-15  6:18                             ` [PATCH 5/5] remote: use exact HEAD lookup if it is available Jeff King
2009-02-15 15:22                               ` Jay Soffian
2009-02-15 19:58                               ` Jeff King
2009-02-15 20:00                                 ` [PATCH 1/2] transport: cleanup duplicated ref fetching code Jeff King
2009-02-15 20:01                                 ` [PATCH 2/2] transport: unambiguously determine local HEAD Jeff King
2009-02-15  5:27                     ` [PATCH] builtin-remote: better handling of multiple remote HEADs Jeff King
2009-02-15  5:34                       ` Jeff King
2009-02-15 14:13                       ` Jay Soffian
2009-02-15 15:12                         ` Jeff King
2009-02-16  2:21                         ` Junio C Hamano
2009-02-16  2:58                           ` Jay Soffian
2009-02-13  8:57 ` [PATCH 0/4] remote HEAD improvements take 2 Jay Soffian

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=76718490902130252t18f4f9dav7aada6fe7bb6ab1b@mail.gmail.com \
    --to=jaysoffian@gmail.com \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).