threads / discuss / 18378

Re: Git {log,diff} against tracked branch?

Subject: Re: Git {log,diff} against tracked branch?

## tl;dr

61 messages between Mar 18, 2009 and Mar 22, 2009.

replies: 60people: 16as markdown or json

Petr Baudis· Mar 18, 2009, 18:26 UTC · lore
  Hi,
On Wed, Mar 18, 2009 at 02:48:50PM +0100, Andreas Gruenbacher wrote:
Show 5 quoted lines
> I often want to see what the differences are between a local branch and the 
> branch it tracks (if it tracks a branch). I currently do something like "git 
> log master..origin/master". This is a lot of unnecessary typing though 
> compared to something like "git log -t master", or even "git log -t" when on 
> the master branch.
  sorry, I think Git can't do anything like this either. :-(
  However, I think something like this would be useful and probably easy
to do? Maybe someone on the list will get inspired to implement
a special refspec character to represent the "tracked branch"
relationship, so e.g. %master would expand to %origin/master. Then you
should be able to do something like:
	git log %..
-- 
				Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
Johannes Schindelin· Mar 18, 2009, 21:12 UTC · re: Petr Baudis · lore

[PATCH] Introduce %<branch> as shortcut to the tracked branch

Suggested by Pasky.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
	On Wed, 18 Mar 2009, Petr Baudis wrote:
	> On Wed, Mar 18, 2009 at 02:48:50PM +0100, Andreas Gruenbacher wrote:
	> > I often want to see what the differences are between a local 
	> > branch and the branch it tracks (if it tracks a branch). I
	> > currently do something like "git log master..origin/master". 
	> > This is a lot of unnecessary typing though compared to something
	> > like "git log -t master", or even "git log -t" when on the 
	> > master branch.
	> 
	> sorry, I think Git can't do anything like this either. :-(
	> 
	> However, I think something like this would be useful and 
	> probably easy to do? Maybe someone on the list will get inspired to 
	> implement a special refspec character to represent the "tracked
	> branch" relationship, so e.g. %master would expand to 
	> %origin/master. Then you should be able to do something like:
	> 
	> 	git log %..
	Great idea!
 sha1_name.c |   22 ++++++++++++++++++----
 1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index a96ca8b..1a77b20 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -6,6 +6,7 @@
 #include "tree-walk.h"
 #include "refs.h"
 #include "cache-tree.h"
