* Re: Git {log,diff} against tracked branch? [not found] <200903181448.50706.agruen@suse.de> @ 2009-03-18 18:26 ` Petr Baudis 2009-03-18 21:12 ` [PATCH] Introduce %<branch> as shortcut to the tracked branch Johannes Schindelin 0 siblings, 1 reply; 61+ messages in thread From: Petr Baudis @ 2009-03-18 18:26 UTC (permalink / raw) To: Andreas Gruenbacher; +Cc: git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH] Introduce %<branch> as shortcut to the tracked branch 2009-03-18 18:26 ` Git {log,diff} against tracked branch? Petr Baudis @ 2009-03-18 21:12 ` Johannes Schindelin 2009-03-18 21:41 ` Andreas Gruenbacher 2009-03-18 21:46 ` [PATCH v2] " Johannes Schindelin 0 siblings, 2 replies; 61+ messages in thread From: Johannes Schindelin @ 2009-03-18 21:12 UTC (permalink / raw) To: Petr Baudis; +Cc: Andreas Gruenbacher, git 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 ^ permalink raw reply related [flat|nested] 61+ messages in thread
* Re: [PATCH] Introduce %<branch> as shortcut to the tracked branch 2009-03-18 21:12 ` [PATCH] Introduce %<branch> as shortcut to the tracked branch Johannes Schindelin @ 2009-03-18 21:41 ` Andreas Gruenbacher 2009-03-18 21:46 ` [PATCH v2] " Johannes Schindelin 1 sibling, 0 replies; 61+ messages in thread From: Andreas Gruenbacher @ 2009-03-18 21:41 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Petr Baudis, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-18 21:12 ` [PATCH] Introduce %<branch> as shortcut to the tracked branch Johannes Schindelin 2009-03-18 21:41 ` Andreas Gruenbacher @ 2009-03-18 21:46 ` Johannes Schindelin 2009-03-18 21:58 ` Andreas Gruenbacher 2009-03-18 22:34 ` Junio C Hamano 1 sibling, 2 replies; 61+ messages in thread From: Johannes Schindelin @ 2009-03-18 21:46 UTC (permalink / raw) To: Petr Baudis; +Cc: Andreas Gruenbacher, git 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 ^ permalink raw reply related [flat|nested] 61+ messages in thread
* Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-18 21:46 ` [PATCH v2] " Johannes Schindelin @ 2009-03-18 21:58 ` Andreas Gruenbacher 2009-03-18 22:43 ` Johannes Schindelin 2009-03-18 22:34 ` Junio C Hamano 1 sibling, 1 reply; 61+ messages in thread From: Andreas Gruenbacher @ 2009-03-18 21:58 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Petr Baudis, git On Wednesday, 18 March 2009 22:46:22 Johannes Schindelin wrote: > Suggested by Pasky. Works here now. Thanks a lot! Andreas ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-18 21:58 ` Andreas Gruenbacher @ 2009-03-18 22:43 ` Johannes Schindelin 0 siblings, 0 replies; 61+ messages in thread From: Johannes Schindelin @ 2009-03-18 22:43 UTC (permalink / raw) To: Andreas Gruenbacher; +Cc: Petr Baudis, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-18 21:46 ` [PATCH v2] " Johannes Schindelin 2009-03-18 21:58 ` Andreas Gruenbacher @ 2009-03-18 22:34 ` Junio C Hamano 2009-03-18 22:46 ` Johannes Schindelin 1 sibling, 1 reply; 61+ messages in thread From: Junio C Hamano @ 2009-03-18 22:34 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Petr Baudis, Andreas Gruenbacher, git 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-18 22:34 ` Junio C Hamano @ 2009-03-18 22:46 ` Johannes Schindelin 2009-03-19 14:52 ` Michael J Gruber 2009-03-20 0:23 ` Johannes Schindelin 0 siblings, 2 replies; 61+ messages in thread From: Johannes Schindelin @ 2009-03-18 22:46 UTC (permalink / raw) To: Junio C Hamano; +Cc: Petr Baudis, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-18 22:46 ` Johannes Schindelin @ 2009-03-19 14:52 ` Michael J Gruber 2009-03-19 15:17 ` Michael J Gruber 2009-03-20 0:23 ` Johannes Schindelin 1 sibling, 1 reply; 61+ messages in thread From: Michael J Gruber @ 2009-03-19 14:52 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-19 14:52 ` Michael J Gruber @ 2009-03-19 15:17 ` Michael J Gruber 0 siblings, 0 replies; 61+ messages in thread From: Michael J Gruber @ 2009-03-19 15:17 UTC (permalink / raw) Cc: Johannes Schindelin, Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-18 22:46 ` Johannes Schindelin 2009-03-19 14:52 ` Michael J Gruber @ 2009-03-20 0:23 ` Johannes Schindelin 2009-03-20 0:38 ` ref name troubles, was " Johannes Schindelin 1 sibling, 1 reply; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 0:23 UTC (permalink / raw) To: Junio C Hamano; +Cc: Petr Baudis, Andreas Gruenbacher, git 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" ^ permalink raw reply [flat|nested] 61+ messages in thread
* ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 0:23 ` Johannes Schindelin @ 2009-03-20 0:38 ` Johannes Schindelin 2009-03-20 0:40 ` Shawn O. Pearce 0 siblings, 1 reply; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 0:38 UTC (permalink / raw) To: Junio C Hamano; +Cc: Petr Baudis, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 0:38 ` ref name troubles, was " Johannes Schindelin @ 2009-03-20 0:40 ` Shawn O. Pearce 2009-03-20 0:44 ` Shawn O. Pearce ` (2 more replies) 0 siblings, 3 replies; 61+ messages in thread From: Shawn O. Pearce @ 2009-03-20 0:40 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 0:40 ` Shawn O. Pearce @ 2009-03-20 0:44 ` Shawn O. Pearce 2009-03-20 5:59 ` Sverre Rabbelier 2009-03-20 9:29 ` [PATCH v3] Introduce BEL<branch> " Johannes Schindelin 2009-03-20 6:05 ` ref name troubles, was Re: [PATCH v2] " Jeff King 2009-03-21 21:00 ` Junio C Hamano 2 siblings, 2 replies; 61+ messages in thread From: Shawn O. Pearce @ 2009-03-20 0:44 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git "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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 0:44 ` Shawn O. Pearce @ 2009-03-20 5:59 ` Sverre Rabbelier 2009-03-20 9:29 ` [PATCH v3] Introduce BEL<branch> " Johannes Schindelin 1 sibling, 0 replies; 61+ messages in thread From: Sverre Rabbelier @ 2009-03-20 5:59 UTC (permalink / raw) To: Shawn O. Pearce Cc: Johannes Schindelin, Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch 2009-03-20 0:44 ` Shawn O. Pearce 2009-03-20 5:59 ` Sverre Rabbelier @ 2009-03-20 9:29 ` Johannes Schindelin 2009-03-20 9:42 ` Wincent Colaiuta ` (2 more replies) 1 sibling, 3 replies; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 9:29 UTC (permalink / raw) To: Shawn O. Pearce; +Cc: Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git 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 ^ permalink raw reply related [flat|nested] 61+ messages in thread
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch 2009-03-20 9:29 ` [PATCH v3] Introduce BEL<branch> " Johannes Schindelin @ 2009-03-20 9:42 ` Wincent Colaiuta 2009-03-20 9:54 ` Johannes Schindelin 2009-03-20 10:04 ` [PATCH] Document and test the new % shotcut for " Michael J Gruber 2009-03-20 16:17 ` [PATCH v4] Introduce %<branch> as shortcut to " Johannes Schindelin 2 siblings, 1 reply; 61+ messages in thread From: Wincent Colaiuta @ 2009-03-20 9:42 UTC (permalink / raw) To: Johannes Schindelin Cc: Shawn O. Pearce, Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch 2009-03-20 9:42 ` Wincent Colaiuta @ 2009-03-20 9:54 ` Johannes Schindelin 2009-03-20 12:33 ` Santi Béjar 0 siblings, 1 reply; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 9:54 UTC (permalink / raw) To: Wincent Colaiuta Cc: Shawn O. Pearce, Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git [-- 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch 2009-03-20 9:54 ` Johannes Schindelin @ 2009-03-20 12:33 ` Santi Béjar 2009-03-20 12:45 ` Andreas Gruenbacher 2009-03-20 12:46 ` Johannes Schindelin 0 siblings, 2 replies; 61+ messages in thread From: Santi Béjar @ 2009-03-20 12:33 UTC (permalink / raw) To: Johannes Schindelin Cc: Wincent Colaiuta, Shawn O. Pearce, Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch 2009-03-20 12:33 ` Santi Béjar @ 2009-03-20 12:45 ` Andreas Gruenbacher 2009-03-20 13:05 ` Matthieu Moy 2009-03-20 12:46 ` Johannes Schindelin 1 sibling, 1 reply; 61+ messages in thread From: Andreas Gruenbacher @ 2009-03-20 12:45 UTC (permalink / raw) To: Santi Béjar Cc: Johannes Schindelin, Wincent Colaiuta, Shawn O. Pearce, Junio C Hamano, Petr Baudis, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch 2009-03-20 12:45 ` Andreas Gruenbacher @ 2009-03-20 13:05 ` Matthieu Moy 0 siblings, 0 replies; 61+ messages in thread From: Matthieu Moy @ 2009-03-20 13:05 UTC (permalink / raw) To: Andreas Gruenbacher Cc: Santi Béjar, Johannes Schindelin, Wincent Colaiuta, Shawn O. Pearce, Junio C Hamano, Petr Baudis, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch 2009-03-20 12:33 ` Santi Béjar 2009-03-20 12:45 ` Andreas Gruenbacher @ 2009-03-20 12:46 ` Johannes Schindelin 2009-03-20 12:53 ` Mikael Magnusson 1 sibling, 1 reply; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 12:46 UTC (permalink / raw) To: Santi Béjar Cc: Wincent Colaiuta, Shawn O. Pearce, Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git [-- 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch 2009-03-20 12:46 ` Johannes Schindelin @ 2009-03-20 12:53 ` Mikael Magnusson 2009-03-20 14:00 ` Johannes Schindelin 0 siblings, 1 reply; 61+ messages in thread From: Mikael Magnusson @ 2009-03-20 12:53 UTC (permalink / raw) To: Johannes Schindelin Cc: Santi Béjar, Wincent Colaiuta, Shawn O. Pearce, Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch 2009-03-20 12:53 ` Mikael Magnusson @ 2009-03-20 14:00 ` Johannes Schindelin 0 siblings, 0 replies; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 14:00 UTC (permalink / raw) To: Mikael Magnusson Cc: Santi Béjar, Wincent Colaiuta, Shawn O. Pearce, Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git [-- 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH] Document and test the new % shotcut for the tracked branch 2009-03-20 9:29 ` [PATCH v3] Introduce BEL<branch> " Johannes Schindelin 2009-03-20 9:42 ` Wincent Colaiuta @ 2009-03-20 10:04 ` Michael J Gruber 2009-03-20 10:31 ` Johannes Schindelin 2009-03-20 16:17 ` [PATCH v4] Introduce %<branch> as shortcut to " Johannes Schindelin 2 siblings, 1 reply; 61+ messages in thread From: Michael J Gruber @ 2009-03-20 10:04 UTC (permalink / raw) To: git Cc: Johannes Schindelin, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, Junio C Hamano 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 ^ permalink raw reply related [flat|nested] 61+ messages in thread
* Re: [PATCH] Document and test the new % shotcut for the tracked branch 2009-03-20 10:04 ` [PATCH] Document and test the new % shotcut for " Michael J Gruber @ 2009-03-20 10:31 ` Johannes Schindelin 2009-03-20 10:38 ` Michael J Gruber ` (2 more replies) 0 siblings, 3 replies; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 10:31 UTC (permalink / raw) To: Michael J Gruber Cc: git, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, Junio C Hamano 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH] Document and test the new % shotcut for the tracked branch 2009-03-20 10:31 ` Johannes Schindelin @ 2009-03-20 10:38 ` Michael J Gruber 2009-03-20 11:16 ` Petr Baudis 2009-03-20 14:15 ` Michael J Gruber 2 siblings, 0 replies; 61+ messages in thread From: Michael J Gruber @ 2009-03-20 10:38 UTC (permalink / raw) To: Johannes Schindelin Cc: git, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, Junio C Hamano 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH] Document and test the new % shotcut for the tracked branch 2009-03-20 10:31 ` Johannes Schindelin 2009-03-20 10:38 ` Michael J Gruber @ 2009-03-20 11:16 ` Petr Baudis 2009-03-20 11:48 ` Johannes Schindelin 2009-03-20 14:15 ` Michael J Gruber 2 siblings, 1 reply; 61+ messages in thread From: Petr Baudis @ 2009-03-20 11:16 UTC (permalink / raw) To: Johannes Schindelin Cc: Michael J Gruber, git, Shawn O. Pearce, Andreas Gruenbacher, Junio C Hamano 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH] Document and test the new % shotcut for the tracked branch 2009-03-20 11:16 ` Petr Baudis @ 2009-03-20 11:48 ` Johannes Schindelin 2009-03-22 17:40 ` Petr Baudis 0 siblings, 1 reply; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 11:48 UTC (permalink / raw) To: Petr Baudis Cc: Michael J Gruber, git, Shawn O. Pearce, Andreas Gruenbacher, Junio C Hamano 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH] Document and test the new % shotcut for the tracked branch 2009-03-20 11:48 ` Johannes Schindelin @ 2009-03-22 17:40 ` Petr Baudis 0 siblings, 0 replies; 61+ messages in thread From: Petr Baudis @ 2009-03-22 17:40 UTC (permalink / raw) To: Johannes Schindelin Cc: Michael J Gruber, git, Shawn O. Pearce, Andreas Gruenbacher, Junio C Hamano 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH] Document and test the new % shotcut for the tracked branch 2009-03-20 10:31 ` Johannes Schindelin 2009-03-20 10:38 ` Michael J Gruber 2009-03-20 11:16 ` Petr Baudis @ 2009-03-20 14:15 ` Michael J Gruber 2 siblings, 0 replies; 61+ messages in thread From: Michael J Gruber @ 2009-03-20 14:15 UTC (permalink / raw) To: Johannes Schindelin Cc: Michael J Gruber, git, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, Junio C Hamano 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 9:29 ` [PATCH v3] Introduce BEL<branch> " Johannes Schindelin 2009-03-20 9:42 ` Wincent Colaiuta 2009-03-20 10:04 ` [PATCH] Document and test the new % shotcut for " Michael J Gruber @ 2009-03-20 16:17 ` Johannes Schindelin 2009-03-20 17:03 ` Junio C Hamano 2009-03-20 17:08 ` Björn Steinbrink 2 siblings, 2 replies; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 16:17 UTC (permalink / raw) To: Shawn O. Pearce Cc: Junio C Hamano, Petr Baudis, Andreas Gruenbacher, B.Steinbrink, git 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 ^ permalink raw reply related [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 16:17 ` [PATCH v4] Introduce %<branch> as shortcut to " Johannes Schindelin @ 2009-03-20 17:03 ` Junio C Hamano 2009-03-20 17:32 ` Johannes Schindelin ` (2 more replies) 2009-03-20 17:08 ` Björn Steinbrink 1 sibling, 3 replies; 61+ messages in thread From: Junio C Hamano @ 2009-03-20 17:03 UTC (permalink / raw) To: Johannes Schindelin Cc: Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink, git 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 17:03 ` Junio C Hamano @ 2009-03-20 17:32 ` Johannes Schindelin 2009-03-20 18:02 ` Junio C Hamano 2009-03-20 23:08 ` Julian Phillips 2 siblings, 0 replies; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 17:32 UTC (permalink / raw) To: Junio C Hamano Cc: Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 17:03 ` Junio C Hamano 2009-03-20 17:32 ` Johannes Schindelin @ 2009-03-20 18:02 ` Junio C Hamano 2009-03-20 19:36 ` Jeff King 2009-03-20 23:08 ` Julian Phillips 2 siblings, 1 reply; 61+ messages in thread From: Junio C Hamano @ 2009-03-20 18:02 UTC (permalink / raw) To: Johannes Schindelin Cc: Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink, git 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). ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 18:02 ` Junio C Hamano @ 2009-03-20 19:36 ` Jeff King 2009-03-20 20:28 ` Julian Phillips 0 siblings, 1 reply; 61+ messages in thread From: Jeff King @ 2009-03-20 19:36 UTC (permalink / raw) To: Junio C Hamano Cc: Johannes Schindelin, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 19:36 ` Jeff King @ 2009-03-20 20:28 ` Julian Phillips 2009-03-20 20:50 ` Jeff King 0 siblings, 1 reply; 61+ messages in thread From: Julian Phillips @ 2009-03-20 20:28 UTC (permalink / raw) To: Jeff King Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink, git 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 20:28 ` Julian Phillips @ 2009-03-20 20:50 ` Jeff King 0 siblings, 0 replies; 61+ messages in thread From: Jeff King @ 2009-03-20 20:50 UTC (permalink / raw) To: Julian Phillips Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 17:03 ` Junio C Hamano 2009-03-20 17:32 ` Johannes Schindelin 2009-03-20 18:02 ` Junio C Hamano @ 2009-03-20 23:08 ` Julian Phillips 2009-03-20 23:20 ` Sverre Rabbelier 2009-03-21 0:35 ` Andreas Gruenbacher 2 siblings, 2 replies; 61+ messages in thread From: Julian Phillips @ 2009-03-20 23:08 UTC (permalink / raw) To: Junio C Hamano Cc: Johannes Schindelin, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink, git 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! ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 23:08 ` Julian Phillips @ 2009-03-20 23:20 ` Sverre Rabbelier 2009-03-20 23:41 ` Julian Phillips 2009-03-21 0:35 ` Andreas Gruenbacher 1 sibling, 1 reply; 61+ messages in thread From: Sverre Rabbelier @ 2009-03-20 23:20 UTC (permalink / raw) To: Julian Phillips Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 23:20 ` Sverre Rabbelier @ 2009-03-20 23:41 ` Julian Phillips 2009-03-20 23:45 ` Sverre Rabbelier 0 siblings, 1 reply; 61+ messages in thread From: Julian Phillips @ 2009-03-20 23:41 UTC (permalink / raw) To: Sverre Rabbelier Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 23:41 ` Julian Phillips @ 2009-03-20 23:45 ` Sverre Rabbelier 0 siblings, 0 replies; 61+ messages in thread From: Sverre Rabbelier @ 2009-03-20 23:45 UTC (permalink / raw) To: Julian Phillips Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 23:08 ` Julian Phillips 2009-03-20 23:20 ` Sverre Rabbelier @ 2009-03-21 0:35 ` Andreas Gruenbacher 2009-03-21 1:10 ` Miles Bader 2009-03-21 13:24 ` Julian Phillips 1 sibling, 2 replies; 61+ messages in thread From: Andreas Gruenbacher @ 2009-03-21 0:35 UTC (permalink / raw) To: Julian Phillips Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis, B.Steinbrink, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-21 0:35 ` Andreas Gruenbacher @ 2009-03-21 1:10 ` Miles Bader 2009-03-21 13:24 ` Julian Phillips 1 sibling, 0 replies; 61+ messages in thread From: Miles Bader @ 2009-03-21 1:10 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-21 0:35 ` Andreas Gruenbacher 2009-03-21 1:10 ` Miles Bader @ 2009-03-21 13:24 ` Julian Phillips 2009-03-21 13:28 ` Julian Phillips 1 sibling, 1 reply; 61+ messages in thread From: Julian Phillips @ 2009-03-21 13:24 UTC (permalink / raw) To: Andreas Gruenbacher Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis, B.Steinbrink, git 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-21 13:24 ` Julian Phillips @ 2009-03-21 13:28 ` Julian Phillips 0 siblings, 0 replies; 61+ messages in thread From: Julian Phillips @ 2009-03-21 13:28 UTC (permalink / raw) To: Andreas Gruenbacher Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis, B.Steinbrink, git 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 16:17 ` [PATCH v4] Introduce %<branch> as shortcut to " Johannes Schindelin 2009-03-20 17:03 ` Junio C Hamano @ 2009-03-20 17:08 ` Björn Steinbrink 1 sibling, 0 replies; 61+ messages in thread From: Björn Steinbrink @ 2009-03-20 17:08 UTC (permalink / raw) To: Johannes Schindelin Cc: Shawn O. Pearce, Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 0:40 ` Shawn O. Pearce 2009-03-20 0:44 ` Shawn O. Pearce @ 2009-03-20 6:05 ` Jeff King 2009-03-20 6:57 ` Junio C Hamano 2009-03-21 21:00 ` Junio C Hamano 2 siblings, 1 reply; 61+ messages in thread From: Jeff King @ 2009-03-20 6:05 UTC (permalink / raw) To: Shawn O. Pearce Cc: Johannes Schindelin, Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 6:05 ` ref name troubles, was Re: [PATCH v2] " Jeff King @ 2009-03-20 6:57 ` Junio C Hamano 2009-03-20 9:30 ` Johannes Schindelin 0 siblings, 1 reply; 61+ messages in thread From: Junio C Hamano @ 2009-03-20 6:57 UTC (permalink / raw) To: Jeff King Cc: Shawn O. Pearce, Johannes Schindelin, Petr Baudis, Andreas Gruenbacher, git 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 6:57 ` Junio C Hamano @ 2009-03-20 9:30 ` Johannes Schindelin 2009-03-20 11:12 ` Petr Baudis 0 siblings, 1 reply; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 9:30 UTC (permalink / raw) To: Junio C Hamano Cc: Jeff King, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 9:30 ` Johannes Schindelin @ 2009-03-20 11:12 ` Petr Baudis 2009-03-20 11:46 ` Johannes Schindelin 2009-03-20 16:47 ` Junio C Hamano 0 siblings, 2 replies; 61+ messages in thread From: Petr Baudis @ 2009-03-20 11:12 UTC (permalink / raw) To: Johannes Schindelin Cc: Junio C Hamano, Jeff King, Shawn O. Pearce, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 11:12 ` Petr Baudis @ 2009-03-20 11:46 ` Johannes Schindelin 2009-03-20 11:50 ` Petr Baudis 2009-03-20 16:47 ` Junio C Hamano 1 sibling, 1 reply; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 11:46 UTC (permalink / raw) To: Petr Baudis Cc: Junio C Hamano, Jeff King, Shawn O. Pearce, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 11:46 ` Johannes Schindelin @ 2009-03-20 11:50 ` Petr Baudis 2009-03-20 11:57 ` Johannes Schindelin 0 siblings, 1 reply; 61+ messages in thread From: Petr Baudis @ 2009-03-20 11:50 UTC (permalink / raw) To: Johannes Schindelin Cc: Junio C Hamano, Jeff King, Shawn O. Pearce, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 11:50 ` Petr Baudis @ 2009-03-20 11:57 ` Johannes Schindelin 2009-03-20 14:31 ` Michael J Gruber 0 siblings, 1 reply; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 11:57 UTC (permalink / raw) To: Petr Baudis Cc: Junio C Hamano, Jeff King, Shawn O. Pearce, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 11:57 ` Johannes Schindelin @ 2009-03-20 14:31 ` Michael J Gruber 2009-03-20 15:01 ` Johannes Schindelin 0 siblings, 1 reply; 61+ messages in thread From: Michael J Gruber @ 2009-03-20 14:31 UTC (permalink / raw) To: Johannes Schindelin Cc: Petr Baudis, Junio C Hamano, Jeff King, Shawn O. Pearce, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 14:31 ` Michael J Gruber @ 2009-03-20 15:01 ` Johannes Schindelin 2009-03-20 15:12 ` Michael J Gruber 0 siblings, 1 reply; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 15:01 UTC (permalink / raw) To: Michael J Gruber Cc: Petr Baudis, Junio C Hamano, Jeff King, Shawn O. Pearce, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 15:01 ` Johannes Schindelin @ 2009-03-20 15:12 ` Michael J Gruber 0 siblings, 0 replies; 61+ messages in thread From: Michael J Gruber @ 2009-03-20 15:12 UTC (permalink / raw) To: Johannes Schindelin Cc: Petr Baudis, Junio C Hamano, Jeff King, Shawn O. Pearce, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 11:12 ` Petr Baudis 2009-03-20 11:46 ` Johannes Schindelin @ 2009-03-20 16:47 ` Junio C Hamano 2009-03-20 19:34 ` Daniel Barkalow 1 sibling, 1 reply; 61+ messages in thread From: Junio C Hamano @ 2009-03-20 16:47 UTC (permalink / raw) To: Petr Baudis Cc: Johannes Schindelin, Jeff King, Shawn O. Pearce, Andreas Gruenbacher, git 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. ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 16:47 ` Junio C Hamano @ 2009-03-20 19:34 ` Daniel Barkalow 2009-03-20 21:48 ` Johannes Schindelin 0 siblings, 1 reply; 61+ messages in thread From: Daniel Barkalow @ 2009-03-20 19:34 UTC (permalink / raw) To: Junio C Hamano Cc: Petr Baudis, Johannes Schindelin, Jeff King, Shawn O. Pearce, Andreas Gruenbacher, git 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* ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 19:34 ` Daniel Barkalow @ 2009-03-20 21:48 ` Johannes Schindelin 0 siblings, 0 replies; 61+ messages in thread From: Johannes Schindelin @ 2009-03-20 21:48 UTC (permalink / raw) To: Daniel Barkalow Cc: Junio C Hamano, Petr Baudis, Jeff King, Shawn O. Pearce, Andreas Gruenbacher, git 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 ^ permalink raw reply [flat|nested] 61+ messages in thread
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch 2009-03-20 0:40 ` Shawn O. Pearce 2009-03-20 0:44 ` Shawn O. Pearce 2009-03-20 6:05 ` ref name troubles, was Re: [PATCH v2] " Jeff King @ 2009-03-21 21:00 ` Junio C Hamano 2 siblings, 0 replies; 61+ messages in thread From: Junio C Hamano @ 2009-03-21 21:00 UTC (permalink / raw) To: Shawn O. Pearce Cc: Johannes Schindelin, Petr Baudis, Andreas Gruenbacher, git "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 ^ permalink raw reply related [flat|nested] 61+ messages in thread
end of thread, other threads:[~2009-03-22 17:41 UTC | newest] Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <200903181448.50706.agruen@suse.de> 2009-03-18 18:26 ` Git {log,diff} against tracked branch? Petr Baudis 2009-03-18 21:12 ` [PATCH] Introduce %<branch> as shortcut to the tracked branch Johannes Schindelin 2009-03-18 21:41 ` Andreas Gruenbacher 2009-03-18 21:46 ` [PATCH v2] " Johannes Schindelin 2009-03-18 21:58 ` Andreas Gruenbacher 2009-03-18 22:43 ` Johannes Schindelin 2009-03-18 22:34 ` Junio C Hamano 2009-03-18 22:46 ` Johannes Schindelin 2009-03-19 14:52 ` Michael J Gruber 2009-03-19 15:17 ` Michael J Gruber 2009-03-20 0:23 ` Johannes Schindelin 2009-03-20 0:38 ` ref name troubles, was " Johannes Schindelin 2009-03-20 0:40 ` Shawn O. Pearce 2009-03-20 0:44 ` Shawn O. Pearce 2009-03-20 5:59 ` Sverre Rabbelier 2009-03-20 9:29 ` [PATCH v3] Introduce BEL<branch> " Johannes Schindelin 2009-03-20 9:42 ` Wincent Colaiuta 2009-03-20 9:54 ` Johannes Schindelin 2009-03-20 12:33 ` Santi Béjar 2009-03-20 12:45 ` Andreas Gruenbacher 2009-03-20 13:05 ` Matthieu Moy 2009-03-20 12:46 ` Johannes Schindelin 2009-03-20 12:53 ` Mikael Magnusson 2009-03-20 14:00 ` Johannes Schindelin 2009-03-20 10:04 ` [PATCH] Document and test the new % shotcut for " Michael J Gruber 2009-03-20 10:31 ` Johannes Schindelin 2009-03-20 10:38 ` Michael J Gruber 2009-03-20 11:16 ` Petr Baudis 2009-03-20 11:48 ` Johannes Schindelin 2009-03-22 17:40 ` Petr Baudis 2009-03-20 14:15 ` Michael J Gruber 2009-03-20 16:17 ` [PATCH v4] Introduce %<branch> as shortcut to " Johannes Schindelin 2009-03-20 17:03 ` Junio C Hamano 2009-03-20 17:32 ` Johannes Schindelin 2009-03-20 18:02 ` Junio C Hamano 2009-03-20 19:36 ` Jeff King 2009-03-20 20:28 ` Julian Phillips 2009-03-20 20:50 ` Jeff King 2009-03-20 23:08 ` Julian Phillips 2009-03-20 23:20 ` Sverre Rabbelier 2009-03-20 23:41 ` Julian Phillips 2009-03-20 23:45 ` Sverre Rabbelier 2009-03-21 0:35 ` Andreas Gruenbacher 2009-03-21 1:10 ` Miles Bader 2009-03-21 13:24 ` Julian Phillips 2009-03-21 13:28 ` Julian Phillips 2009-03-20 17:08 ` Björn Steinbrink 2009-03-20 6:05 ` ref name troubles, was Re: [PATCH v2] " Jeff King 2009-03-20 6:57 ` Junio C Hamano 2009-03-20 9:30 ` Johannes Schindelin 2009-03-20 11:12 ` Petr Baudis 2009-03-20 11:46 ` Johannes Schindelin 2009-03-20 11:50 ` Petr Baudis 2009-03-20 11:57 ` Johannes Schindelin 2009-03-20 14:31 ` Michael J Gruber 2009-03-20 15:01 ` Johannes Schindelin 2009-03-20 15:12 ` Michael J Gruber 2009-03-20 16:47 ` Junio C Hamano 2009-03-20 19:34 ` Daniel Barkalow 2009-03-20 21:48 ` Johannes Schindelin 2009-03-21 21:00 ` Junio C Hamano
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.