threads / patch / 23659

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

Subject: [RFD PATCH] revlist/rev-parse: Introduce --heads and --locals revision specifiers

## tl;dr

27 messages between May 1, 2010 and May 17, 2010. Diffs are folded; open one to read it.

replies: 26people: 7as markdown or json

Michael J Gruber· May 1, 2010, 18:36 UTC · lore

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

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
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(-)
Show changes to 3 files +26 −0

builtin/rev-list.c, builtin/rev-parse.c, revision.c

diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 51ceb19..fb8208c 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -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"
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index 8fbf9d0..c739479 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -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)
diff --git a/revision.c b/revision.c
index f4b8b38..04f9be7 100644
--- a/revision.c
+++ b/revision.c
@@ -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
Jakub Narebski· May 1, 2010, 19:42 UTC · re: Michael J Gruber · lore

Re: [RFD PATCH] revlist/rev-parse: Introduce --heads and --locals revision specifiers

Michael J Gruber <git@drmicha.warpmail.net> writes:
Show 9 quoted lines
> 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

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

-- 
Jakub Narebski
Poland
ShadeHawk on #git
Michael J Gruber· May 1, 2010, 19:47 UTC · re: Jakub Narebski · lore

Re: [RFD PATCH] revlist/rev-parse: Introduce --heads and --locals revision specifiers

Jakub Narebski venit, vidit, dixit 01.05.2010 21:42:
Show 15 quoted lines
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> 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
> 
> Wouldn't new feature (introduced in 1.7.0) of --glob=<glob-pattern>
> be enough?
> 

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
Jakub Narebski· May 1, 2010, 19:51 UTC · re: Michael J Gruber · lore

Re: [RFD PATCH] revlist/rev-parse: Introduce --heads and --locals revision specifiers

Michael J Gruber wrote:
Show 22 quoted lines
> Jakub Narebski venit, vidit, dixit 01.05.2010 21:42:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>> 
>>> 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
>> 
>> Wouldn't new feature (introduced in 1.7.0) of --glob=<glob-pattern>
>> be enough?
>> 
> 
> 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 ;)
Ah, sorry, I have misunderstood the goal of your change.
Seems like a good idea.
-- 
Jakub Narebski
Poland
Jeff King· May 2, 2010, 05:00 UTC · re: Michael J Gruber · lore

Re: [RFD PATCH] revlist/rev-parse: Introduce --heads and --locals revision specifiers

On Sat, May 01, 2010 at 08:36:33PM +0200, Michael J Gruber wrote:
Show 9 quoted lines
> 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

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
Michael J Gruber· May 2, 2010, 13:43 UTC · re: Jeff King · lore

Re: [RFD PATCH] revlist/rev-parse: Introduce --heads and --locals revision specifiers

Jeff King venit, vidit, dixit 02.05.2010 07:00:
Show 15 quoted lines
> On Sat, May 01, 2010 at 08:36:33PM +0200, Michael J Gruber wrote:
> 
>> 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
> 
> 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
I second your Yikes... but won't suggest renaming refs/heads.
> does make some sense (it is all the local and remote heads), but I am
> worried that it will cause confusion.
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
Jeff King· May 5, 2010, 03:35 UTC · re: Michael J Gruber · lore

Re: [RFD PATCH] revlist/rev-parse: Introduce --heads and --locals revision specifiers

On Sun, May 02, 2010 at 03:43:05PM +0200, Michael J Gruber wrote:
Show 8 quoted lines
> > 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.
> 
> So, your alternative suggestion is...? ;)
I have to criticize _and_ suggest? Sheesh.
> How about --tips? But I don't like that.

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.

> We really use head as the term for the tip (ordered end-vertex) of a
> branch, be it local or remote.

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

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
Michael J Gruber· May 13, 2010, 14:24 UTC · re: Jeff King · lore

[PATCH 0/4] All is too much

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(-)
Jeff King· May 14, 2010, 06:06 UTC · re: Michael J Gruber · lore

Re: [PATCH 0/4] All is too much

On Thu, May 13, 2010 at 04:24:34PM +0200, Michael J Gruber wrote:
> This series introduces --lrbranches and --locals as abbreviations
> for "HEAD --branches --remotes" (local and remote branches) resp.
> "HEAD --branches --tags" (local refs).

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
Michael J Gruber· May 14, 2010, 16:08 UTC · re: Jeff King · lore

Re: [PATCH 0/4] All is too much

Jeff King venit, vidit, dixit 14.05.2010 08:06:
Show 12 quoted lines
> On Thu, May 13, 2010 at 04:24:34PM +0200, Michael J Gruber wrote:
> 
>> This series introduces --lrbranches and --locals as abbreviations
>> for "HEAD --branches --remotes" (local and remote branches) resp.
>> "HEAD --branches --tags" (local refs).
> 
> 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.

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
Akhbari, Farshad· May 14, 2010, 16:14 UTC · re: Michael J Gruber · lore

