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

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

[Petr Baudis]

  Hi,

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 %..

-- 
				Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr

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

[Johannes Schindelin]

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

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

[Andreas Gruenbacher]

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

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

[Johannes Schindelin]

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

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

[Andreas Gruenbacher]

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

Works here now. Thanks a lot!

Andreas

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

[Junio C Hamano]

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.

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

[Johannes Schindelin]

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

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

[Johannes Schindelin]

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...

Ciao,
Dscho

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

[Michael J Gruber]

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...

Michael

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

[Michael J Gruber]

Michael J Gruber venit, vidit, dixit 19.03.2009 15:52:
> 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

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

[Johannes Schindelin]

Hi,

On Wed, 18 Mar 2009, Johannes Schindelin wrote:

> 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"

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

[Johannes Schindelin]

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

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

[Shawn O. Pearce]

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.

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.

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

[Shawn O. Pearce]

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> 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.

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

[Sverre Rabbelier]

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

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

[Jeff King]

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

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

[Junio C Hamano]

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.

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

[Johannes Schindelin]

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

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

[Johannes Schindelin]

Hi,

On Thu, 19 Mar 2009, Junio C Hamano wrote:

> 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

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

[Wincent Colaiuta]

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.

Cheers,
Wincent

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

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 771 bytes --]

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.

Ciao,
Dscho

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

[Michael J Gruber]

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
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.

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

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

[Johannes Schindelin]

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.

> 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.

> 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

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

[Michael J Gruber]

Johannes Schindelin venit, vidit, dixit 20.03.2009 11:31:
> 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...

> 
>> 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)

> 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...

>> <Goes to figure out how to enter BEL...>
> 
> Ctrl-v Ctrl-g
> 
> Ciao,
> Dscho

Bing bing bing...

Michael

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

[Petr Baudis]

Hi!

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.

-- 
				Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr

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

[Petr Baudis]

  Hi!

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}?

				Petr "Pasky" Baudis

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

[Johannes Schindelin]

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.

Ciao,
Dscho

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

[Johannes Schindelin]

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.

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

Ciao,
Dscho

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

[Petr Baudis]

On Fri, Mar 20, 2009 at 12:46:19PM +0100, Johannes Schindelin wrote:
> 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

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

[Johannes Schindelin]

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 @{..}.

Ciao,
Dscho

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

[Santi Béjar]

2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> 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

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

[Andreas Gruenbacher]

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

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

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1370 bytes --]

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.

Ciao,
Dscho

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

[Mikael Magnusson]

2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> 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

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

[Matthieu Moy]

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

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

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1920 bytes --]

Hi,

On Fri, 20 Mar 2009, Mikael Magnusson wrote:

> 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

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

[Michael J Gruber]

Johannes Schindelin venit, vidit, dixit 20.03.2009 11:31:
> 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

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

[Michael J Gruber]

Johannes Schindelin venit, vidit, dixit 20.03.2009 12:57:
> 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

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

[Johannes Schindelin]

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

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

[Michael J Gruber]

Johannes Schindelin venit, vidit, dixit 20.03.2009 16:01:
> 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

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

[Johannes Schindelin]

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

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

[Junio C Hamano]

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.

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

[Junio C Hamano]

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.

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.

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

[Björn Steinbrink]

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

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

[Johannes Schindelin]

Hi,

On Fri, 20 Mar 2009, Junio C Hamano wrote:

> 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

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> 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).

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

[Daniel Barkalow]

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.

	-Daniel
*This .sig left intentionally blank*

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

[Jeff King]

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.

-Peff

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

[Julian Phillips]

On Fri, 20 Mar 2009, Jeff King wrote:

> 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.

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

[Jeff King]

On Fri, Mar 20, 2009 at 08:28:28PM +0000, Julian Phillips wrote:

>> 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

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

[Johannes Schindelin]

Hi,

On Fri, 20 Mar 2009, Daniel Barkalow wrote:

> 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

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

[Julian Phillips]

On Fri, 20 Mar 2009, Junio C Hamano wrote:

> 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!

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

[Sverre Rabbelier]

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

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

[Julian Phillips]

On Sat, 21 Mar 2009, Sverre Rabbelier wrote:

> 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

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

[Sverre Rabbelier]

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

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

[Andreas Gruenbacher]

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...

Andreas

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

[Miles Bader]

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

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

[Julian Phillips]

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?

-- 
Julian

  ---
I'm still waiting for the advent of the computer science groupie.

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

[Julian Phillips]

On Sat, 21 Mar 2009, Julian Phillips wrote:

> 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.

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

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> 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

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

[Petr Baudis]

On Fri, Mar 20, 2009 at 12:48:50PM +0100, Johannes Schindelin wrote:
> 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