revlist/rev-parse: Introduce --heads and --locals revision specifiers

Due to the increasing usage of the ref namespace (e.g. notes, replace) the revision specifier "--all" becomes decreasingly useful. But "something like --all" is ineeded for getting a quick overview of the development state of a repository.

Introduce --heads and --locals specifiers in order to help with that:

--heads == HEAD --branches --remotes
--locals = HEAD --branches --tags

---
RFD for several reasons:

- It's incredibly useful, I want it - do others? ;)
- names of the options (let the bikeshedding begin)
- should rev-parse include HEAD?
- tests and doc, of course

rev-parse does not include HEAD even with --all, but rev-list does. The patch keeps with that tradition (the commit message does not quite convey this). I don't feel it's a good one. Cleaning that up requires more work, though.

 builtin/rev-list.c  |    2 ++
 builtin/rev-parse.c |   12 ++++++++++++
 revision.c          |   12 ++++++++++++
 3 files changed, 26 insertions(+), 0 deletions(-)

index 51ceb19..fb8208c 100644
@@ -20,7 +20,9 @@ static const char rev_list_usage[] =
 "    --all\n"
 "    --branches\n"
 "    --tags\n"
+"    --locals\n"
 "    --remotes\n"
+"    --heads\n"
 "    --stdin\n"
 "    --quiet\n"
 "  ordering output:\n"

index 8fbf9d0..c739479 100644
@@ -44,6 +44,8 @@ static int is_rev_argument(const char *arg)
 		"--branches=",
 		"--branches",
 		"--header",
+		"--heads",
+		"--locals",
 		"--max-age=",
 		"--max-count=",
 		"--min-age=",

@@ -598,6 +600,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
 				for_each_tag_ref(show_reference, NULL);
 				continue;
 			}
+			if (!strcmp(arg, "--locals")) {
+				for_each_branch_ref(show_reference, NULL);
+				for_each_tag_ref(show_reference, NULL);
+				continue;
+			}
 			if (!prefixcmp(arg, "--glob=")) {
 				for_each_glob_ref(show_reference, arg + 7, NULL);
 				continue;

@@ -611,6 +618,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
 				for_each_remote_ref(show_reference, NULL);
 				continue;
 			}
+			if (!strcmp(arg, "--heads")) {
+				for_each_branch_ref(show_reference, NULL);
+				for_each_remote_ref(show_reference, NULL);
+				continue;
+			}
 			if (!strcmp(arg, "--show-toplevel")) {
 				const char *work_tree = get_git_work_tree();
 				if (work_tree)

index f4b8b38..04f9be7 100644
@@ -1399,10 +1399,22 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s
 				handle_refs(revs, flags, for_each_tag_ref);
 				continue;
 			}
+			if (!strcmp(arg, "--locals")) {
+				handle_refs(revs, flags, for_each_branch_ref);
+				handle_refs(revs, flags, for_each_tag_ref);
+				handle_refs(revs, flags, head_ref);
+				continue;
+			}
 			if (!strcmp(arg, "--remotes")) {
 				handle_refs(revs, flags, for_each_remote_ref);
 				continue;
 			}
+			if (!strcmp(arg, "--heads")) {
+				handle_refs(revs, flags, for_each_remote_ref);
+				handle_refs(revs, flags, for_each_branch_ref);
+				handle_refs(revs, flags, head_ref);
+				continue;
+			}
 			if (!prefixcmp(arg, "--glob=")) {
 				struct all_refs_cb cb;
 				init_all_refs_cb(&cb, revs, flags);

1.7.1.328.g9993c

I don't have anything against the concept, but "--heads" is a horrible name, as it implies refs/heads (which is of course what --branches does. Yikes!). I know why you picked it, and once you think about it, yes, it does make some sense (it is all the local and remote heads), but I am worried that it will cause confusion.

-Peff

Jeff King venit, vidit, dixit 02.05.2010 07:00:

I second your Yikes... but won't suggest renaming refs/heads.

So, your alternative suggestion is...? ;)

How about --tips? But I don't like that. We really use head as the term for the tip (ordered end-vertex) of a branch, be it local or remote. I would hope that ordinary users do not have to deal with the layout under refs, and thus won't be confused. But people peel and poke everywhere where there not supposed to :)

Michael

I have to criticize _and_ suggest? Sheesh.

I don't like it either. Really, "--branches" is a reasonable description of what you are providing, but that is already taken. :)