Git methodology question

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.

Chris Packham· May 14, 2010, 21:44 UTC · re: Akhbari, Farshad · lore

Re: Git methodology question

On Fri, May 14, 2010 at 9:14 AM, Akhbari, Farshad <farshad.akhbari@intel.com> wrote:

Show 22 quoted lines
>
> 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
Avery Pennarun· May 14, 2010, 21:54 UTC · re: Akhbari, Farshad · lore

Re: Git methodology question

On Fri, May 14, 2010 at 12:14 PM, Akhbari, Farshad <farshad.akhbari@intel.com> wrote:

Show 11 quoted lines
> 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?

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
Michael J Gruber· May 14, 2010, 18:26 UTC · re: Michael J Gruber · lore

[PATCH v2 0/4] All is too much

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(-)
Michael J Gruber· May 14, 2010, 18:26 UTC · re: Michael J Gruber · lore

[PATCH v2 1/4] rev-parse: deprecate use as an option sifter

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>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/git-rev-parse.txt |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)
Show changes to Documentation/git-rev-parse.txt +10 −4
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 8db600f..99d2a79 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -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
Michael J Gruber· May 14, 2010, 18:26 UTC · re: Michael J Gruber · lore

[PATCH v2 2/4] t6018: add tests for rev-list's --branches and --tags

so that we know when they break.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 t/t6018-rev-list-glob.sh |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)
Show changes to t/t6018-rev-list-glob.sh +13 −0
diff --git a/t/t6018-rev-list-glob.sh b/t/t6018-rev-list-glob.sh
index 8d3fa7d..dbedc4d 100755
--- a/t/t6018-rev-list-glob.sh
+++ b/t/t6018-rev-list-glob.sh
@@ -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
Michael J Gruber· May 14, 2010, 18:26 UTC · re: Michael J Gruber · lore

[PATCH v2 3/4] t6018: make sure all tested symbolic names are different revs

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 t/t6018-rev-list-glob.sh |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)
Show changes to t/t6018-rev-list-glob.sh +3 −1
diff --git a/t/t6018-rev-list-glob.sh b/t/t6018-rev-list-glob.sh
index dbedc4d..58428d9 100755
--- a/t/t6018-rev-list-glob.sh
+++ b/t/t6018-rev-list-glob.sh
@@ -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
Michael J Gruber· May 14, 2010, 18:26 UTC · re: Michael J Gruber · lore

[PATCH v2 4/4] revlist: Introduce --lrbranches 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 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

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 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(-)
Show changes to 5 files +40 −0

Documentation/git-rev-list.txt, Documentation/rev-list-options.txt, builtin/rev-list.c, revision.c, t/t6018-rev-list-glob.sh

diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 173f3fc..81d67da 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -25,6 +25,8 @@ SYNOPSIS
 	     [ \--tags[=pattern] ]
 	     [ \--remotes[=pattern] ]
 	     [ \--glob=glob-pattern ]
+	     [ \--locals ]
+	     [ \--lrbranches ]
 	     [ \--stdin ]
 	     [ \--quiet ]
 	     [ \--topo-order ]
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index b9fb7a8..21c0c93 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -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::
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 51ceb19..50664b7 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -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"
diff --git a/revision.c b/revision.c
index f4b8b38..5067fce 100644
--- a/revision.c
+++ b/revision.c
@@ -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);
diff --git a/t/t6018-rev-list-glob.sh b/t/t6018-rev-list-glob.sh
index 58428d9..fd77fe5 100755
--- a/t/t6018-rev-list-glob.sh
+++ b/t/t6018-rev-list-glob.sh
@@ -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
Michael J Gruber· May 13, 2010, 14:24 UTC · re: Jeff King · lore

[PATCH 1/4] rev-parse: deprecate use as an option sifter

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>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 Documentation/git-rev-parse.txt |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)
Show changes to Documentation/git-rev-parse.txt +10 −4
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 8db600f..99d2a79 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -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· May 14, 2010, 15:41 UTC · re: Michael J Gruber · lore

Re: [PATCH 1/4] rev-parse: deprecate use as an option sifter

Michael J Gruber <git@drmicha.warpmail.net> writes:
>  NAME
>  ----
> -git-rev-parse - Pick out and massage parameters
> +git-rev-parse - Parse symbolic names into object names
What about "git rev-parse --parseopt"?  Isn't it massaging parameters?
-- 
Jakub Narebski
Poland
ShadeHawk on #git
Michael J Gruber· May 14, 2010, 18:52 UTC · re: Jakub Narebski · lore

Re: [PATCH 1/4] rev-parse: deprecate use as an option sifter