+#include "remote.h"
 
 static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
 {
@@ -241,9 +242,10 @@ static int ambiguous_path(const char *path, int len)
 
 /*
  * *string and *len will only be substituted, and *string returned (for
- * later free()ing) if the string passed in is of the form @{-<n>}.
+ * later free()ing) if the string passed in is of the form @{-<n>} or
+ * of the form %<branch>.
  */
-static char *substitute_nth_last_branch(const char **string, int *len)
+static char *substitute_branch(const char **string, int *len)
 {
 	struct strbuf buf = STRBUF_INIT;
 	int ret = interpret_nth_last_branch(*string, &buf);
@@ -255,12 +257,24 @@ static char *substitute_nth_last_branch(const char **string, int *len)
 		return (char *)*string;
 	}
 
+	if (**string == '%') {
+		int ours, theirs;
+		struct branch *tracking = branch_get((*string)[1] ?
+			(*string) + 1 : NULL);
+
+		if (tracking->merge && tracking->merge[0]->dst) {
+			*string = xstrdup(tracking->merge[0]->dst);
+			*len = strlen(*string);
+			return (char *)*string;
+		}
+	}
+
 	return NULL;
 }
 
 int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
 {
-	char *last_branch = substitute_nth_last_branch(&str, &len);
+	char *last_branch = substitute_branch(&str, &len);
 	const char **p, *r;
 	int refs_found = 0;
 
@@ -289,7 +303,7 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
 
 int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
 {
-	char *last_branch = substitute_nth_last_branch(&str, &len);
+	char *last_branch = substitute_branch(&str, &len);
 	const char **p;
 	int logs_found = 0;
 
-- 
1.6.2.1.422.g885ce.dirty
Andreas Gruenbacher· Mar 18, 2009, 21:41 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Introduce %<branch> as shortcut to the tracked branch

On Wednesday, 18 March 2009 22:12:19 Johannes Schindelin wrote:
> Suggested by Pasky.

Doesn't work here with git e986ceb, unfortunately. On branch master which is tracking origin/master, I get this:

	$ git log %..
	fatal: ambiguous argument '%..': unknown revision or path not in the
		working tree.
(There also is a trivial reject in hunk one as well.)

Thanks, Andreas

Johannes Schindelin· Mar 18, 2009, 21:46 UTC · re: Johannes Schindelin · lore

[PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Suggested by Pasky.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
	Arjen reminded me on IRC that I worked off of dscho/master instead 
	of junio/next...  D'oh.
 sha1_name.c |   21 +++++++++++++++++----
 1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 2f75179..cb4168d 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -5,6 +5,7 @@
 #include "blob.h"
 #include "tree-walk.h"
 #include "refs.h"
+#include "remote.h"
 
 static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
 {
@@ -240,9 +241,10 @@ static int ambiguous_path(const char *path, int len)
 
 /*
  * *string and *len will only be substituted, and *string returned (for
- * later free()ing) if the string passed in is of the form @{-<n>}.
+ * later free()ing) if the string passed in is of the form @{-<n>} or
+ * of the form %<branch>.
  */
-static char *substitute_nth_last_branch(const char **string, int *len)
+static char *substitute_branch(const char **string, int *len)
 {
 	struct strbuf buf = STRBUF_INIT;
 	int ret = interpret_nth_last_branch(*string, &buf);
@@ -254,12 +256,23 @@ static char *substitute_nth_last_branch(const char **string, int *len)
 		return (char *)*string;
 	}
 
+	if (**string == '%') {
+		struct branch *tracking = branch_get((*string)[1] ?
+			(*string) + 1 : NULL);
+
+		if (tracking->merge && tracking->merge[0]->dst) {
+			*string = xstrdup(tracking->merge[0]->dst);
+			*len = strlen(*string);
+			return (char *)*string;
+		}
+	}
+
 	return NULL;
 }
 
 int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
 {
-	char *last_branch = substitute_nth_last_branch(&str, &len);
+	char *last_branch = substitute_branch(&str, &len);
 	const char **p, *r;
 	int refs_found = 0;
 
@@ -288,7 +301,7 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
 
 int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
 {
-	char *last_branch = substitute_nth_last_branch(&str, &len);
+	char *last_branch = substitute_branch(&str, &len);
 	const char **p;
 	int logs_found = 0;
 
-- 
1.6.2.1.422.g885ce.dirty
Johannes Schindelin· Mar 18, 2009, 22:43 UTC · re: Andreas Gruenbacher · lore

Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Hi
On Wed, 18 Mar 2009, Andreas Gruenbacher wrote:
> On Wednesday, 18 March 2009 22:46:22 Johannes Schindelin wrote:
> > Suggested by Pasky.
> 
> Works here now. Thanks a lot!
You're welcome!  Was fun, too...

Ciao, Dscho

Junio C Hamano· Mar 18, 2009, 22:34 UTC · re: Johannes Schindelin · lore

Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Suggested by Pasky.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

In the longer term who suggested matters much less than why such a feature is desirable, how it is used, and without it what is impossible and/or cumbersome. What's the motivation behind this?

You do not have to explain it to me, but you should explain it to the history that records this commit, and to the users who read doccos.

Johannes Schindelin· Mar 18, 2009, 22:46 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Hi,
On Wed, 18 Mar 2009, Junio C Hamano wrote:
Show 12 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Suggested by Pasky.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> In the longer term who suggested matters much less than why such a 
> feature is desirable, how it is used, and without it what is impossible 
> and/or cumbersome.  What's the motivation behind this?
> 
> You do not have to explain it to me, but you should explain it to the 
> history that records this commit, and to the users who read doccos.

And that's not all... Documentation updates and tests for % and %<branch> are missing, too.

My main motivation to make this patch was to see how fast I could come up with something working that does not hurt my eyes.

But I do not have time to do more today: My main project as well as Git got accepted into the Google Summer of Code program, so I am even more swamped than usually.

So... if anybody feels like it, I would be very thankful for a proper commit message, documentation and tests...

Ciao, Dscho

Michael J Gruber· Mar 19, 2009, 14:52 UTC · re: Johannes Schindelin · lore

Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Johannes Schindelin venit, vidit, dixit 18.03.2009 23:46:
Show 29 quoted lines
> Hi,
> 
> On Wed, 18 Mar 2009, Junio C Hamano wrote:
> 
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> Suggested by Pasky.
>>>
>>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>
>> In the longer term who suggested matters much less than why such a 
>> feature is desirable, how it is used, and without it what is impossible 
>> and/or cumbersome.  What's the motivation behind this?
>>
>> You do not have to explain it to me, but you should explain it to the 
>> history that records this commit, and to the users who read doccos.
> 
> And that's not all... Documentation updates and tests for % and %<branch> 
> are missing, too.
> 
> My main motivation to make this patch was to see how fast I could come up 
> with something working that does not hurt my eyes.
> 
> But I do not have time to do more today: My main project as well as Git 
> got accepted into the Google Summer of Code program, so I am even more 
> swamped than usually.
> 
> So... if anybody feels like it, I would be very thankful for a proper 
> commit message, documentation and tests...

Just a quick note that I'm feeling like it... Though it seems this does not quite work with local branches, i.e. a branch created with

git checkout --track -b tracking tracked

with "tracked" being a local branch. I don't see why on first inspection of the code (branch.tracking.merge = refs/heads/tracked, so what), but maybe you will...

Michael
Michael J Gruber· Mar 19, 2009, 15:17 UTC · re: Michael J Gruber · lore

Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Michael J Gruber venit, vidit, dixit 19.03.2009 15:52:
Show 39 quoted lines
> Johannes Schindelin venit, vidit, dixit 18.03.2009 23:46:
>> Hi,
>>
>> On Wed, 18 Mar 2009, Junio C Hamano wrote:
>>
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>
>>>> Suggested by Pasky.
>>>>
>>>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>>
>>> In the longer term who suggested matters much less than why such a 
>>> feature is desirable, how it is used, and without it what is impossible 
>>> and/or cumbersome.  What's the motivation behind this?
>>>
>>> You do not have to explain it to me, but you should explain it to the 
>>> history that records this commit, and to the users who read doccos.
>>
>> And that's not all... Documentation updates and tests for % and %<branch> 
>> are missing, too.
>>
>> My main motivation to make this patch was to see how fast I could come up 
>> with something working that does not hurt my eyes.
>>
>> But I do not have time to do more today: My main project as well as Git 
>> got accepted into the Google Summer of Code program, so I am even more 
>> swamped than usually.
>>
>> So... if anybody feels like it, I would be very thankful for a proper 
>> commit message, documentation and tests...
> 
> Just a quick note that I'm feeling like it... Though it seems this does
> not quite work with local branches, i.e. a branch created with
> 
> git checkout --track -b tracking tracked
> 
> with "tracked" being a local branch. I don't see why on first inspection
> of the code (branch.tracking.merge = refs/heads/tracked, so what), but
> maybe you will...

So, for a local branch, branch_get() returns a branch without merge info even though it's in the config (the remote is "." here). "git branch --track" is specifically meant for (branching off a ) local branch, because it's the default for remote branches anyway. Right? Does not look right.

Michael
Johannes Schindelin· Mar 20, 2009, 00:23 UTC · re: Johannes Schindelin · lore

Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Hi,
On Wed, 18 Mar 2009, Johannes Schindelin wrote:
Show 17 quoted lines
> On Wed, 18 Mar 2009, Junio C Hamano wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > Suggested by Pasky.
> > >
> > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > 
> > In the longer term who suggested matters much less than why such a 
> > feature is desirable, how it is used, and without it what is impossible 
> > and/or cumbersome.  What's the motivation behind this?
> > 
> > You do not have to explain it to me, but you should explain it to the 
> > history that records this commit, and to the users who read doccos.
> 
> And that's not all... Documentation updates and tests for % and %<branch> 
> are missing, too.
Darn, darn, DARN!

Just when I squeezed that half an hour from the time I have to sleep, to provide documentation and tests, _just_ after I finished that, I got the idea that '%' might not be a 'bad ref char' after all.

And of course I was correct.
Just try this:
	$ git checkout -b %helloworld
and weep... so, no v3 of that patch, even if I have it right here.

Ciao, Dscho "who goes to bed being frustrated"

Johannes Schindelin· Mar 20, 2009, 00:38 UTC · re: Johannes Schindelin · lore

ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Hi,
On Fri, 20 Mar 2009, Johannes Schindelin wrote:
> Just try this:
> 
> 	$ git checkout -b %helloworld
It gets worse.  Much worse.
Try this (triggered by a comment by Ilari on IRC):
	$ git checkout -b '@{1}'
That _works_! WTH?

Ciao, Dscho

Shawn O. Pearce· Mar 20, 2009, 00:40 UTC · re: Johannes Schindelin · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 13 quoted lines
> On Fri, 20 Mar 2009, Johannes Schindelin wrote:
> 
> > Just try this:
> > 
> > 	$ git checkout -b %helloworld
> 
> It gets worse.  Much worse.
> 
> Try this (triggered by a comment by Ilari on IRC):
> 
> 	$ git checkout -b '@{1}'
> 
> That _works_! WTH?

'@' is not reserved. Neither is '{' or '}'. Neither is the combination.

Waaaaaay back when I added reflog query syntax I tried to use only '@', people with branch names like 'foo@bar' made a point that they didn't want to reserve it. We stuck the {} in as a "highly unlikely to conflict with a branch name" and others pointed out most shells will do fun things with those, but we kept it to avoid ambiguous meanings of "foo@noon" when foo@noon is already a branch.

Fast-forward more than 2 years, and the "@{...}" syntax is quite widely used, perhaps more so than "@" in a branch name. But its still not reserved.

So yea, you can create a branch named "foo@{1}".
$ git branch foo@{1}
$ git branch
  cache-walk
  foo@{1}
  master
* mergebase-bug
  mw/blame
  rr/compareeditor
  transport-mirror
  worktree-api
  worktree-edit
Yay.
-- 
Shawn.
Shawn O. Pearce· Mar 20, 2009, 00:44 UTC · re: Shawn O. Pearce · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

"Shawn O. Pearce" <spearce@spearce.org> wrote:
Show 17 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Fri, 20 Mar 2009, Johannes Schindelin wrote:
> > 
> > > Just try this:
> > > 
> > > 	$ git checkout -b %helloworld
> > 
> > It gets worse.  Much worse.
> > 
> > Try this (triggered by a comment by Ilari on IRC):
> > 
> > 	$ git checkout -b '@{1}'
> > 
> > That _works_! WTH?
> 
> '@' is not reserved.  Neither is '{' or '}'.  Neither is
> the combination.

In hindsight, I wish we had reserved all of the "fun" characters like !@#$%^&*():;~'"\ and prevented them from ever appearing in a ref name.

Instead only what check_ref_format() in refs.c ll.694 tells is is reserved:

 671 /*
 672  * Make sure "ref" is something reasonable to have under ".git/refs/";
 673  * We do not like it if:
 674  *
 675  * - any path component of it begins with ".", or
 676  * - it has double dots "..", or
 677  * - it has ASCII control character, "~", "^", ":" or SP, anywhere, or
 678  * - it ends with a "/".
 679  */
Heh.  At least : and SP are reserved.
Use BEL for your %helloworld hack.  It'll be fun to type.  :-)
-- 
Shawn.
Sverre Rabbelier· Mar 20, 2009, 05:59 UTC · re: Shawn O. Pearce · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Heya,
On Fri, Mar 20, 2009 at 01:44, Shawn O. Pearce <spearce@spearce.org> wrote:
> In hindsight, I wish we had reserved all of the "fun" characters
> like !@#$%^&*():;~'"\ and prevented them from ever appearing in a
> ref name.

Maybe we should add a --pedantic which whines when you use any of those in a branch name; oh wait, wrong project... :P.

-- 
Cheers,

Sverre Rabbelier
Johannes Schindelin· Mar 20, 2009, 09:29 UTC · re: Shawn O. Pearce · lore

[PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch

Often, it is quite interesting to inspect the branch tracked by a given branch. This patch introduces a nice notation to get at the tracked branch: 'BEL<branch>' can be used to access that tracked branch.

A special shortcut 'BEL' refers to the branch tracked by the current branch.
Suggested by Pasky and Shawn.

This patch extends the function introduced to handle the nth-last branch (via the {-<n>} notation); therefore that function name was renamed to something more general.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
	On Thu, 19 Mar 2009, Shawn O. Pearce wrote:
	> Use BEL for your %helloworld hack.
	Here you are.
 Documentation/git-rev-parse.txt |    3 ++
 sha1_name.c                     |   21 ++++++++++++---
 t/t1506-rev-parse-tracked.sh    |   54 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 74 insertions(+), 4 deletions(-)
 create mode 100755 t/t1506-rev-parse-tracked.sh
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 5ed2bc8..a4bcd5e 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -215,6 +215,9 @@ when you run 'git-merge'.
 * The special construct '@\{-<n>\}' means the <n>th branch checked out
   before the current one.
 
+* The prefix 'BEL' to a ref means the branch tracked by that ref.  If no
+  ref was specified, it means the branch tracked by the current branch.
+
 * A suffix '{caret}' to a revision parameter means the first parent of
   that commit object.  '{caret}<n>' means the <n>th parent (i.e.
   'rev{caret}'
diff --git a/sha1_name.c b/sha1_name.c
index 2f75179..cb4168d 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -5,6 +5,7 @@
 #include "blob.h"
 #include "tree-walk.h"
 #include "refs.h"
+#include "remote.h"
 
 static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
 {
@@ -240,9 +241,10 @@ static int ambiguous_path(const char *path, int len)
 
 /*
  * *string and *len will only be substituted, and *string returned (for
- * later free()ing) if the string passed in is of the form @{-<n>}.
+ * later free()ing) if the string passed in is of the form @{-<n>} or
+ * of the form BEL<branch>.
  */
-static char *substitute_nth_last_branch(const char **string, int *len)
+static char *substitute_branch(const char **string, int *len)
 {
 	struct strbuf buf = STRBUF_INIT;
 	int ret = interpret_nth_last_branch(*string, &buf);
@@ -254,12 +256,23 @@ static char *substitute_nth_last_branch(const char **string, int *len)
 		return (char *)*string;
 	}
 
+	if (**string == '\007') {
+		struct branch *tracking = branch_get((*string)[1] ?
+			(*string) + 1 : NULL);
+
+		if (tracking->merge && tracking->merge[0]->dst) {
+			*string = xstrdup(tracking->merge[0]->dst);
+			*len = strlen(*string);
+			return (char *)*string;
+		}
+	}
+
 	return NULL;
 }
 
 int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
 {
-	char *last_branch = substitute_nth_last_branch(&str, &len);
+	char *last_branch = substitute_branch(&str, &len);
 	const char **p, *r;
 	int refs_found = 0;
 
@@ -288,7 +301,7 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
 
 int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
 {
-	char *last_branch = substitute_nth_last_branch(&str, &len);
+	char *last_branch = substitute_branch(&str, &len);
 	const char **p;
 	int logs_found = 0;
 
diff --git a/t/t1506-rev-parse-tracked.sh b/t/t1506-rev-parse-tracked.sh
new file mode 100755
index 0000000..359f648
--- /dev/null
+++ b/t/t1506-rev-parse-tracked.sh
@@ -0,0 +1,54 @@
+#!/bin/sh
+
+test_description='test BEL<branch> syntax'
+
+. ./test-lib.sh
+
+
+test_expect_success 'setup' '
+
+	test_commit 1 &&
+	git checkout -b side &&
+	test_commit 2 &&
+	git checkout master &&
+	git clone . clone &&
+	test_commit 3 &&
+	(cd clone &&
+	 test_commit 4 &&
+	 git branch --track my-side origin/side)
+
+'
+
+full_name () {
+	(cd clone &&
+	 git rev-parse --symbolic-full-name "$@")
+}
+
+commit_subject () {
+	(cd clone &&
+	 git show -s --pretty=format:%s "$@")
+}
+
+test_expect_success 'BEL resolves to correct full name' '
+
+	test refs/remotes/origin/master = "$(full_name "$(echo -e '\007')")"
+
+'
+
+test_expect_success 'BELmy-side resolves to correct full name' '
+
+	test refs/remotes/origin/side = "$(full_name "$(echo -e '\007')"my-side)"
+
+'
+
+test_expect_success 'BELmy-side resolves to correct commit' '
+
+	git checkout side &&
+	test_commit 5 &&
+	(cd clone && git fetch) &&
+	test 2 = "$(commit_subject my-side)" &&
+	test 5 = "$(commit_subject "$(echo -e '\007')"my-side)"
+
+'
+
+test_done
-- 
1.6.2.1.477.g74567
Wincent Colaiuta· Mar 20, 2009, 09:42 UTC · re: Johannes Schindelin · lore

Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch

El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
Show 10 quoted lines
>
> Often, it is quite interesting to inspect the branch tracked by a  
> given
> branch.  This patch introduces a nice notation to get at the tracked
> branch: 'BEL<branch>' can be used to access that tracked branch.
>
> A special shortcut 'BEL' refers to the branch tracked by the current  
> branch.
>
> Suggested by Pasky and Shawn.

What does BEL actually stand for? I read Shawn's suggestion, but it's not immediately clear to me what "BEL" means.

Cheers, Wincent

Johannes Schindelin· Mar 20, 2009, 09:54 UTC · re: Wincent Colaiuta · lore

Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch

Hi,
On Fri, 20 Mar 2009, Wincent Colaiuta wrote:
Show 13 quoted lines
> El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
> 
> >
> >Often, it is quite interesting to inspect the branch tracked by a given
> >branch.  This patch introduces a nice notation to get at the tracked
> >branch: 'BEL<branch>' can be used to access that tracked branch.
> >
> >A special shortcut 'BEL' refers to the branch tracked by the current branch.
> >
> >Suggested by Pasky and Shawn.
> 
> What does BEL actually stand for? I read Shawn's suggestion, but it's not
> immediately clear to me what "BEL" means.

It is the ASCII "bell" character, 007 (I always wanted to write that magic identifier into a patch).

FWIW you could type it in a regular ANSI terminal using Control-v Control-g.

Ciao, Dscho

Santi Béjar· Mar 20, 2009, 12:33 UTC · re: Johannes Schindelin · lore

Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch

2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
Show 23 quoted lines
> Hi,
>
> On Fri, 20 Mar 2009, Wincent Colaiuta wrote:
>
>> El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
>>
>> >
>> >Often, it is quite interesting to inspect the branch tracked by a given
>> >branch.  This patch introduces a nice notation to get at the tracked
>> >branch: 'BEL<branch>' can be used to access that tracked branch.
>> >
>> >A special shortcut 'BEL' refers to the branch tracked by the current branch.
>> >
>> >Suggested by Pasky and Shawn.
>>
>> What does BEL actually stand for? I read Shawn's suggestion, but it's not
>> immediately clear to me what "BEL" means.
>
> It is the ASCII "bell" character, 007 (I always wanted to write that
> magic identifier into a patch).
>
> FWIW you could type it in a regular ANSI terminal using Control-v
> Control-g.

Can we use branch^{origin} instead? It is longer to type, but uses the same syntax as the ^{tree}, ^{commit}, ^{tag} and you don't have to know how to produce the bell character.

2 cents, Santi

Andreas Gruenbacher· Mar 20, 2009, 12:45 UTC · re: Santi Béjar · lore

Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch

On Friday, 20 March 2009 13:33:18 Santi Béjar wrote:
> Can we use branch^{origin} instead? It is longer to type, but uses the
> same syntax as the ^{tree}, ^{commit}, ^{tag} and you don't have to
> know how to produce the bell character.

For me this defeats the purpose; I can just as well type origin/branch (or whatever it is) instead of branch^{origin}. I'm really looking for something very short like % or %branch.

A notation for referring to the tracked branch in arbitrary contexts still sounds like a good idea, and for that purpose, your proposal sounds useful.

Thanks, Andreas

Matthieu Moy· Mar 20, 2009, 13:05 UTC · re: Andreas Gruenbacher · lore

Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch

Andreas Gruenbacher <agruen@suse.de> writes:
> For me this defeats the purpose; I can just as well type origin/branch (or 
> whatever it is) instead of branch^{origin}.  I'm really looking for something 
> very short like % or %branch.

I was thinking of ../branch (so, replace % with ../ in your patch, roughly). The cool thing is that my fingers are used to ../ already. The bad things are 1) not sure the "analogy" with .. in filesystem is good, and 2) this interacts badly with ref..branch. ref..%branch was cool, ref..../branch is less cool.

Or is //branch an idea?
My 2 cents,
-- 
Matthieu
Johannes Schindelin· Mar 20, 2009, 12:46 UTC · re: Santi Béjar · lore

Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch

Hi,
On Fri, 20 Mar 2009, Santi Béjar wrote:
Show 28 quoted lines
> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Fri, 20 Mar 2009, Wincent Colaiuta wrote:
> >
> >> El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
> >>
> >> >Often, it is quite interesting to inspect the branch tracked by a 
> >> >given branch.  This patch introduces a nice notation to get at the 
> >> >tracked branch: 'BEL<branch>' can be used to access that tracked 
> >> >branch.
> >> >
> >> >A special shortcut 'BEL' refers to the branch tracked by the current 
> >> >branch.
> >> >
> >> >Suggested by Pasky and Shawn.
> >>
> >> What does BEL actually stand for? I read Shawn's suggestion, but it's 
> >> not immediately clear to me what "BEL" means.
> >
> > It is the ASCII "bell" character, 007 (I always wanted to write that 
> > magic identifier into a patch).
> >
> > FWIW you could type it in a regular ANSI terminal using Control-v 
> > Control-g.
> 
> Can we use branch^{origin} instead? It is longer to type, but uses the 
> same syntax as the ^{tree}, ^{commit}, ^{tag} and you don't have to know 
> how to produce the bell character.
I think I addressed that issue already.  (Summary: I do not like it)

Let me spell it out if it was not obvious yet: the BEL patch was meant as a more or less funny reminder that the issue is not solved and that I need help.

Ciao, Dscho

Mikael Magnusson· Mar 20, 2009, 12:53 UTC · re: Johannes Schindelin · lore

Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch

2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
Show 38 quoted lines
> Hi,
>
> On Fri, 20 Mar 2009, Santi Béjar wrote:
>
>> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>
>> > On Fri, 20 Mar 2009, Wincent Colaiuta wrote:
>> >
>> >> El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
>> >>
>> >> >Often, it is quite interesting to inspect the branch tracked by a
>> >> >given branch.  This patch introduces a nice notation to get at the
>> >> >tracked branch: 'BEL<branch>' can be used to access that tracked
>> >> >branch.
>> >> >
>> >> >A special shortcut 'BEL' refers to the branch tracked by the current
>> >> >branch.
>> >> >
>> >> >Suggested by Pasky and Shawn.
>> >>
>> >> What does BEL actually stand for? I read Shawn's suggestion, but it's
>> >> not immediately clear to me what "BEL" means.
>> >
>> > It is the ASCII "bell" character, 007 (I always wanted to write that
>> > magic identifier into a patch).
>> >
>> > FWIW you could type it in a regular ANSI terminal using Control-v
>> > Control-g.
>>
>> Can we use branch^{origin} instead? It is longer to type, but uses the
>> same syntax as the ^{tree}, ^{commit}, ^{tag} and you don't have to know
>> how to produce the bell character.
>
> I think I addressed that issue already.  (Summary: I do not like it)
>
> Let me spell it out if it was not obvious yet: the BEL patch was meant as
> a more or less funny reminder that the issue is not solved and that I need
> help.

Would :%:foo work? I thought about the reserved prefix :/! , but :/!! isn't reserved so I don't think that would work. And it's pretty annoying to type too.

-- 
Mikael Magnusson
Johannes Schindelin· Mar 20, 2009, 14:00 UTC · re: Mikael Magnusson · lore

Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch

Hi,
On Fri, 20 Mar 2009, Mikael Magnusson wrote:
Show 42 quoted lines
> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Fri, 20 Mar 2009, Santi Béjar wrote:
> >
> >> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >>
> >> > On Fri, 20 Mar 2009, Wincent Colaiuta wrote:
> >> >
> >> >> El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
> >> >>
> >> >> >Often, it is quite interesting to inspect the branch tracked by a
> >> >> >given branch.  This patch introduces a nice notation to get at the
> >> >> >tracked branch: 'BEL<branch>' can be used to access that tracked
> >> >> >branch.
> >> >> >
> >> >> >A special shortcut 'BEL' refers to the branch tracked by the current
> >> >> >branch.
> >> >> >
> >> >> >Suggested by Pasky and Shawn.
> >> >>
> >> >> What does BEL actually stand for? I read Shawn's suggestion, but it's
> >> >> not immediately clear to me what "BEL" means.
> >> >
> >> > It is the ASCII "bell" character, 007 (I always wanted to write that
> >> > magic identifier into a patch).
> >> >
> >> > FWIW you could type it in a regular ANSI terminal using Control-v
> >> > Control-g.
> >>
> >> Can we use branch^{origin} instead? It is longer to type, but uses the
> >> same syntax as the ^{tree}, ^{commit}, ^{tag} and you don't have to know
> >> how to produce the bell character.
> >
> > I think I addressed that issue already.  (Summary: I do not like it)
> >
> > Let me spell it out if it was not obvious yet: the BEL patch was meant as
> > a more or less funny reminder that the issue is not solved and that I need
> > help.
> 
> Would :%:foo work? I thought about the reserved prefix :/! , but :/!! 
> isn't reserved so I don't think that would work. And it's pretty 
> annoying to type too.
Or maybe :%foo?

That would have a rather nasty interaction with code I have in my tree to refer to the cache-trees via ':<path>', but I guess I can live with that.

Ciao, Dscho

Michael J Gruber· Mar 20, 2009, 10:04 UTC · re: Johannes Schindelin · lore

[PATCH] Document and test the new % shotcut for the tracked branch

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Johannes Schindelin venit, vidit, dixit 20.03.2009 10:29:
Show 14 quoted lines
> 
> Often, it is quite interesting to inspect the branch tracked by a given
> branch.  This patch introduces a nice notation to get at the tracked
> branch: 'BEL<branch>' can be used to access that tracked branch.
> 
> A special shortcut 'BEL' refers to the branch tracked by the current branch.
> 
> Suggested by Pasky and Shawn.
> 
> This patch extends the function introduced to handle the nth-last branch
> (via the {-<n>} notation); therefore that function name was renamed to
> something more general.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
I guess you beat me to it then, which is fine.

But haven't you seen my note about the failing test either? The code below tests with branches which track local branches. merge and remote is set for the branch in question ("tracking"), it's just that remote is ".". It seems that the remote.c code does not set up merge info for these branches.

<Goes to figure out how to enter BEL...>
 Documentation/git-rev-parse.txt |    3 ++
 t/t1506-rev-parse-track.sh      |   60 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 63 insertions(+), 0 deletions(-)
 create mode 100755 t/t1506-rev-parse-track.sh
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 5ed2bc8..dafcfe8 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -215,6 +215,9 @@ when you run 'git-merge'.
 * The special construct '@\{-<n>\}' means the <n>th branch checked out
   before the current one.
 
+* A prefix '%', optionally followed by a branchname '<branch>', means the
+  branch tracked by '<branch>'. '<branch>' defaults to the current branch.
+
 * A suffix '{caret}' to a revision parameter means the first parent of
   that commit object.  '{caret}<n>' means the <n>th parent (i.e.
   'rev{caret}'
diff --git a/t/t1506-rev-parse-track.sh b/t/t1506-rev-parse-track.sh
new file mode 100755
index 0000000..1ca1dd6
--- /dev/null
+++ b/t/t1506-rev-parse-track.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+test_description='test % syntax'
+
+. ./test-lib.sh
+
+
+make_commit () {
+	echo "$1" > "$1" &&
+	git add "$1" &&
+	git commit -m "$1"
+}
+
+
+test_expect_success 'setup' '
+
+	make_commit 1 &&
+	git branch tracked &&
+	make_commit 2 &&
+	git checkout tracked &&
+	make_commit 3 &&
+	git checkout --track -b tracking tracked
+	make_commit 4 &&
+	git checkout master
+
+'
+
+# tracking tracks tracked
+# master does not track anything
+# all three point at different commits
+
+test_rev_equivalent () {
+
+	git rev-parse "$1" > expect &&
+	git rev-parse "$2" > output &&
+	test_cmp expect output
+
+}
+
+test_expect_success '%trackingbranch works' '
+	test_rev_equivalent tracked %tracking
+'
+
+test_expect_success '% works in tracking branch' '
+	git checkout tracking &&
+	test_rev_equivalent tracked %
+'
+
+test_expect_success '%nontrackingbranch fails' '
+	test_must_fail git rev-parse %tracked
+'
+
+test_expect_success '% fails in non-tracking branch' '
+	git checkout tracked &&
+	test_must_fail git rev-parse %
+'
+
+test_done
+
+
-- 
1.6.2.149.g6462
Johannes Schindelin· Mar 20, 2009, 10:31 UTC · re: Michael J Gruber · lore

Re: [PATCH] Document and test the new % shotcut for the tracked branch

Hi,
On Fri, 20 Mar 2009, Michael J Gruber wrote:
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
That is brutal.  First shot, then cut.
Show 19 quoted lines
> Johannes Schindelin venit, vidit, dixit 20.03.2009 10:29:
> > 
> > Often, it is quite interesting to inspect the branch tracked by a 
> > given branch.  This patch introduces a nice notation to get at the 
> > tracked branch: 'BEL<branch>' can be used to access that tracked 
> > branch.
> > 
> > A special shortcut 'BEL' refers to the branch tracked by the current 
> > branch.
> > 
> > Suggested by Pasky and Shawn.
> > 
> > This patch extends the function introduced to handle the nth-last 
> > branch (via the {-<n>} notation); therefore that function name was 
> > renamed to something more general.
> > 
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> I guess you beat me to it then, which is fine.

I had it ready yesterday! But the real problem is not addressed by your patch, either: '%<branch>' is a legal branch name.

I briefly considered <branch>^{tracked}, but
- the ^{} codepath does not try to substitute branch _names_, so we'd have 
  to duplicate that ^{} detection, and,
- it is really cumbersome to write.
Show 5 quoted lines
> But haven't you seen my note about the failing test either? The code 
> below tests with branches which track local branches. merge and remote 
> is set for the branch in question ("tracking"), it's just that remote is 
> ".". It seems that the remote.c code does not set up merge info for 
> these branches.
I have seen it, it's just not my itch, and I am busy enough as it is.
> <Goes to figure out how to enter BEL...>
Ctrl-v Ctrl-g

Ciao, Dscho

Michael J Gruber· Mar 20, 2009, 10:38 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Document and test the new % shotcut for the tracked branch

Johannes Schindelin venit, vidit, dixit 20.03.2009 11:31:
Show 8 quoted lines
> Hi,
> 
> On Fri, 20 Mar 2009, Michael J Gruber wrote:
> 
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
> 
> That is brutal.  First shot, then cut.
I'm sorry! But you're a tough guy, you'll recover...
Show 23 quoted lines
> 
>> Johannes Schindelin venit, vidit, dixit 20.03.2009 10:29:
>>>
>>> Often, it is quite interesting to inspect the branch tracked by a 
>>> given branch.  This patch introduces a nice notation to get at the 
>>> tracked branch: 'BEL<branch>' can be used to access that tracked 
>>> branch.
>>>
>>> A special shortcut 'BEL' refers to the branch tracked by the current 
>>> branch.
>>>
>>> Suggested by Pasky and Shawn.
>>>
>>> This patch extends the function introduced to handle the nth-last 
>>> branch (via the {-<n>} notation); therefore that function name was 
>>> renamed to something more general.
>>>
>>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>
>> I guess you beat me to it then, which is fine.
> 
> I had it ready yesterday!  But the real problem is not addressed by your 
> patch, either: '%<branch>' is a legal branch name.

No, of course, I just added doc+test to your patch v2, since you seemed to encourage people to do so.

I would have sent it out yesterday if my tests hadn't shown a problem. (Or did you misunderstand my doc notation? <branch> = ${branch} = "branch" placeholder for a generic branch name)

Show 14 quoted lines
> I briefly considered <branch>^{tracked}, but
> 
> - the ^{} codepath does not try to substitute branch _names_, so we'd have 
>   to duplicate that ^{} detection, and,
> 
> - it is really cumbersome to write.
> 
>> But haven't you seen my note about the failing test either? The code 
>> below tests with branches which track local branches. merge and remote 
>> is set for the branch in question ("tracking"), it's just that remote is 
>> ".". It seems that the remote.c code does not set up merge info for 
>> these branches.
> 
> I have seen it, it's just not my itch, and I am busy enough as it is.

If I'm not totally off-track (which I may well be) then that problem should show up with other uses of the merge/track setting as well. I guess it's just that everyone tracks remote branches, not local ones.

I'll see if I have time...
Show 6 quoted lines
>> <Goes to figure out how to enter BEL...>
> 
> Ctrl-v Ctrl-g
> 
> Ciao,
> Dscho
Bing bing bing...
Michael
Petr Baudis· Mar 20, 2009, 11:16 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Document and test the new % shotcut for the tracked branch

  Hi!
On Fri, Mar 20, 2009 at 11:31:31AM +0100, Johannes Schindelin wrote:
Show 9 quoted lines
> I had it ready yesterday!  But the real problem is not addressed by your 
> patch, either: '%<branch>' is a legal branch name.
> 
> I briefly considered <branch>^{tracked}, but
> 
> - the ^{} codepath does not try to substitute branch _names_, so we'd have 
>   to duplicate that ^{} detection, and,
> 
> - it is really cumbersome to write.

We already have @{N} to do one branch-based substitution, so what about following this convention? Can't we have @{t}?

				Petr "Pasky" Baudis
Johannes Schindelin· Mar 20, 2009, 11:48 UTC · re: Petr Baudis · lore

Re: [PATCH] Document and test the new % shotcut for the tracked branch

Hi,
On Fri, 20 Mar 2009, Petr Baudis wrote:
Show 13 quoted lines
> On Fri, Mar 20, 2009 at 11:31:31AM +0100, Johannes Schindelin wrote:
> > I had it ready yesterday!  But the real problem is not addressed by 
> > your patch, either: '%<branch>' is a legal branch name.
> > 
> > I briefly considered <branch>^{tracked}, but
> > 
> > - the ^{} codepath does not try to substitute branch _names_, so we'd 
> >   have to duplicate that ^{} detection, and,
> > 
> > - it is really cumbersome to write.
> 
> We already have @{N} to do one branch-based substitution, so what about 
> following this convention? Can't we have @{t}?

Have you ever tried a German keyboard layout? You would not say that @{} is easy to write if you did.

Besides, @{<string>} is already taken for the date-based reflog.

Ciao, Dscho

Petr Baudis· Mar 22, 2009, 17:40 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Document and test the new % shotcut for the tracked branch

On Fri, Mar 20, 2009 at 12:48:50PM +0100, Johannes Schindelin wrote:
Show 20 quoted lines
> Hi,
> 
> On Fri, 20 Mar 2009, Petr Baudis wrote:
> 
> > On Fri, Mar 20, 2009 at 11:31:31AM +0100, Johannes Schindelin wrote:
> > > I had it ready yesterday!  But the real problem is not addressed by 
> > > your patch, either: '%<branch>' is a legal branch name.
> > > 
> > > I briefly considered <branch>^{tracked}, but
> > > 
> > > - the ^{} codepath does not try to substitute branch _names_, so we'd 
> > >   have to duplicate that ^{} detection, and,
> > > 
> > > - it is really cumbersome to write.
> > 
> > We already have @{N} to do one branch-based substitution, so what about 
> > following this convention? Can't we have @{t}?
> 
> Have you ever tried a German keyboard layout?  You would not say that @{} 
> is easy to write if you did.

Interesting, do you really use the regular German keyboard layout while working in shell or programming? Most Czech people I know [*] use either the USA layout or Czech programming layout.

> Besides, @{<string>} is already taken for the date-based reflog.
Yes, but some strings can never be dates. ;-)

Has our ref-shed painting fest reached any conclusion yet? I'm not fond of spending more one-off sequences (~, //, ../, ...) on this, or anything containing a colon (too confusing, IMHO). It would be nice to get some generic escaping syntax.

The cleanest way I can think of is declaring ~ a special character and having <ref>~<letter> as a generic way for ref-based expansions; master~t would then expand to tracked branch of master.

The only(?) downside is that to mangle HEAD ref, you should write \~t (but you won't notice your mistake until user 't' appears), but that's a tough call...

(Should HEAD~t -> $HEAD~t -> master~t -> origin/master or rather HEAD~t -> origin/HEAD? The former is more intuitive, I guess.)

[*] Since most Czech people I know are UNIX users, it seems...
-- 
				Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
Michael J Gruber· Mar 20, 2009, 14:15 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Document and test the new % shotcut for the tracked branch

Johannes Schindelin venit, vidit, dixit 20.03.2009 11:31:
Show 8 quoted lines
> Hi,
> 
> On Fri, 20 Mar 2009, Michael J Gruber wrote:
> 
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
> 
> That is brutal.  First shot, then cut.

Oh my gosh, noooow I got it! Better late than never. You really have a thing with typos... Although not quoting the subject was not fair ;)

Cheers, Michael

Johannes Schindelin· Mar 20, 2009, 16:17 UTC · re: Johannes Schindelin · lore

[PATCH v4] Introduce %<branch> as shortcut to the tracked branch

Often, it is quite interesting to inspect the branch tracked by a given branch. This patch introduces a nice notation to get at the tracked branch: '%<branch>' can be used to access that tracked branch.

A special shortcut '%' refers to the branch tracked by the current branch.
Suggested by Pasky.

Even if a branch name can legally start with a '%' sign, we can use the special character '%' here, as you can always specify the full ref: refs/heads/%my-branch (pointed out by doener on IRC).

This patch extends the function introduced to handle the nth-last branch (via the {-<n>} notation); therefore that function name was renamed to something more general.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
	Sometimes IRC is awesome.  Knowing that you can always access an
	otherwise-hidden branch using the full name, I am now fully
	comfortable with '%[<branch>]'.
 Documentation/git-rev-parse.txt |    3 ++
 sha1_name.c                     |   21 ++++++++++++---
 t/t1506-rev-parse-tracked.sh    |   54 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 74 insertions(+), 4 deletions(-)
 create mode 100755 t/t1506-rev-parse-tracked.sh
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 5ed2bc8..a4bcd5e 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -215,6 +215,9 @@ when you run 'git-merge'.
 * The special construct '@\{-<n>\}' means the <n>th branch checked out
   before the current one.
 
+* The prefix '%' to a ref means the branch tracked by that ref.  If no
+  ref was specified, it means the branch tracked by the current branch.
+
 * A suffix '{caret}' to a revision parameter means the first parent of
   that commit object.  '{caret}<n>' means the <n>th parent (i.e.
   'rev{caret}'
diff --git a/sha1_name.c b/sha1_name.c
index 2f75179..cb4168d 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -5,6 +5,7 @@
 #include "blob.h"
 #include "tree-walk.h"
 #include "refs.h"
+#include "remote.h"
 
 static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
 {
@@ -240,9 +241,10 @@ static int ambiguous_path(const char *path, int len)
 
 /*
  * *string and *len will only be substituted, and *string returned (for
- * later free()ing) if the string passed in is of the form @{-<n>}.
+ * later free()ing) if the string passed in is of the form @{-<n>} or
+ * of the form %<branch>.
  */
-static char *substitute_nth_last_branch(const char **string, int *len)
+static char *substitute_branch(const char **string, int *len)
 {
 	struct strbuf buf = STRBUF_INIT;
 	int ret = interpret_nth_last_branch(*string, &buf);
@@ -254,12 +256,23 @@ static char *substitute_nth_last_branch(const char **string, int *len)
 		return (char *)*string;
 	}
 
+	if (**string == '%') {
+		struct branch *tracking = branch_get((*string)[1] ?
+			(*string) + 1 : NULL);
+
+		if (tracking->merge && tracking->merge[0]->dst) {
+			*string = xstrdup(tracking->merge[0]->dst);
+			*len = strlen(*string);
+			return (char *)*string;
+		}
+	}
+
 	return NULL;
 }
 
 int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
 {
-	char *last_branch = substitute_nth_last_branch(&str, &len);
+	char *last_branch = substitute_branch(&str, &len);
 	const char **p, *r;
 	int refs_found = 0;
 
@@ -288,7 +301,7 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
 
 int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
 {
-	char *last_branch = substitute_nth_last_branch(&str, &len);
+	char *last_branch = substitute_branch(&str, &len);
 	const char **p;
 	int logs_found = 0;
 
diff --git a/t/t1506-rev-parse-tracked.sh b/t/t1506-rev-parse-tracked.sh
new file mode 100755
index 0000000..359f648
--- /dev/null
+++ b/t/t1506-rev-parse-tracked.sh
@@ -0,0 +1,54 @@
+#!/bin/sh
+
+test_description='test %<branch> syntax'
+
+. ./test-lib.sh
+
+
+test_expect_success 'setup' '
+
+	test_commit 1 &&
+	git checkout -b side &&
+	test_commit 2 &&
+	git checkout master &&
+	git clone . clone &&
+	test_commit 3 &&
+	(cd clone &&
+	 test_commit 4 &&
+	 git branch --track my-side origin/side)
+
+'
+
+full_name () {
+	(cd clone &&
+	 git rev-parse --symbolic-full-name "$@")
+}
+
+commit_subject () {
+	(cd clone &&
+	 git show -s --pretty=format:%s "$@")
+}
+
+test_expect_success '% resolves to correct full name' '
+
+	test refs/remotes/origin/master = "$(full_name %)"
+
+'
+
+test_expect_success '%my-side resolves to correct full name' '
+
+	test refs/remotes/origin/side = "$(full_name %my-side)"
+
+'
+
+test_expect_success '%my-side resolves to correct commit' '
+
+	git checkout side &&
+	test_commit 5 &&
+	(cd clone && git fetch) &&
+	test 2 = "$(commit_subject my-side)" &&
+	test 5 = "$(commit_subject %my-side)"
+
+'
+
+test_done
-- 
1.6.2.1.477.g74567
Junio C Hamano· Mar 20, 2009, 17:03 UTC · re: Johannes Schindelin · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 11 quoted lines
> Often, it is quite interesting to inspect the branch tracked by a given
> branch.  This patch introduces a nice notation to get at the tracked
> branch: '%<branch>' can be used to access that tracked branch.
>
> A special shortcut '%' refers to the branch tracked by the current branch.
>
> Suggested by Pasky.
>
> Even if a branch name can legally start with a '%' sign, we can use the
> special character '%' here, as you can always specify the full ref:
> refs/heads/%my-branch (pointed out by doener on IRC).

That is not a good argument, as %<name> is (just like name@{-n} is) a substitute way to spell the "name" of a branch, not just a random SHA-1, and to some commands it makes a difference between <branchname> and refs/heads/<branchname>. The latter is not giving the name of the branch, but merely a commit object name.

An most obvious one is that "git checkout branchname" and "git checkout refs/heads/branchname" behave differently. You cannot checkout a branch called %master after this patch goes in.

Just be honest and say "You may have a branch whose name begins with a '%' and you cannot refer to it anymore in certain contexts. Too bad. Don't do it next time you create a new branch". I _can_ buy that argument.

It however asks for a sane escape hatch. You cannot "fix" such branch names in most obvious ways (if you could, that would be a bug in this % feature).

 (1) git branch -m %master percent-master
     We would end up renaming what master tracks to new name.
 (2) git branch percent-master refs/heads/%master; git branch -d %master
     The first part is a good try, but the latter deletes what master
     tracks.

"git update-ref -d refs/heads/%master" needs to replace the second step of the latter.

Johannes Schindelin· Mar 20, 2009, 17:32 UTC · re: Junio C Hamano · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

Hi,
On Fri, 20 Mar 2009, Junio C Hamano wrote:
Show 27 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Often, it is quite interesting to inspect the branch tracked by a given
> > branch.  This patch introduces a nice notation to get at the tracked
> > branch: '%<branch>' can be used to access that tracked branch.
> >
> > A special shortcut '%' refers to the branch tracked by the current branch.
> >
> > Suggested by Pasky.
> >
> > Even if a branch name can legally start with a '%' sign, we can use the
> > special character '%' here, as you can always specify the full ref:
> > refs/heads/%my-branch (pointed out by doener on IRC).
> 
> That is not a good argument, as %<name> is (just like name@{-n} is) a
> substitute way to spell the "name" of a branch, not just a random SHA-1,
> and to some commands it makes a difference between <branchname> and
> refs/heads/<branchname>.  The latter is not giving the name of the branch,
> but merely a commit object name.
> 
> An most obvious one is that "git checkout branchname" and "git checkout
> refs/heads/branchname" behave differently.  You cannot checkout a branch
> called %master after this patch goes in.
> 
> Just be honest and say "You may have a branch whose name begins with a '%'
> and you cannot refer to it anymore in certain contexts.  Too bad.  Don't
> do it next time you create a new branch".  I _can_ buy that argument.

Be that as it may, at this point I kick the ball back to the interested parties. I did my duty.

Ciao, Dscho

Junio C Hamano· Mar 20, 2009, 18:02 UTC · re: Junio C Hamano · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

Junio C Hamano <gitster@pobox.com> writes:
Show 19 quoted lines
> Just be honest and say "You may have a branch whose name begins with a '%'
> and you cannot refer to it anymore in certain contexts.  Too bad.  Don't
> do it next time you create a new branch".  I _can_ buy that argument.
>
> It however asks for a sane escape hatch.  You cannot "fix" such branch
> names in most obvious ways (if you could, that would be a bug in this %
> feature).
>
>  (1) git branch -m %master percent-master
>
>      We would end up renaming what master tracks to new name.
>
>  (2) git branch percent-master refs/heads/%master; git branch -d %master
>
>      The first part is a good try, but the latter deletes what master
>      tracks.
>
> "git update-ref -d refs/heads/%master" needs to replace the second step of
> the latter.
A naïve question.

Has nobody suggested to use a really illegal characters such as ':' instead? After all, we are not talking something that you can use in refspecs but another way to spell branch names.

Alternatively, '~master' may have a nice connotation that means "where master calls its home".

I haven't looked at the patch deeply yet, but what does the failure case do? I think we should die() if %master is asked for and master is not merging from anywhere by default (similarly, if @{-4} is asked and we haven't switched that many times, we should die(), although I do not remember how I coded that codepath---I presume it's the same codepath you are touching with this round).

Jeff King· Mar 20, 2009, 19:36 UTC · re: Junio C Hamano · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

On Fri, Mar 20, 2009 at 11:02:33AM -0700, Junio C Hamano wrote:
Show 5 quoted lines
> A naïve question.
> 
> Has nobody suggested to use a really illegal characters such as ':'
> instead?  After all, we are not talking something that you can use in
> refspecs but another way to spell branch names.

But if this goes into dwim_ref, then won't it be usable for refspecs? Or even if it isn't, then imagine the user who doesn't know this and types

  git push :foo
unwittingly deleting the remote "foo".

Yes, that is unlikely (since why would they push the tracking branch of foo?), but I don't think it makes sense to argue that it doesn't have confusing (and potentially dangerous) consequenses.

> Alternatively, '~master' may have a nice connotation that means "where
> master calls its home".

I think that is quite clever and doesn't have any meaning for a revision specifier already. I like it.

-Peff
Julian Phillips· Mar 20, 2009, 20:28 UTC · re: Jeff King · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

On Fri, 20 Mar 2009, Jeff King wrote:
Show 24 quoted lines
> On Fri, Mar 20, 2009 at 11:02:33AM -0700, Junio C Hamano wrote:
>
>> A na?ve question.
>>
>> Has nobody suggested to use a really illegal characters such as ':'
>> instead?  After all, we are not talking something that you can use in
>> refspecs but another way to spell branch names.
>
> But if this goes into dwim_ref, then won't it be usable for refspecs? Or
> even if it isn't, then imagine the user who doesn't know this and types
>
>  git push :foo
>
> unwittingly deleting the remote "foo".
>
> Yes, that is unlikely (since why would they push the tracking branch of
> foo?), but I don't think it makes sense to argue that it doesn't have
> confusing (and potentially dangerous) consequenses.
>
>> Alternatively, '~master' may have a nice connotation that means "where
>> master calls its home".
>
> I think that is quite clever and doesn't have any meaning for a revision
> specifier already. I like it.

I considered suggesting this earlier, but didn't as the behaviour is not consistent. If you have a user named master then you have to type '~master' (including quotes), if you don't you can type ~master, and you always have to type '~' instead of ~. I didn't particularly fancy typing all those quotes, and certainly not explaining the behaviour to people not overly familiar with unix shell behaviour.

-- 
Julian

  ---
It's very inconvenient to be mortal -- you never know when everything may
suddenly stop happening.
Jeff King· Mar 20, 2009, 20:50 UTC · re: Julian Phillips · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

On Fri, Mar 20, 2009 at 08:28:28PM +0000, Julian Phillips wrote:
Show 9 quoted lines
>> I think that is quite clever and doesn't have any meaning for a revision
>> specifier already. I like it.
>
> I considered suggesting this earlier, but didn't as the behaviour is not  
> consistent.  If you have a user named master then you have to type  
> '~master' (including quotes), if you don't you can type ~master, and you  
> always have to type '~' instead of ~.  I didn't particularly fancy typing  
> all those quotes, and certainly not explaining the behaviour to people not 
> overly familiar with unix shell behaviour.

Oh, good point. I wasn't thinking it through. My initial thought was that there is no problem conflicting with a file ~master/foo, since you generally don't want to use absolute paths that are likely outside your git repository. But of course the shell doesn't know this and will screw you, which I failed to consider.

-Peff
Julian Phillips· Mar 20, 2009, 23:08 UTC · re: Junio C Hamano · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

On Fri, 20 Mar 2009, Junio C Hamano wrote:
Show 20 quoted lines
> An most obvious one is that "git checkout branchname" and "git checkout
> refs/heads/branchname" behave differently.  You cannot checkout a branch
> called %master after this patch goes in.
>
> Just be honest and say "You may have a branch whose name begins with a '%'
> and you cannot refer to it anymore in certain contexts.  Too bad.  Don't
> do it next time you create a new branch".  I _can_ buy that argument.
>
> It however asks for a sane escape hatch.  You cannot "fix" such branch
> names in most obvious ways (if you could, that would be a bug in this %
> feature).
>
> (1) git branch -m %master percent-master
>
>     We would end up renaming what master tracks to new name.
>
> (2) git branch percent-master refs/heads/%master; git branch -d %master
>
>     The first part is a good try, but the latter deletes what master
>     tracks.

How about adding a generic escape hatch, that would cover this and future extensions?

Let a ref that starts with a single quote be taken as given and not processed. You have to escape it to get it past the shell, but that makes it rather unlikely that anyone has used a name that starts with a quote - and if they have you can still use this mechanism to rename it.

So now (1) above could be written:
  git branch -m "'%master" percent-master
and other commands, such as
  git branch -d "'%master"
or
  git checkout "'%master"
would also do the right thing (i.e. use refs/heads/%master as a branch).
-- 
Julian

  ---
Stewie Griffin:  [looking in the fridge for a drink] Soda... purple stuff... Sunny D, all right!
Sverre Rabbelier· Mar 20, 2009, 23:20 UTC · re: Julian Phillips · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

Heya,
On Sat, Mar 21, 2009 at 00:08, Julian Phillips <julian@quantumfyre.co.uk> wrote:
>  git branch -m "'%master" percent-master

Which kinda defeats the purpose of having a short-and-easy-to-write refname, no? "'%master" is not that easy to type, I at least get my fingers mixed up in the "'% sequence. Perhaps we should reserve these special characters now, and deprecate their use? Junio seemed to be open to that (quoted below)...

> Just be honest and say "You may have a branch whose name begins with a '%'
> and you cannot refer to it anymore in certain contexts.  Too bad.  Don't
> do it next time you create a new branch".  I _can_ buy that argument.
-- 
Cheers,

Sverre Rabbelier
Julian Phillips· Mar 20, 2009, 23:41 UTC · re: Sverre Rabbelier · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

On Sat, 21 Mar 2009, Sverre Rabbelier wrote:
Show 10 quoted lines
> Heya,
>
> On Sat, Mar 21, 2009 at 00:08, Julian Phillips <julian@quantumfyre.co.uk> wrote:
>>  git branch -m "'%master" percent-master
>
> Which kinda defeats the purpose of having a short-and-easy-to-write
> refname, no? "'%master" is not that easy to type, I at least get my
> fingers mixed up in the "'% sequence. Perhaps we should reserve these
> special characters now, and deprecate their use? Junio seemed to be
> open to that (quoted below)...
But it's not supposed to be easy to type ...

To use the new syntax you type %master only. What I was proposing was a way to get at the branch that you had before the wizzy new feature was added. Something you only do once to rename it - why waste an easy to type sequence on that?

I agree that adding some more reserved characters is a reasonable way forward - but I think a way should be provided for people who are _already_ using those characters to rename their branches to something that avoids those characters in a simple (but not necessarily easy to type) way.

-- 
Julian

  ---
panic("%s: CORRUPTED BTREE OR SOMETHING", __FUNCTION__);
         linux-2.6.6/fs/xfs/xfs_bmap.c
Sverre Rabbelier· Mar 20, 2009, 23:45 UTC · re: Julian Phillips · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

Heya,
On Sat, Mar 21, 2009 at 00:41, Julian Phillips <julian@quantumfyre.co.uk> wrote:
> To use the new syntax you type %master only.  What I was proposing was a way
> to get at the branch that you had before the wizzy new feature was added.
>  Something you only do once to rename it - why waste an easy to type
> sequence on that?

Oooooh, sorry, I totally understood your suggestion the wrong way around! In that case, I like it! :)

> I agree that adding some more reserved characters is a reasonable way
> forward - but I think a way should be provided for people who are _already_
> using those characters to rename their branches to something that avoids
> those characters in a simple (but not necessarily easy to type) way.
Your suggestion on how to escape the DWIMery sounds sane to me :).
-- 
Cheers,

Sverre Rabbelier
Andreas Gruenbacher· Mar 21, 2009, 00:35 UTC · re: Julian Phillips · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

On Saturday, 21 March 2009 0:08:42 Julian Phillips wrote:
Show 7 quoted lines
> How about adding a generic escape hatch, that would cover this and
> future extensions?
>
> Let a ref that starts with a single quote be taken as given and not
> processed.  You have to escape it to get it past the shell, but that makes
> it rather unlikely that anyone has used a name that starts with a quote -
> and if they have you can still use this mechanism to rename it.

To me the most obvious escape sequence would be \x for disabling whatever special meaning x has (for non-alphabetic x). With quoting you likely eventually end up needing \' in some cases anyway...

Andreas
Miles Bader· Mar 21, 2009, 01:10 UTC · re: Andreas Gruenbacher · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

Andreas Gruenbacher <agruen@suse.de> writes:
> To me the most obvious escape sequence would be \x for disabling whatever 
> special meaning x has (for non-alphabetic x). With quoting you likely 
> eventually end up needing  \' in some cases anyway...

I think it's a good idea to _avoid_ using backslash as an escape when possible -- the potential for confusion and screwups from multiple layers all interpreting backslash should be familiar to most people here... (single-quote suffers from the same problem a bit, but at least it's not quite as overused as backslash)

-Miles
-- 
One of the lessons of history is that nothing is often a good thing to
do, and always a clever thing to say.  -- Will Durant
Julian Phillips· Mar 21, 2009, 13:24 UTC · re: Andreas Gruenbacher · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

On Sat, 21 Mar 2009, Andreas Gruenbacher wrote:
Show 12 quoted lines
> On Saturday, 21 March 2009 0:08:42 Julian Phillips wrote:
>> How about adding a generic escape hatch, that would cover this and
>> future extensions?
>>
>> Let a ref that starts with a single quote be taken as given and not
>> processed.  You have to escape it to get it past the shell, but that makes
>> it rather unlikely that anyone has used a name that starts with a quote -
>> and if they have you can still use this mechanism to rename it.
>
> To me the most obvious escape sequence would be \x for disabling whatever
> special meaning x has (for non-alphabetic x). With quoting you likely
> eventually end up needing  \' in some cases anyway...

Except that \ is the escape character for the shell too ... and that can get very confusing. Haven't you ever spent too long trying to figure out how many \s you needed to get the command to work properly?

-- 
Julian

  ---
I'm still waiting for the advent of the computer science groupie.
Julian Phillips· Mar 21, 2009, 13:28 UTC · re: Julian Phillips · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

On Sat, 21 Mar 2009, Julian Phillips wrote:
Show 20 quoted lines
> On Sat, 21 Mar 2009, Andreas Gruenbacher wrote:
>
>>  On Saturday, 21 March 2009 0:08:42 Julian Phillips wrote:
>> >  How about adding a generic escape hatch, that would cover this and
>> >  future extensions?
>> > 
>> >  Let a ref that starts with a single quote be taken as given and not
>> >  processed.  You have to escape it to get it past the shell, but that 
>> >  makes
>> >  it rather unlikely that anyone has used a name that starts with a quote 
>> >  -
>> >  and if they have you can still use this mechanism to rename it.
>>
>>  To me the most obvious escape sequence would be \x for disabling whatever
>>  special meaning x has (for non-alphabetic x). With quoting you likely
>>  eventually end up needing  \' in some cases anyway...
>
> Except that \ is the escape character for the shell too ... and that can get 
> very confusing.  Haven't you ever spent too long trying to figure out how 
> many \s you needed to get the command to work properly?

Having said that, the actual character used doesn't really matter. That's just a what colour do you want your shed type detail ...

-- 
Julian

  ---
BOFH Excuse #118:

the router thinks its a printer.
Björn Steinbrink· Mar 20, 2009, 17:08 UTC · re: Johannes Schindelin · lore

Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch

On 2009.03.20 17:17:01 +0100, Johannes Schindelin wrote:
> Even if a branch name can legally start with a '%' sign, we can use the
> special character '%' here, as you can always specify the full ref:
> refs/heads/%my-branch (pointed out by doener on IRC).

Hm, I just recalled that "git checkout" doesn't "like" anything but the shortname for a branch, with refs/heads/master or heads/master, you get a detached HEAD. Though at least when reading the doc, that seems like a bug to me. The man page says:

    When this parameter names a non-branch (but still a valid commit
    object), your HEAD becomes detached.

And of course refs/heads/master names a branch. Is it expected/intended that checkout detaches HEAD anyway when given a full ref name?

Björn
Jeff King· Mar 20, 2009, 06:05 UTC · re: Shawn O. Pearce · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

On Thu, Mar 19, 2009 at 05:40:29PM -0700, Shawn O. Pearce wrote:
> So yea, you can create a branch named "foo@{1}".
But you can't actually refer to it:
  $ git branch foo@{1}
  $ git show foo@{1} --
  fatal: bad revision 'foo@{1}'
which implies that nobody is actually using it for anything.
-Peff
Junio C Hamano· Mar 20, 2009, 06:57 UTC · re: Jeff King · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Jeff King <peff@peff.net> writes:
Show 11 quoted lines
> On Thu, Mar 19, 2009 at 05:40:29PM -0700, Shawn O. Pearce wrote:
>
>> So yea, you can create a branch named "foo@{1}".
>
> But you can't actually refer to it:
>
>   $ git branch foo@{1}
>   $ git show foo@{1} --
>   fatal: bad revision 'foo@{1}'
>
> which implies that nobody is actually using it for anything.

I think you are right. It is just "git branch" and perhaps "git update-ref" are too loose in enforcing what can be created.

Johannes Schindelin· Mar 20, 2009, 09:30 UTC · re: Junio C Hamano · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Hi,
On Thu, 19 Mar 2009, Junio C Hamano wrote:
Show 16 quoted lines
> Jeff King <peff@peff.net> writes:
> 
> > On Thu, Mar 19, 2009 at 05:40:29PM -0700, Shawn O. Pearce wrote:
> >
> >> So yea, you can create a branch named "foo@{1}".
> >
> > But you can't actually refer to it:
> >
> >   $ git branch foo@{1}
> >   $ git show foo@{1} --
> >   fatal: bad revision 'foo@{1}'
> >
> > which implies that nobody is actually using it for anything.
> 
> I think you are right.  It is just "git branch" and perhaps "git
> update-ref" are too loose in enforcing what can be created.

"git branch" I agree with, but not "git update-ref". As plumbing, the latter should be much more allowing, feeding rope aplenty (but also allowing cool tricks we do not think about yet).

Ciao, Dscho

Petr Baudis· Mar 20, 2009, 11:12 UTC · re: Johannes Schindelin · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Hi!
On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:
Show 8 quoted lines
> On Thu, 19 Mar 2009, Junio C Hamano wrote:
> 
> > I think you are right.  It is just "git branch" and perhaps "git
> > update-ref" are too loose in enforcing what can be created.
> 
> "git branch" I agree with, but not "git update-ref".  As plumbing, the 
> latter should be much more allowing, feeding rope aplenty (but also 
> allowing cool tricks we do not think about yet).

We shouldn't allow creating insane ref names even with update-ref. That way porcelains cannot rely on update-ref to sanity check the user's crap. At most, maybe you might want to bypass this check with some force switch, though I really can't quite imagine why.

-- 
				Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
Johannes Schindelin· Mar 20, 2009, 11:46 UTC · re: Petr Baudis · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Hi,
On Fri, 20 Mar 2009, Petr Baudis wrote:
Show 14 quoted lines
> On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:
> > On Thu, 19 Mar 2009, Junio C Hamano wrote:
> > 
> > > I think you are right.  It is just "git branch" and perhaps "git
> > > update-ref" are too loose in enforcing what can be created.
> > 
> > "git branch" I agree with, but not "git update-ref".  As plumbing, the 
> > latter should be much more allowing, feeding rope aplenty (but also 
> > allowing cool tricks we do not think about yet).
> 
> We shouldn't allow creating insane ref names even with update-ref. That
> way porcelains cannot rely on update-ref to sanity check the user's
> crap. At most, maybe you might want to bypass this check with some force
> switch, though I really can't quite imagine why.

You really cannot imagine? You, the author of filter-branch? People _do_ have fscked-up repositories, but they get really angry when they cannot use rebase or filter-branch on them.

Ciao, Dscho

Petr Baudis· Mar 20, 2009, 11:50 UTC · re: Johannes Schindelin · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

On Fri, Mar 20, 2009 at 12:46:19PM +0100, Johannes Schindelin wrote:
Show 22 quoted lines
> Hi,
> 
> On Fri, 20 Mar 2009, Petr Baudis wrote:
> 
> > On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:
> > > On Thu, 19 Mar 2009, Junio C Hamano wrote:
> > > 
> > > > I think you are right.  It is just "git branch" and perhaps "git
> > > > update-ref" are too loose in enforcing what can be created.
> > > 
> > > "git branch" I agree with, but not "git update-ref".  As plumbing, the 
> > > latter should be much more allowing, feeding rope aplenty (but also 
> > > allowing cool tricks we do not think about yet).
> > 
> > We shouldn't allow creating insane ref names even with update-ref. That
> > way porcelains cannot rely on update-ref to sanity check the user's
> > crap. At most, maybe you might want to bypass this check with some force
> > switch, though I really can't quite imagine why.
> 
> You really cannot imagine?  You, the author of filter-branch?  People _do_ 
> have fscked-up repositories, but they get really angry when they cannot 
> use rebase or filter-branch on them.
They can rename the ref as the first step of a cleanup, can't they?
-- 
				Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
Johannes Schindelin· Mar 20, 2009, 11:57 UTC · re: Petr Baudis · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Hi,
On Fri, 20 Mar 2009, Petr Baudis wrote:
Show 24 quoted lines
> On Fri, Mar 20, 2009 at 12:46:19PM +0100, Johannes Schindelin wrote:
> 
> > On Fri, 20 Mar 2009, Petr Baudis wrote:
> > 
> > > On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:
> > > > On Thu, 19 Mar 2009, Junio C Hamano wrote:
> > > > 
> > > > > I think you are right.  It is just "git branch" and perhaps "git
> > > > > update-ref" are too loose in enforcing what can be created.
> > > > 
> > > > "git branch" I agree with, but not "git update-ref".  As plumbing, the 
> > > > latter should be much more allowing, feeding rope aplenty (but also 
> > > > allowing cool tricks we do not think about yet).
> > > 
> > > We shouldn't allow creating insane ref names even with update-ref. That
> > > way porcelains cannot rely on update-ref to sanity check the user's
> > > crap. At most, maybe you might want to bypass this check with some force
> > > switch, though I really can't quite imagine why.
> > 
> > You really cannot imagine?  You, the author of filter-branch?  People _do_ 
> > have fscked-up repositories, but they get really angry when they cannot 
> > use rebase or filter-branch on them.
> 
> They can rename the ref as the first step of a cleanup, can't they?

Well, of course, we can make life hard on everybody. That is quite possible.

But then, we can be nice, and at the same time fix the problem _properly_.
IMHO a _warning_ should be the best thing.

But all this does not solve _my_ problem: I'd like something as easy to write as %next, but as unlikely to be used in existing refs as @{..}.

Ciao, Dscho

Michael J Gruber· Mar 20, 2009, 14:31 UTC · re: Johannes Schindelin · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Johannes Schindelin venit, vidit, dixit 20.03.2009 12:57:
Show 38 quoted lines
> Hi,
> 
> On Fri, 20 Mar 2009, Petr Baudis wrote:
> 
>> On Fri, Mar 20, 2009 at 12:46:19PM +0100, Johannes Schindelin wrote:
>>
>>> On Fri, 20 Mar 2009, Petr Baudis wrote:
>>>
>>>> On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:
>>>>> On Thu, 19 Mar 2009, Junio C Hamano wrote:
>>>>>
>>>>>> I think you are right.  It is just "git branch" and perhaps "git
>>>>>> update-ref" are too loose in enforcing what can be created.
>>>>>
>>>>> "git branch" I agree with, but not "git update-ref".  As plumbing, the 
>>>>> latter should be much more allowing, feeding rope aplenty (but also 
>>>>> allowing cool tricks we do not think about yet).
>>>>
>>>> We shouldn't allow creating insane ref names even with update-ref. That
>>>> way porcelains cannot rely on update-ref to sanity check the user's
>>>> crap. At most, maybe you might want to bypass this check with some force
>>>> switch, though I really can't quite imagine why.
>>>
>>> You really cannot imagine?  You, the author of filter-branch?  People _do_ 
>>> have fscked-up repositories, but they get really angry when they cannot 
>>> use rebase or filter-branch on them.
>>
>> They can rename the ref as the first step of a cleanup, can't they?
> 
> Well, of course, we can make life hard on everybody.  That is quite 
> possible.
> 
> But then, we can be nice, and at the same time fix the problem _properly_.
> 
> IMHO a _warning_ should be the best thing.
> 
> But all this does not solve _my_ problem: I'd like something as easy to 
> write as %next, but as unlikely to be used in existing refs as @{..}.

Do we have ^ as a prefix yet? Neither the suffix (commit^) nor the infix (commit^{type}) allow an empty commit (for HEAD) - which might be nice, though. So, ^ as a prefix is free, even without any specifier after.

Also, I don't think people would use @@ much in branch names.
Michael
Johannes Schindelin· Mar 20, 2009, 15:01 UTC · re: Michael J Gruber · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Hi,
On Fri, 20 Mar 2009, Michael J Gruber wrote:
> Do we have ^ as a prefix yet?
Yes, it means "not".  IOW '^bla blub' is the same as 'bla..blub'.
> Also, I don't think people would use @@ much in branch names.
Whoa...

Ciao, Dscho

Michael J Gruber· Mar 20, 2009, 15:12 UTC · re: Johannes Schindelin · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Johannes Schindelin venit, vidit, dixit 20.03.2009 16:01:
Show 7 quoted lines
> Hi,
> 
> On Fri, 20 Mar 2009, Michael J Gruber wrote:
> 
>> Do we have ^ as a prefix yet?
> 
> Yes, it means "not".  IOW '^bla blub' is the same as 'bla..blub'.

Oh yes, I forgot. commit specifiers and ranges are in different sections in git-rev-parse.1.

>> Also, I don't think people would use @@ much in branch names.
> 
> Whoa...
We already have ^! and ^@ (I didn't know).

While someone may have a branch like "@junio" I think doubled special characters are uncommon. Except for that topic branch /&$%$%§$%&/) for a really nasty bug.

Of course, if @@ refers to a tracked branch which follows another branch, then @@@@...

Michael
Junio C Hamano· Mar 20, 2009, 16:47 UTC · re: Petr Baudis · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Petr Baudis <pasky@suse.cz> writes:
Show 8 quoted lines
>> "git branch" I agree with, but not "git update-ref".  As plumbing, the 
>> latter should be much more allowing, feeding rope aplenty (but also 
>> allowing cool tricks we do not think about yet).
>
> We shouldn't allow creating insane ref names even with update-ref. That
> way porcelains cannot rely on update-ref to sanity check the user's
> crap. At most, maybe you might want to bypass this check with some force
> switch, though I really can't quite imagine why.

That's all nice and clean in theory, but it was more or less the same reasoning as what was behind the tightening not to allow anything but refs/heads pointed by HEAD, but you know what fell out of it. "Insane" and "crap" are in the eye of the beholder.

Daniel Barkalow· Mar 20, 2009, 19:34 UTC · re: Junio C Hamano · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

On Fri, 20 Mar 2009, Junio C Hamano wrote:
Show 15 quoted lines
> Petr Baudis <pasky@suse.cz> writes:
> 
> >> "git branch" I agree with, but not "git update-ref".  As plumbing, the 
> >> latter should be much more allowing, feeding rope aplenty (but also 
> >> allowing cool tricks we do not think about yet).
> >
> > We shouldn't allow creating insane ref names even with update-ref. That
> > way porcelains cannot rely on update-ref to sanity check the user's
> > crap. At most, maybe you might want to bypass this check with some force
> > switch, though I really can't quite imagine why.
> 
> That's all nice and clean in theory, but it was more or less the same
> reasoning as what was behind the tightening not to allow anything but
> refs/heads pointed by HEAD, but you know what fell out of it.  "Insane"
> and "crap" are in the eye of the beholder.

I think there's no possible use to being able to use update-ref to create a ref that rev-parse can't be made to read. I think people will want to do all sorts of things that are insane (I'd personally like some refs with the basename "..."), but they're only likely to do insane things that happen to work, rather than insane things that aren't prevented but still don't work.

	-Daniel
*This .sig left intentionally blank*
Johannes Schindelin· Mar 20, 2009, 21:48 UTC · re: Daniel Barkalow · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

Hi,
On Fri, 20 Mar 2009, Daniel Barkalow wrote:
Show 24 quoted lines
> On Fri, 20 Mar 2009, Junio C Hamano wrote:
> 
> > Petr Baudis <pasky@suse.cz> writes:
> > 
> > >> "git branch" I agree with, but not "git update-ref".  As plumbing, 
> > >> the latter should be much more allowing, feeding rope aplenty (but 
> > >> also allowing cool tricks we do not think about yet).
> > >
> > > We shouldn't allow creating insane ref names even with update-ref. 
> > > That way porcelains cannot rely on update-ref to sanity check the 
> > > user's crap. At most, maybe you might want to bypass this check with 
> > > some force switch, though I really can't quite imagine why.
> > 
> > That's all nice and clean in theory, but it was more or less the same 
> > reasoning as what was behind the tightening not to allow anything but 
> > refs/heads pointed by HEAD, but you know what fell out of it.  
> > "Insane" and "crap" are in the eye of the beholder.
> 
> I think there's no possible use to being able to use update-ref to 
> create a ref that rev-parse can't be made to read. I think people will 
> want to do all sorts of things that are insane (I'd personally like some 
> refs with the basename "..."), but they're only likely to do insane 
> things that happen to work, rather than insane things that aren't 
> prevented but still don't work.

Of course, you are forgetting that rev-parse may well have been able to grok such a ref at some stage.

And at that stage, it becomes not a user error, but a _huge_ mistake by us, the Git developers.

Don't blame the user (http://www.schneier.com/blog/archives/2009/03/it_security_bla.html).

Ciao, Dscho

Junio C Hamano· Mar 21, 2009, 21:00 UTC · re: Shawn O. Pearce · lore

Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 24 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Fri, 20 Mar 2009, Johannes Schindelin wrote:
>> 
>> > Just try this:
>> > 
>> > 	$ git checkout -b %helloworld
>> 
>> It gets worse.  Much worse.
>> 
>> Try this (triggered by a comment by Ilari on IRC):
>> 
>> 	$ git checkout -b '@{1}'
>> 
>> That _works_! WTH?
>
> '@' is not reserved.  Neither is '{' or '}'.  Neither is
> the combination.
>
> Waaaaaay back when I added reflog query syntax I tried to use only
> '@', people with branch names like 'foo@bar' made a point that they
> didn't want to reserve it.  We stuck the {} in as a "highly unlikely
> to conflict with a branch name" and others pointed out most shells
> will do fun things with those, but we kept it to avoid ambiguous
> meanings of "foo@noon" when foo@noon is already a branch.
Let's do something along this line.
-- >8 --
Subject: [PATCH] check_ref_format(): tighten refname rules

Yes, I know that tightening rules retroactively is bad, but this changes the rules for refnames to forbid:

 (1) a refname that ends with a dot.
     We already reject a path component that begins with a dot, primarily
     to avoid ambiguous range interpretation.  If we allowed ".B" as a
     valid ref, it is unclear if "A...B" means "in dot-B but not in A" or
     "either in A or B but not in both".
     But for this to be complete, we need also to forbid "A." to avoid "in
     B but not in A-dot".  This was not a problem in the original range
     notation, but we should have added this restriction when three-dot
     notation was introduced.
     Unlike "no dot at the beginning of any path component" rule, this
     rule does not have to be "no dot at the end of any path component",
     because you cannot abbreviate the tail end away, similar to you can
     say "dot-B" to mean "refs/heads/dot-B".
 (2) a refname that contains "@{" in it.
     Some people and foreign SCM converter may have named their branches
     as frotz@243 and we still want to keep supporting it, but "git branch
     @{1}" is a disaster.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 refs.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 8d3c502..abd5623 100644
--- a/refs.c
+++ b/refs.c
@@ -693,7 +693,7 @@ static inline int bad_ref_char(int ch)
 
 int check_ref_format(const char *ref)
 {
-	int ch, level, bad_type;
+	int ch, level, bad_type, last;
 	int ret = CHECK_REF_FORMAT_OK;
 	const char *cp = ref;
 
@@ -717,19 +717,23 @@ int check_ref_format(const char *ref)
 				return CHECK_REF_FORMAT_ERROR;
 		}
 
+		last = ch;
 		/* scan the rest of the path component */
 		while ((ch = *cp++) != 0) {
 			bad_type = bad_ref_char(ch);
-			if (bad_type) {
+			if (bad_type)
 				return CHECK_REF_FORMAT_ERROR;
-			}
 			if (ch == '/')
 				break;
-			if (ch == '.' && *cp == '.')
+			if (last == '.' && ch == '.')
+				return CHECK_REF_FORMAT_ERROR;
+			if (last == '@' && ch == '{')
 				return CHECK_REF_FORMAT_ERROR;
 		}
 		level++;
 		if (!ch) {
+			if (ref <= cp - 2 && cp[-2] == '.')
+				return CHECK_REF_FORMAT_ERROR;
 			if (level < 2)
 				return CHECK_REF_FORMAT_ONELEVEL;
 			return ret;
-- 
1.6.2.1.299.gda643a

← back to recent threads