I can't think of another place in git where we collectively refer to local and remote branch heads by a single term. The closest is git-branch's "-a". You could do "--all-branches", but this was meant to save some typing, so it probably fails on that count.

The problem with things like --tips, --heads, or --branches, is that there is nothing to say "I mean _both_ local and remote" as opposed to just local. And I'm not sure there is a way to say that without getting long. I guess "--all-heads" is shorter, but still ugly.

Yeah. Originally both of those things were in refs/heads/, but the "separate remote" layout has been standard for some time. Even Junio may have switched by now. :)

I think refs/heads is something many git users know about. Git was designed from the start to have a simple data model, and that model (including things like ref naming) was always exposed to the user. That's what makes it so flexible, and of course is what makes many people complain.

These days that data model is a little more hidden, but I think you do still see the refs hierarchy. Certainly users see "remotes/" (e.g., in "git branch -a"), though perhaps they don't necessarily realize how it relates to refs/ and refs/heads/. Full ref names are also used for disambiguation, though I suppose most people never need to deal with that. But the first time one runs "git for-each-ref" (I know, I manage to work it into every conversation, right?) you get full exposure.

-Peff

This command used to be used to distinguish between parameters meant for rev-list and others, but this is deprectated now, and one should not rely on rev-parse keeping up to date with rev-list. State this in the man page and reword the title according to the primary use (converting symbolic names to SHA1's).

Reference: <http://permalink.gmane.org/gmane.comp.version-control.git/146118>

---
 Documentation/git-rev-parse.txt |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

index 8db600f..99d2a79 100644
@@ -3,7 +3,7 @@ git-rev-parse(1)
 
 NAME
 ----
-git-rev-parse - Pick out and massage parameters
+git-rev-parse - Parse symbolic names into object names
 
 
 SYNOPSIS

@@ -13,12 +13,18 @@ SYNOPSIS
 DESCRIPTION
 -----------
 
-Many git porcelainish commands take mixture of flags
+The primary use of 'git rev-parse' is to turn symbolic object names into
+40-letter object names ("SHA-1").
+
+Also, many git porcelainish commands take a mixture of flags
 (i.e. parameters that begin with a dash '-') and parameters
 meant for the underlying 'git rev-list' command they use internally
 and flags and parameters for the other commands they use
-downstream of 'git rev-list'.  This command is used to
-distinguish between them.
+downstream of 'git rev-list'.  This command used to be used to
+distinguish between them, but this is deprectated now, and you should
+not expect 'git rev-parse' to keep up to date with newer parameters for
+'git rev-list'. You can use linkgit:git-rev-list[1] directly or
+linkgit:git-for-each-ref[1] for scripting.
 
 
 OPTIONS

1.7.1.240.geeaa4d

Jakub Narebski venit, vidit, dixit 14.05.2010 17:41:

Sure it is. But if you read the part of the patch that you cut out (i.e. the comment and relevant diff) you see that the massaging part is the deprecated part of it. That's why I suggest not mentioning it at the most prominent place. (I don't suggest removing that functionality.)

Michael

"git rev-parse --parseopt" is not deprecated. What is deprecated is --revs-only, --flags, etc.

Jakub Narebski
Poland

Jakub Narebski venit, vidit, dixit 14.05.2010 21:01:

Still, I would say that "massage parameters" refers to all parameter massaging including '--flags' etc. And, my paragraph about deprecation mentions the option sifting part only.

Cheers,
Michael

git-filter-branch uses --revs-only and --no-revs, and I'm not sure how it could avoid doing so without losing a lot of flexibility (or knowing a list of options, which is worse)...

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

so that we know when they break.

---
 t/t6018-rev-list-glob.sh |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

index 8d3fa7d..dbedc4d 100755
@@ -162,6 +162,13 @@ test_expect_success 'rev-list --branches=subspace' '
 	compare rev-list "subspace/one subspace/two" "--branches=subspace"
 
 '
+
+test_expect_success 'rev-list --branches' '
+
+	compare rev-list "master subspace-x someref other/three subspace/one subspace/two" "--branches"
+
+'
+
 test_expect_success 'rev-list --glob=heads/someref/* master' '
 
 	compare rev-list "master" "--glob=heads/someref/* master"

@@ -186,6 +193,12 @@ test_expect_success 'rev-list --tags=foo' '
 
 '
 
+test_expect_success 'rev-list --tags' '
+
+	compare rev-list "foo/bar" "--tags"
+
+'
+
 test_expect_success 'rev-list --remotes=foo' '
 
 	compare rev-list "foo/baz" "--remotes=foo"

