[PATCH] branch: do not attempt to track HEAD implicitly

[PATCH] branch: do not attempt to track HEAD implicitly

[Thomas Rast]

With branch.autosetupmerge=always, 'HEAD' becomes a valid target for
branch tracking.  This is a bit silly, and in fact the code already
guards against it when attempting it explicitly:

  $ git checkout HEAD^0
  $ g branch -t foo
  fatal: Cannot setup tracking information; starting point is not a branch.

Silently drop the HEAD candidate in the implicit (i.e. without -t
flag) case, so that the branch starts out without an upstream.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 branch.c          |    8 ++++++--
 t/t3200-branch.sh |    9 +++++++++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/branch.c b/branch.c
index 93dc866..19310e4 100644
--- a/branch.c
+++ b/branch.c
@@ -176,8 +176,12 @@ void create_branch(const char *head,
 		break;
 	case 1:
 		/* Unique completion -- good, only if it is a real ref */
-		if (explicit_tracking && !strcmp(real_ref, "HEAD"))
-			die("Cannot setup tracking information; starting point is not a branch.");
+		if (!strcmp(real_ref, "HEAD")) {
+			if (explicit_tracking)
+				die("Cannot setup tracking information; starting point is not a branch.");
+			else
+				real_ref = NULL;
+		}
 		break;
 	default:
 		die("Ambiguous object name: '%s'.", start_name);
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index f308235..0fa5c91 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -488,6 +488,15 @@ test_expect_success 'autosetuprebase always on an untracked remote branch' '
 	test "z$(git config branch.myr20.rebase)" = z
 '
 
+test_expect_success 'autosetuprebase always on detached HEAD' '
+	git config branch.autosetupmerge always &&
+	test_when_finished git checkout master &&
+	git checkout HEAD^0 &&
+	git branch my11 &&
+	test -z "$(git config branch.my11.remote)" &&
+	test -z "$(git config branch.my11.merge)"
+'
+
 test_expect_success 'detect misconfigured autosetuprebase (bad value)' '
 	git config branch.autosetuprebase garbage &&
 	test_must_fail git branch
-- 
1.7.3.3.797.g7a32f

Re: [PATCH] branch: do not attempt to track HEAD implicitly

[Martin von Zweigbergk]

On Tue, Dec 14, 2010 at 1:38 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> With branch.autosetupmerge=always, 'HEAD' becomes a valid target for
> branch tracking.  This is a bit silly, and in fact the code already
> guards against it when attempting it explicitly:
>
>  $ git checkout HEAD^0
>  $ g branch -t foo

missing the "it" in "git"

>  fatal: Cannot setup tracking information; starting point is not a branch.
>
> Silently drop the HEAD candidate in the implicit (i.e. without -t
> flag) case, so that the branch starts out without an upstream.

Thanks. This has been on my todo list for a while.

Should it only check for HEAD? How about ORIG_HEAD and FETCH_HEAD?
Simply anything outside of refs/ maybe? Would that make sense?

/Martin

Re: [PATCH] branch: do not attempt to track HEAD implicitly

[Thomas Rast]

Martin von Zweigbergk wrote:
> On Tue, Dec 14, 2010 at 1:38 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> > Silently drop the HEAD candidate in the implicit (i.e. without -t
> > flag) case, so that the branch starts out without an upstream.
> 
> Thanks. This has been on my todo list for a while.
> 
> Should it only check for HEAD? How about ORIG_HEAD and FETCH_HEAD?
> Simply anything outside of refs/ maybe? Would that make sense?

Good point.  It seems HEAD wins the dwim_ref() over the rest:

$ g rev-parse HEAD ORIG_HEAD FETCH_HEAD
79f9a226d33659f0e6a69429931d66b5f70c9708
79f9a226d33659f0e6a69429931d66b5f70c9708
79f9a226d33659f0e6a69429931d66b5f70c9708
$ g branch test
$ g config -l | grep branch.test.

Not sure through which mechanism, however.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: [PATCH] branch: do not attempt to track HEAD implicitly

[Martin von Zweigbergk]

On Wed, 15 Dec 2010, Thomas Rast wrote:

> Martin von Zweigbergk wrote:
> > On Tue, Dec 14, 2010 at 1:38 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> > > Silently drop the HEAD candidate in the implicit (i.e. without -t
> > > flag) case, so that the branch starts out without an upstream.
> > 
> > Thanks. This has been on my todo list for a while.
> > 
> > Should it only check for HEAD? How about ORIG_HEAD and FETCH_HEAD?
> > Simply anything outside of refs/ maybe? Would that make sense?
> 
> Good point.  It seems HEAD wins the dwim_ref() over the rest:
> 
> $ g rev-parse HEAD ORIG_HEAD FETCH_HEAD
> 79f9a226d33659f0e6a69429931d66b5f70c9708
> 79f9a226d33659f0e6a69429931d66b5f70c9708
> 79f9a226d33659f0e6a69429931d66b5f70c9708

Probably a stupid question, but why are all three of them pointing to
the same commit? I guess that is what you want to show, but how did
you get there? If I run the same command (I assume your 'g' alias
simply calls git), I get three different commits (in general, of
course).

> $ g branch test
> $ g config -l | grep branch.test.
> 
> Not sure through which mechanism, however.

The scenario I meant is the following:

$ git config branch.autosetupmerge always
$ git branch test ORIG_HEAD
Branch test set up to track local ref ORIG_HEAD.
$ git config -l | grep branch.test
branch.test.remote=.
branch.test.merge=ORIG_HEAD


/Martin

Re: [PATCH] branch: do not attempt to track HEAD implicitly

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Martin von Zweigbergk wrote:
>> On Tue, Dec 14, 2010 at 1:38 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>> > Silently drop the HEAD candidate in the implicit (i.e. without -t
>> > flag) case, so that the branch starts out without an upstream.
>> 
>> Thanks. This has been on my todo list for a while.
>> 
>> Should it only check for HEAD? How about ORIG_HEAD and FETCH_HEAD?
>> Simply anything outside of refs/ maybe? Would that make sense?

I was tempted to say "limit to refs/heads/ and refs/remotes/" but perhaps
people have custom namespaces defined in refs/ hierarchy and for some of
them the tracking may make sense.  How about ignoring the implicit track
if the ref does not begin with refs/ to cover the obvious ones like HEAD,
FETCH_HEAD, etc.?