Jakub Narebski venit, vidit, dixit 14.05.2010 17:41:
Show 9 quoted lines
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>>  NAME
>>  ----
>> -git-rev-parse - Pick out and massage parameters
>> +git-rev-parse - Parse symbolic names into object names
> 
> What about "git rev-parse --parseopt"?  Isn't it massaging parameters?
> 

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
Jakub Narebski· May 14, 2010, 19:01 UTC · re: Michael J Gruber · lore

Re: [PATCH 1/4] rev-parse: deprecate use as an option sifter

Dnia piątek 14. maja 2010 20:52, Michael J Gruber napisał:
Show 15 quoted lines
> Jakub Narebski venit, vidit, dixit 14.05.2010 17:41:
> > Michael J Gruber <git@drmicha.warpmail.net> writes:
> > 
> >>  NAME
> >>  ----
> >> -git-rev-parse - Pick out and massage parameters
> >> +git-rev-parse - Parse symbolic names into object names
> > 
> > What about "git rev-parse --parseopt"?  Isn't it massaging parameters?
> > 
> 
> 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.)

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

-- 
Jakub Narebski
Poland
Michael J Gruber· May 14, 2010, 19:22 UTC · re: Jakub Narebski · lore

Re: [PATCH 1/4] rev-parse: deprecate use as an option sifter

Jakub Narebski venit, vidit, dixit 14.05.2010 21:01:
Show 20 quoted lines
> Dnia piątek 14. maja 2010 20:52, Michael J Gruber napisał:
>> Jakub Narebski venit, vidit, dixit 14.05.2010 17:41:
>>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>>
>>>>  NAME
>>>>  ----
>>>> -git-rev-parse - Pick out and massage parameters
>>>> +git-rev-parse - Parse symbolic names into object names
>>>
>>> What about "git rev-parse --parseopt"?  Isn't it massaging parameters?
>>>
>>
>> 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.)
> 
> "git rev-parse --parseopt" is not deprecated.  What is deprecated is
> --revs-only, --flags, etc.
> 

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

Thomas Rast· May 17, 2010, 14:26 UTC · re: Jakub Narebski · lore

Re: [PATCH 1/4] rev-parse: deprecate use as an option sifter

Jakub Narebski wrote:
> 
> "git rev-parse --parseopt" is not deprecated.  What is deprecated is
> --revs-only, --flags, etc.

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
Michael J Gruber· May 13, 2010, 14:24 UTC · re: Jeff King · lore

[PATCH 2/4] t6018: add tests for rev-list's --branches and --tags

so that we know when they break.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 t/t6018-rev-list-glob.sh |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)
Show changes to t/t6018-rev-list-glob.sh +13 −0
diff --git a/t/t6018-rev-list-glob.sh b/t/t6018-rev-list-glob.sh
index 8d3fa7d..dbedc4d 100755
--- a/t/t6018-rev-list-glob.sh
+++ b/t/t6018-rev-list-glob.sh
@@ -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
Michael J Gruber· May 13, 2010, 14:24 UTC · re: Jeff King · lore

[PATCH 3/4] t6018: make sure all tested symbolic names are different revs

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 t/t6018-rev-list-glob.sh |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)
Show changes to t/t6018-rev-list-glob.sh +15 −1
diff --git a/t/t6018-rev-list-glob.sh b/t/t6018-rev-list-glob.sh
index dbedc4d..a1320aa 100755
--- a/t/t6018-rev-list-glob.sh
+++ b/t/t6018-rev-list-glob.sh
@@ -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
Michael J Gruber· May 13, 2010, 14:24 UTC · re: Jeff King · lore

[PATCH 4/4] revlist: Introduce --lrbranches 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 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

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 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(-)
Show changes to 5 files +32 −4

Documentation/git-rev-list.txt, Documentation/rev-list-options.txt, builtin/rev-list.c, revision.c, t/t6018-rev-list-glob.sh

diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 173f3fc..81d67da 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -25,6 +25,8 @@ SYNOPSIS
 	     [ \--tags[=pattern] ]
 	     [ \--remotes[=pattern] ]
 	     [ \--glob=glob-pattern ]
+	     [ \--locals ]
+	     [ \--lrbranches ]
 	     [ \--stdin ]
 	     [ \--quiet ]
 	     [ \--topo-order ]
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index b9fb7a8..21c0c93 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -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::
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 51ceb19..50664b7 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -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"
diff --git a/revision.c b/revision.c
index f4b8b38..5067fce 100644
--- a/revision.c
+++ b/revision.c
@@ -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);
diff --git a/t/t6018-rev-list-glob.sh b/t/t6018-rev-list-glob.sh
index a1320aa..fd77fe5 100755
--- a/t/t6018-rev-list-glob.sh
+++ b/t/t6018-rev-list-glob.sh
@@ -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

← back to recent threads