1.7.1.240.geeaa4d

---
 t/t6018-rev-list-glob.sh |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

index dbedc4d..a1320aa 100755
@@ -34,7 +34,9 @@ test_expect_success 'setup' '
 	git checkout master &&
 	commit master2 &&
 	git tag foo/bar master &&
-	git update-ref refs/remotes/foo/baz master
+	commit master3 &&
+	git update-ref refs/remotes/foo/baz master &&
+	commit master4
 '
 
 test_expect_success 'rev-parse --glob=refs/heads/subspace/*' '

@@ -205,4 +207,16 @@ test_expect_success 'rev-list --remotes=foo' '
 
 '
 
+test_expect_success 'rev-list --locals' '
+
+	compare rev-list "master subspace-x someref other/three subspace/one subspace/two" "--localss"
+
+'
+
+test_expect_success 'rev-list --lrbranches' '
+
+	compare rev-list "master subspace-x someref other/three subspace/one subspace/two" "--lrbranches"
+
+'
+
 test_done

1.7.1.240.geeaa4d

This series introduces --lrbranches and --locals as abbreviations for "HEAD --branches --remotes" (local and remote branches) resp. "HEAD --branches --tags" (local refs).
They are becoming increasingly necessary as refs/ is growing with auxiliary refs such as notes and replacements, so that "--all" is too much :)

While at it, or rather: in preparation, we note rev-parse as being deprectated as an option sifter (as discussed on list) and clean up and complete t6018.

Michael J Gruber (4):
rev-parse: deprecate use as an option sifter
t6018: add tests for rev-list's --branches and --tags
t6018: make sure all tested symbolic names are different revs
revlist: Introduce --lrbranches and --locals revision specifiers

 Documentation/git-rev-list.txt     |    2 ++
 Documentation/git-rev-parse.txt    |   14 ++++++++++----
 Documentation/rev-list-options.txt |    8 ++++++++
 builtin/rev-list.c                 |    2 ++
 revision.c                         |   12 ++++++++++++
 t/t6018-rev-list-glob.sh           |   33 ++++++++++++++++++++++++++++++++-
 6 files changed, 66 insertions(+), 5 deletions(-)

Thanks. --lrbranches is still a little ugly to me, but it does address my concern with --heads, and I don't have a better suggestion.

Patch 4/4 itself looks OK. Did you test each part of the series independently, though? It looks like 3/4 tests --lrbranches, which isn't introduced until 4/4.

-Peff

Jeff King venit, vidit, dixit 14.05.2010 08:06:

