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

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

[Michael J Gruber]

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

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

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

[Jakub Narebski]

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?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Michael J Gruber]

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

Michael

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

[Jakub Narebski]

Michael J Gruber wrote:
> 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

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

[Jeff King]

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
does make some sense (it is all the local and remote heads), but I am
worried that it will cause confusion.

-Peff

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

[Michael J Gruber]

Jeff King venit, vidit, dixit 02.05.2010 07:00:
> 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

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

[Jeff King]

On Sun, May 02, 2010 at 03:43:05PM +0200, Michael J Gruber wrote:

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

[PATCH 0/4] All is too much

[Michael J Gruber]

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

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

[Michael J Gruber]

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

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

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

[Michael J Gruber]

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

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

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

[Michael J Gruber]

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 t/t6018-rev-list-glob.sh |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

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

[PATCH 4/4] revlist: Introduce --lrbranches and --locals revision specifiers

[Michael J Gruber]

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

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

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

[Jeff King]

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

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

[Jakub Narebski]

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

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

[Michael J Gruber]

Jeff King venit, vidit, dixit 14.05.2010 08:06:
> 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

Git methodology question

[Akhbari, Farshad]

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.

[PATCH v2 0/4] All is too much

[Michael J Gruber]

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

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

[Michael J Gruber]

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

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

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

[Michael J Gruber]

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

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

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

[Michael J Gruber]

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
 t/t6018-rev-list-glob.sh |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

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

[PATCH v2 4/4] revlist: Introduce --lrbranches and --locals revision specifiers

[Michael J Gruber]

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

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

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

[Michael J Gruber]

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

Michael

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

[Jakub Narebski]

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.

-- 
Jakub Narebski
Poland

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

[Michael J Gruber]

Jakub Narebski venit, vidit, dixit 14.05.2010 21:01:
> 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

Re: Git methodology question

[Chris Packham]

On Fri, May 14, 2010 at 9:14 AM, Akhbari, Farshad
<farshad.akhbari@intel.com> wrote:
>
> 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

Re: Git methodology question

[Avery Pennarun]

On Fri, May 14, 2010 at 12:14 PM, Akhbari, Farshad
<farshad.akhbari@intel.com> wrote:
> 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

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

[Thomas Rast]

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