git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Pat Notz" <pknotz@sandia.gov>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>
Subject: Re: [PATCHv6] Make git-clone respect branch.autosetuprebase
Date: Tue, 10 Mar 2009 01:16:15 -0700	[thread overview]
Message-ID: <7vab7tbxo0.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 1236659098-14400-1-git-send-email-pknotz@sandia.gov

"Pat Notz" <pknotz@sandia.gov> writes:

> This version fixes the verbose output to be more human friendly.  Before,
> the branch being tracked was printed as 'refs/heads/frotz' regardless of
> wether that was a local or remote branch.  Now, a local branch is just
> printed as 'frotz' and a remote branch is printed as 'origin/frotz'

Since I've already queued the previous round in 'next', I took the liberty
of making this into an incremental.

I do not think what you did is really correct.  For clone, because we do
not create anything but the default "refs/remotes/<origin>/<branch>"
layout, always stripping out the first 11 bytes "refs/heads/" happens to
give a more intuitive result.  But the helper function is shared with a
more general "git branch --track" that lets you mark the new branch to
track almost anything.  For example, the version from v1.6.0 gives you
these:

    $ git branch --track maint-1.6.0 v1.6.0
    Branch maint-1.6.0 set up to track local branch refs/tags/v1.6.0
    $ git branch --track frotz master
    Branch frotz set up to track local branch refs/heads/master

Arguably, the former should say "track local ref refs/tags/v1.6.0" (or the
command should not even let you "track" a tag, which is supposed to be
immutable), and the latter would be helped by stripping "refs/heads/".
But the point is that stripping first 11 bytes unconditionally would be
wrong if you happen to start tracking a tag whose name is a single byte.

Also I do not think ("%s/%s", origin, remote+11) is correct in general.
You could very well configure your tracking to:

	[remote "origin"]
	fetch = refs/heads/*:refs/remotes/upstream/*

and I think the variable "remote" here refer to the name the ref is known
as in the remote repository, not the name we use to keep a copy of.  IOW,
when we say "Branch frotz tracks remote 'master'", we should say "the
branch known as 'master' at the remote site, no matter what name we happen
to call its copy locally somewhere under our refs/remotes".

In that sense, both the version I queued and the original are lacking
a critical piece of information: which remote we are talking about.

In any case, here is your patch, made into an incremental.  I'll send out
an alternative fix in a separate message.

 branch.c |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/branch.c b/branch.c
index d20fb04..d586843 100644
--- a/branch.c
+++ b/branch.c
@@ -65,12 +65,18 @@ void install_branch_config(int flag, const char *local, const char *origin, cons
 		git_config_set(key.buf, "true");
 	}
 
-	if (flag & BRANCH_CONFIG_VERBOSE)
+	if (flag & BRANCH_CONFIG_VERBOSE) {
+		strbuf_reset(&key);
+		if (origin)
+			strbuf_addf(&key, "%s/%s", origin, remote+11);
+		else
+			strbuf_addf(&key, "%s", remote+11);
 		printf("Branch %s set up to track %s branch %s %s.\n",
 		       local,
 		       origin ? "remote" : "local",
-		       remote,
+		       key.buf,
 		       rebasing ? "by rebasing" : "by merging");
+	}
 	strbuf_release(&key);
 }
 

  reply	other threads:[~2009-03-10  8:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1cd1989b0903060621w60124401s9986507e356783b1@mail.gmail.com>
2009-03-10  3:26 ` [PATCHv5] Make git-clone respect branch.autosetuprebase Pat Notz
2009-03-10  4:24   ` [PATCHv6] " Pat Notz
2009-03-10  8:16     ` Junio C Hamano [this message]
2009-03-10  8:20       ` [PATCH] Improve "git branch --tracking" output Junio C Hamano

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=7vab7tbxo0.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=pknotz@sandia.gov \
    /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).