Sheesh. I did test them individually, of course. That is, before reordering with rebase -i and "fixup!"ing the last one. I probably squashed them in the wrong order :(

I always get confused by the ordering in the action script, which is just the reverse of git log --oneline.

I'm sorry I didn't catch this myself, I'll rerebase-eee asap.

Michael

This command used to be used to distinguish between parameters meant for rev-list and others, but this is deprectated now, and one should not rely on rev-parse keeping up to date with rev-list. State this in the man page and reword the title according to the primary use (converting symbolic names to SHA1's).

Reference: <http://permalink.gmane.org/gmane.comp.version-control.git/146118>

---
 Documentation/git-rev-parse.txt |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

index 8db600f..99d2a79 100644
@@ -3,7 +3,7 @@ git-rev-parse(1)
 
 NAME
 ----
-git-rev-parse - Pick out and massage parameters
+git-rev-parse - Parse symbolic names into object names
 
 
 SYNOPSIS

@@ -13,12 +13,18 @@ SYNOPSIS
 DESCRIPTION
 -----------
 
-Many git porcelainish commands take mixture of flags
+The primary use of 'git rev-parse' is to turn symbolic object names into
+40-letter object names ("SHA-1").
+
+Also, many git porcelainish commands take a mixture of flags
 (i.e. parameters that begin with a dash '-') and parameters
 meant for the underlying 'git rev-list' command they use internally
 and flags and parameters for the other commands they use
-downstream of 'git rev-list'.  This command is used to
-distinguish between them.
+downstream of 'git rev-list'.  This command used to be used to
+distinguish between them, but this is deprectated now, and you should
+not expect 'git rev-parse' to keep up to date with newer parameters for
+'git rev-list'. You can use linkgit:git-rev-list[1] directly or
+linkgit:git-for-each-ref[1] for scripting.
 
 
 OPTIONS

1.7.1.240.geeaa4d

so that we know when they break.

---
 t/t6018-rev-list-glob.sh |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

index 8d3fa7d..dbedc4d 100755
@@ -162,6 +162,13 @@ test_expect_success 'rev-list --branches=subspace' '
 	compare rev-list "subspace/one subspace/two" "--branches=subspace"
 
 '
+
+test_expect_success 'rev-list --branches' '
+
+	compare rev-list "master subspace-x someref other/three subspace/one subspace/two" "--branches"
+
+'
+
 test_expect_success 'rev-list --glob=heads/someref/* master' '
 
 	compare rev-list "master" "--glob=heads/someref/* master"

@@ -186,6 +193,12 @@ test_expect_success 'rev-list --tags=foo' '
 
 '
 
+test_expect_success 'rev-list --tags' '
+
+	compare rev-list "foo/bar" "--tags"
+
+'
+
 test_expect_success 'rev-list --remotes=foo' '
 
 	compare rev-list "foo/baz" "--remotes=foo"

1.7.1.240.geeaa4d

All,

I am trying to setup a "reliable" flow with git. I am sort of new to the tool and need some help from the experts. The question pertains to the way SHA1 tags can be back-tracked in parallel clones. Here is the scenario I have in mind:

In order of time:
User1 – pulls from the origin; updates, modifies, verifies and commits into his clone. This will generate SHA1_1 User2 – pulls from the origin; updates, modifies, verifies and commits into his clone. This will generate SHA1_2 User3 – pulls from the origin; updates, modifies, verifies and commits into his clone. This will generate SHA1_3

In none of these cases, anyone is updating from each other’s clones

At the end of the week, the model builder needs to merge and verify all commits from user1, user2 and user3 before pushing into the origin master.

The question is,
Can the model builder use SHA1_3 tag only to get all the updates made by user1, user2 and user3; or all SHA1 tags are needed?

Thanks,
Farshad.

Hi,

I'm not sure if I entirely understand your question. Is "the model builder" a person?

Making the assumption that it is (the usual term for this would be a project maintainer) then you might wan to have a read of the "DISTRIBUTED WORKFLOWS" section of the gitworkflows man page [1].

The short answer, if I've understood your question, is that all 3 developers will have to submit their work to the maintainer. There are various mechanisms for this; they can either use "git format-patch" and "git send-email" or request that the maintainer pulls from a repository that they have published ("git request-pull" can help by generating a nicely formatted email message).

After the maintainer has applied the changes the developers can then use "git pull" to get the latest changes from the origin. This will include their change and the changes from the other developers and may also include some merge commits.

As developers get more advanced they may start working on topic branches and re-basing (or deleting) the branches after the maintainer has applied their changes. Remember that in this case the topic branches are local so the developers can do what they like with them. The maintainer doesn't care _how_ the developers work locally they are just concerned with the end result.

Hope that helps.

---

[1] http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_distributed_workflows

You will definitely need all three commit ids (SHA1_* in your words) since all three commits are totally independent from each other.

In order for someone to *get* all three of those commits, they will have to retrieve them somehow. Generally, you do it in one of these ways:

1) Run a git-daemon (or similar) on all three users' machines, and let the model builder 'git pull' from all three servers

or

2) Have all three users 'git push' to a different branch on the central repo, as in "git push origin HEAD:user1", "git push origin HEAD:user2" and so on, and have the model builder merge all three branches and then push the result back to master.

Of course, you could also have everybody pulling from / pushing to master directly, but I guess that isn't what you're trying to accomplish (it sounds like you want your "model builder" to be a central maintainer who decides what does/doesn't get into the main trunk).

Have fun,

Avery

Resent with correct rebasing/squasing:
1,2 are unchanged
The introduction of tests for the new options is moved from 3 to 4 as originally intended.

Michael J Gruber (4):
rev-parse: deprecate use as an option sifter
t6018: add tests for rev-list's --branches and --tags
t6018: make sure all tested symbolic names are different revs
revlist: Introduce --lrbranches and --locals revision specifiers

 Documentation/git-rev-list.txt     |    2 ++
 Documentation/git-rev-parse.txt    |   14 ++++++++++----
 Documentation/rev-list-options.txt |    8 ++++++++
 builtin/rev-list.c                 |    2 ++
 revision.c                         |   12 ++++++++++++
 t/t6018-rev-list-glob.sh           |   33 ++++++++++++++++++++++++++++++++-
 6 files changed, 66 insertions(+), 5 deletions(-)

---
 t/t6018-rev-list-glob.sh |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

index dbedc4d..58428d9 100755
@@ -34,7 +34,9 @@ test_expect_success 'setup' '
 	git checkout master &&
 	commit master2 &&
 	git tag foo/bar master &&
-	git update-ref refs/remotes/foo/baz master
+	commit master3 &&
+	git update-ref refs/remotes/foo/baz master &&
+	commit master4
 '
 
 test_expect_success 'rev-parse --glob=refs/heads/subspace/*' '

1.7.1.240.geeaa4d

Due to the increasing usage of the ref namespace (e.g. notes, replace) the revision specifier "--all" becomes decreasingly useful. But "something like --all" is needed for getting a quick overview of the development state of a repository.

Introduce --lrbranches and --locals specifiers in order to help with that:

--lrbranches == HEAD --branches --remotes
--locals = HEAD --branches --tags

---
 Documentation/git-rev-list.txt     |    2 ++
 Documentation/rev-list-options.txt |    8 ++++++++
 builtin/rev-list.c                 |    2 ++
 revision.c                         |   12 ++++++++++++
 t/t6018-rev-list-glob.sh           |   16 ++++++++++++++++
 5 files changed, 40 insertions(+), 0 deletions(-)

index 173f3fc..81d67da 100644
@@ -25,6 +25,8 @@ SYNOPSIS
 	     [ \--tags[=pattern] ]
 	     [ \--remotes[=pattern] ]
 	     [ \--glob=glob-pattern ]
+	     [ \--locals ]
+	     [ \--lrbranches ]
 	     [ \--stdin ]
 	     [ \--quiet ]
 	     [ \--topo-order ]

index b9fb7a8..21c0c93 100644
@@ -264,6 +264,14 @@ endif::git-rev-list[]
 	is automatically prepended if missing. If pattern lacks '?', '*',
 	or '[', '/*' at the end is implied.
 
+--locals::
+	This is an abbreviation for `HEAD --branches --tags`, i.e. all
+	local refs.
+
+--lrbranches::
+
+	This is an abbreviation for `HEAD --branches --remotes`, i.e. all
+	local and remote branch heads plus HEAD.
 
 ifndef::git-rev-list[]
 --bisect::

index 51ceb19..50664b7 100644
@@ -20,7 +20,9 @@ static const char rev_list_usage[] =
 "    --all\n"
 "    --branches\n"
 "    --tags\n"
+"    --locals\n"
 "    --remotes\n"
+"    --lrbranches\n"
 "    --stdin\n"
 "    --quiet\n"
 "  ordering output:\n"

index f4b8b38..5067fce 100644
@@ -1399,10 +1399,22 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s
 				handle_refs(revs, flags, for_each_tag_ref);
 				continue;
 			}
+			if (!strcmp(arg, "--locals")) {
+				handle_refs(revs, flags, for_each_branch_ref);
+				handle_refs(revs, flags, for_each_tag_ref);
+				handle_refs(revs, flags, head_ref);
+				continue;
+			}
 			if (!strcmp(arg, "--remotes")) {
 				handle_refs(revs, flags, for_each_remote_ref);
 				continue;
 			}
+			if (!strcmp(arg, "--lrbranches")) {
+				handle_refs(revs, flags, for_each_remote_ref);
+				handle_refs(revs, flags, for_each_branch_ref);
+				handle_refs(revs, flags, head_ref);
+				continue;
+			}
 			if (!prefixcmp(arg, "--glob=")) {
 				struct all_refs_cb cb;
 				init_all_refs_cb(&cb, revs, flags);

index 58428d9..fd77fe5 100755
@@ -207,4 +207,20 @@ test_expect_success 'rev-list --remotes=foo' '
 
 '
 
+test_expect_success 'rev-list --no-walk --locals' '
+
+	compare "rev-list --no-walk" \
+	"master subspace-x someref other/three subspace/one subspace/two foo/bar" \
+	"--locals"
+
+'
+
+test_expect_success 'rev-list --no-walk --lrbranches' '
+
+	compare "rev-list --no-walk" \
+	"master subspace-x someref other/three subspace/one subspace/two foo/baz" \
+	"--lrbranches"
+
+'
+
 test_done

1.7.1.240.geeaa4d

Due to the increasing usage of the ref namespace (e.g. notes, replace) the revision specifier "--all" becomes decreasingly useful. But "something like --all" is needed for getting a quick overview of the development state of a repository.

Introduce --lrbranches and --locals specifiers in order to help with that:

--lrbranches == HEAD --branches --remotes
--locals = HEAD --branches --tags

---
 Documentation/git-rev-list.txt     |    2 ++
 Documentation/rev-list-options.txt |    8 ++++++++
 builtin/rev-list.c                 |    2 ++
 revision.c                         |   12 ++++++++++++
 t/t6018-rev-list-glob.sh           |   12 ++++++++----
 5 files changed, 32 insertions(+), 4 deletions(-)

index 173f3fc..81d67da 100644
@@ -25,6 +25,8 @@ SYNOPSIS
 	     [ \--tags[=pattern] ]
 	     [ \--remotes[=pattern] ]
 	     [ \--glob=glob-pattern ]
+	     [ \--locals ]
+	     [ \--lrbranches ]
 	     [ \--stdin ]
 	     [ \--quiet ]
 	     [ \--topo-order ]

index b9fb7a8..21c0c93 100644
@@ -264,6 +264,14 @@ endif::git-rev-list[]
 	is automatically prepended if missing. If pattern lacks '?', '*',
 	or '[', '/*' at the end is implied.
 
+--locals::
+	This is an abbreviation for `HEAD --branches --tags`, i.e. all
+	local refs.
+
+--lrbranches::
+
+	This is an abbreviation for `HEAD --branches --remotes`, i.e. all
+	local and remote branch heads plus HEAD.
 
 ifndef::git-rev-list[]
 --bisect::

index 51ceb19..50664b7 100644
@@ -20,7 +20,9 @@ static const char rev_list_usage[] =
 "    --all\n"
 "    --branches\n"
 "    --tags\n"
+"    --locals\n"
 "    --remotes\n"
+"    --lrbranches\n"
 "    --stdin\n"
 "    --quiet\n"
 "  ordering output:\n"

index f4b8b38..5067fce 100644
@@ -1399,10 +1399,22 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s
 				handle_refs(revs, flags, for_each_tag_ref);
 				continue;
 			}
+			if (!strcmp(arg, "--locals")) {
+				handle_refs(revs, flags, for_each_branch_ref);
+				handle_refs(revs, flags, for_each_tag_ref);
+				handle_refs(revs, flags, head_ref);
+				continue;
+			}
 			if (!strcmp(arg, "--remotes")) {
 				handle_refs(revs, flags, for_each_remote_ref);
 				continue;
 			}
+			if (!strcmp(arg, "--lrbranches")) {
+				handle_refs(revs, flags, for_each_remote_ref);
+				handle_refs(revs, flags, for_each_branch_ref);
+				handle_refs(revs, flags, head_ref);
+				continue;
+			}
 			if (!prefixcmp(arg, "--glob=")) {
 				struct all_refs_cb cb;
 				init_all_refs_cb(&cb, revs, flags);

index a1320aa..fd77fe5 100755
@@ -207,15 +207,19 @@ test_expect_success 'rev-list --remotes=foo' '
 
 '
 
-test_expect_success 'rev-list --locals' '
+test_expect_success 'rev-list --no-walk --locals' '
 
-	compare rev-list "master subspace-x someref other/three subspace/one subspace/two" "--localss"
+	compare "rev-list --no-walk" \
+	"master subspace-x someref other/three subspace/one subspace/two foo/bar" \
+	"--locals"
 
 '
 
-test_expect_success 'rev-list --lrbranches' '
+test_expect_success 'rev-list --no-walk --lrbranches' '
 
-	compare rev-list "master subspace-x someref other/three subspace/one subspace/two" "--lrbranches"
+	compare "rev-list --no-walk" \
+	"master subspace-x someref other/three subspace/one subspace/two foo/baz" \
+	"--lrbranches"
 
 '
 

1.7.1.240.geeaa4d

Wouldn't new feature (introduced in 1.7.0) of --glob=<glob-pattern> be enough?

Jakub Narebski
Poland
ShadeHawk on #git

Jakub Narebski venit, vidit, dixit 01.05.2010 21:42:

You can already use the exact expressions which I wrote above ("--branches --tags" etc.). The point is to have short ones for the most useful cases. And "--all" used to be useful.

It's just that we don't have aliases for rev notation ;)

Michael

Ah, sorry, I have misunderstood the goal of your change.

Seems like a good idea.

Jakub Narebski
Poland