Re: [PATCH v2] Fix notes handling in rev-list

2012-07-19 Thread Jeff King 
On Wed, Jul 18, 2012 at 03:39:34PM -0700, Junio C Hamano wrote:

 Jeff King p...@peff.net writes:
 
  So leaving aside the --graph issues, we would need to decide what to
  show in the non-graph case. And I think your suggestion is good; there
  is no real need to dereference the blob (if you want that, you can turn
  on the pretty-printer).
 
  I'm just not sure what the output should be. I guess:
 
commit_sha1 notes sha1s
 
  is probably the most sensible (it's sort of like --parents). And that
  solves the --graph issue, too, since it continues to take only a single
  line.
 
 Surely.  rev-list --parents --notes would still be usable that
 way, as a reader that requests such a combination is prepared to
 tell commits (i.e. parents) and blobs (i.e. notes) apart.

I don't think we forbid non-blob values in notes trees, so technically
there could be some ambiguity. I doubt it is a big problem in practice
(especially since I haven't even heard of a good use case yet for git
rev-list --notes, let alone git rev-list --notes --parents). But now
would be the time to avoid a crappy format that we will be stuck with
later.

Unlike elements of the commit object itself, like --parents or
--timestamp, notes do not really gain any efficiency by being printed as
part of the traversal. So modulo the cost of piping the list of commits,
it would not really be any more efficient than git rev-list | git notes
list --stdin (except that the latter does not take a --stdin argument,
but could easily do so). And the latter is way more flexible.

So for plumbing, I think this is the wrong direction, anyway. The real
value of this patch is that the pretty-printed code path would work more
like git-log (especially the %N format, which lets callers make their
own micro-format for specifying all the bits they are interested in).

Maybe the best thing is to simply disallow --notes when not using a
pretty-printed format.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Fix notes handling in rev-list

2012-07-19 Thread Junio C Hamano 
Jeff King p...@peff.net writes:

 Unlike elements of the commit object itself, like --parents or
 --timestamp, notes do not really gain any efficiency by being printed as
 part of the traversal. So modulo the cost of piping the list of commits,
 it would not really be any more efficient than git rev-list | git notes
 list --stdin (except that the latter does not take a --stdin argument,
 but could easily do so). And the latter is way more flexible.

Yeah, I prefer that (not that I think we need either badly).

 So for plumbing, I think this is the wrong direction, anyway. The real
 value of this patch is that the pretty-printed code path would work more
 like git-log (especially the %N format, which lets callers make their
 own micro-format for specifying all the bits they are interested in).

Yeah, but at that point the obvious question becomes why you aren't
using 'git log' in the first place.

 Maybe the best thing is to simply disallow --notes when not using a
 pretty-printed format.

Yeah, or simply ignore it.


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Fix notes handling in rev-list

2012-07-19 Thread Jeff King 
On Thu, Jul 19, 2012 at 10:20:18AM -0700, Junio C Hamano wrote:

  So for plumbing, I think this is the wrong direction, anyway. The real
  value of this patch is that the pretty-printed code path would work more
  like git-log (especially the %N format, which lets callers make their
  own micro-format for specifying all the bits they are interested in).
 
 Yeah, but at that point the obvious question becomes why you aren't
 using 'git log' in the first place.

I dunno. I guess there are other plumbing-like behaviors of rev-list
that you would want, but the only ones I can think of are diff options,
which rev-list does not handle at all.

  Maybe the best thing is to simply disallow --notes when not using a
  pretty-printed format.
 
 Yeah, or simply ignore it.

I'd rather generate an error to make it more obvious what is happening
(and it is not that we are somehow failing to find any notes). And it
might help prevent the later question of: why does git rev-list
--oneline --notes show notes, but git rev-list --notes silently
ignores it? 

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Fix notes handling in rev-list

2012-07-18 Thread Jeff King 
On Mon, Jul 16, 2012 at 10:42:07PM -0700, Junio C Hamano wrote:

  Just like log, the notes are part of the commit information to the right
  of the graph. But this second hunk is for when we are not using the
  pretty-printer at all, and the output looks like this:
 
$ git rev-list --graph --notes -2 HEAD
* f6bbb09529a4cc73446c7c115ac1468477bd0cc6
 
Notes:
foobar
* 31c79549b85c6393be4f40432f5b86ebc097fc7e
 
  which doesn't make sense
 
 I actually have quite a different feeling about this.  As I said in
 the separate message, I think --graph, or anything that makes the
 output unparsable or harder to parse for machines for that matter,
 in rev-list are not something we have because we wanted to support
 them, but that which just happen to work because the large part of
 rev-list and log can share building blocks to do similar things.
 The key phrase is can share here; it does not necessarily mean
 they should [*1*].

Somebody went to the trouble to make rev-list --graph work[1] (that is
what the call to graph_show_remainder in the else clause of the
conditional is about). I agree it seems kind of useless, but it does
work now, and we should at least not make it worse (and I think we both
agree that the output above is just wrong).

So whatever we show for a note, it should look like:

  * f6bbb095...
  | the notes thing to show
  * 31c79549...

Because that is how graph output is formatted. Either that, or we should
disallow --graph entirely with rev-list (which I'd also be OK with).

 I do not mind having an option to show the notes text, but I doubt
 it is a sane thing to do to make rev-list --notes unconditionally
 show the payload of the notes blob.  rev-list --objects only shows
 the object names of trees and blobs, not the payload in these
 objects, and this is very much on purpuse.  It allows the downstream
 process that reads its output from the pipe to easily parse the
 output and choose to do whatever it wants to do using them.
 
 I wonder if we should show the blob object names that store the
 notes payload if we were given --notes option in a format that is
 easy for readers to mechanically parse its output.

So leaving aside the --graph issues, we would need to decide what to
show in the non-graph case. And I think your suggestion is good; there
is no real need to dereference the blob (if you want that, you can turn
on the pretty-printer).

I'm just not sure what the output should be. I guess:

  commit_sha1 notes sha1s

is probably the most sensible (it's sort of like --parents). And that
solves the --graph issue, too, since it continues to take only a single
line.

-Peff

[1] Looking at the code, I do think somebody wanted rev-list --graph
to work, and it is not an accident. But I think they did not do a very
thorough job, as things like git rev-list --objects --graph produce
nonsensical output.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Fix notes handling in rev-list

2012-07-18 Thread Junio C Hamano 
Jeff King p...@peff.net writes:

 So leaving aside the --graph issues, we would need to decide what to
 show in the non-graph case. And I think your suggestion is good; there
 is no real need to dereference the blob (if you want that, you can turn
 on the pretty-printer).

 I'm just not sure what the output should be. I guess:

   commit_sha1 notes sha1s

 is probably the most sensible (it's sort of like --parents). And that
 solves the --graph issue, too, since it continues to take only a single
 line.

Surely.  rev-list --parents --notes would still be usable that
way, as a reader that requests such a combination is prepared to
tell commits (i.e. parents) and blobs (i.e. notes) apart.

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] Fix notes handling in rev-list

2012-07-16 Thread Jukka Lehtniemi 
Display notes in the rev-list when switch '--notes' is used.
Also expand notes place holder (%N) in user format.
Previously rev-list ignored both of these.

Signed-off-by: Jukka Lehtniemi jukka.lehtni...@gmail.com
---

Thanks for your feedback Peff!

 builtin/rev-list.c |   16 +++-
 t/t6006-rev-list-format.sh |   22 +-
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index ff5a383..ad8abcb 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -7,6 +7,7 @@
 #include log-tree.h
 #include graph.h
 #include bisect.h
+#include notes.h
 
 static const char rev_list_usage[] =
 git rev-list [OPTION] commit-id... [ -- paths... ]\n
@@ -111,6 +112,7 @@ static void show_commit(struct commit *commit, void *data)
ctx.date_mode = revs-date_mode;
ctx.date_mode_explicit = revs-date_mode_explicit;
ctx.fmt = revs-commit_format;
+   ctx.show_notes = revs-show_notes;
pretty_print_commit(ctx, commit, buf);
if (revs-graph) {
if (buf.len) {
@@ -159,6 +161,12 @@ static void show_commit(struct commit *commit, void *data)
} else {
if (graph_show_remainder(revs-graph))
putchar('\n');
+   if (revs-show_notes_given) {
+   struct strbuf buf = STRBUF_INIT;
+   format_display_notes(commit-object.sha1, buf, 0, 
NOTES_SHOW_HEADER|NOTES_INDENT); 
+   fwrite(buf.buf, 1, buf.len, stdout);
+   strbuf_release(buf);
+   }
}
maybe_flush_or_die(stdout, stdout);
finish_commit(commit, data);
@@ -309,6 +317,7 @@ int cmd_rev_list(int argc, const char **argv, const char 
*prefix)
 {
struct rev_info revs;
struct rev_list_info info;
+   struct userformat_want userformat_want = {0};
int i;
int bisect_list = 0;
int bisect_show_vars = 0;
@@ -322,9 +331,14 @@ int cmd_rev_list(int argc, const char **argv, const char 
*prefix)
 
memset(info, 0, sizeof(info));
info.revs = revs;
+
+   userformat_find_requirements(NULL, userformat_want);
+   if (userformat_want.notes)
+   revs.show_notes = 1;
if (revs.bisect)
bisect_list = 1;
-
+   if (revs.show_notes)
+   init_display_notes(revs.notes_opt);
if (DIFF_OPT_TST(revs.diffopt, QUICK))
info.flags |= REV_LIST_QUIET;
for (i = 1 ; i  argc; i++) {
diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
index f94f0c4..ab616a0 100755
--- a/t/t6006-rev-list-format.sh
+++ b/t/t6006-rev-list-format.sh
@@ -7,7 +7,8 @@ test_description='git rev-list --pretty=format test'
 test_tick
 test_expect_success 'setup' '
 touch foo  git add foo  git commit -m added foo 
-  echo changed foo  git commit -a -m changed foo
+  echo changed foo  git commit -a -m changed foo 
+  git notes add -m note foo
 '
 
 # usage: test_format name format_string expected_output
@@ -19,6 +20,25 @@ test_cmp expect.$1 output.$1
 
 }
 
+test_expect_success 'notes switch' 
+cat expect.notes_switch 'EOF'
+131a310eb913d107dd3c09a65d1651175898735d
+
+Notes:
+note foo
+86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+EOF
+git rev-list --notes master output.notes_switch 
+test_cmp expect.notes_switch output.notes_switch
+
+
+test_format notes %N 'EOF'
+commit 131a310eb913d107dd3c09a65d1651175898735d
+note foo
+
+commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
+EOF
+
 test_format percent %%h 'EOF'
 commit 131a310eb913d107dd3c09a65d1651175898735d
 %h
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Fix notes handling in rev-list

2012-07-16 Thread Jeff King 
On Mon, Jul 16, 2012 at 12:03:40PM -0700, Junio C Hamano wrote:

 Jukka Lehtniemi jukka.lehtni...@gmail.com writes:
 
  Display notes in the rev-list when switch '--notes' is used.
  Also expand notes place holder (%N) in user format.
  Previously rev-list ignored both of these.
 
  Signed-off-by: Jukka Lehtniemi jukka.lehtni...@gmail.com
  ---
 
  Thanks for your feedback Peff!
 
 If it is an update for some old patch (I am guessing that is the
 case from v2 and feedback above), please hint where the
 original can be found not to waste reviewers' time.

Agreed. For reference, v1 is here:

  http://thread.gmane.org/gmane.comp.version-control.git/193842

 As git rev-list -h does not say anything about notes, I do not
 think this should be even called Fix; rather it is teach rev-list
 to show notes with --notes, a new feature.

It does not, but git rev-list --help does (and it mentions %N for
the pretty userformat). So it's debatable whether it is a code bug or a
documentation bug. But whatever we call it, I think it is an
improvement.

 And as a new feature, git rev-list -h should be taught to include
 this new option in its output.  I didn't check the documentation but
 you may also want to add --notes there, too (hint: grep for --pretty
 to find where you may need to add the new option).

rev-list -h is already an unwieldy 35 lines, yet still manages to miss
many options (e.g., --grep, --author, --cherry-*, variations of
--left-right, --boundary, history simplification options like
--full-history, and so on). I don't think one more option is going to
break the camel's back, but I wonder if rev-list -h could use some
cleanup. E.g., maybe drop seldom used stuff like --bisect-vars, format
similar options on a single line to save space, and add in some missing
options.

My preference would actually be to just give up and refer people to the
manpage after a one or two line usage. But I think we have had that
discussion before and you did not agree.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Fix notes handling in rev-list

2012-07-16 Thread Junio C Hamano 
Jeff King p...@peff.net writes:

 ... But whatever we call it, I think it is an
 improvement.

I didn't say it makes things worse in any way, did I?

I was reacting on the Subject: line because that will what I later
have to work from when reading shortlog, summarizing changes, etc.

 ... I don't think one more option is going to
 break the camel's back, but I wonder if rev-list -h could use some
 cleanup. E.g., maybe drop seldom used stuff like --bisect-vars, format
 similar options on a single line to save space, and add in some missing
 options.

Sounds good.  The manpage also needs some cleaning up, I would
think, to omit things that may happen to work (primarily because a
lot of code is shared with log) but do not have to, for example.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Fix notes handling in rev-list

2012-07-16 Thread Jeff King 
On Mon, Jul 16, 2012 at 09:30:09PM +0300, Jukka Lehtniemi wrote:

 @@ -111,6 +112,7 @@ static void show_commit(struct commit *commit, void *data)
   ctx.date_mode = revs-date_mode;
   ctx.date_mode_explicit = revs-date_mode_explicit;
   ctx.fmt = revs-commit_format;
 + ctx.show_notes = revs-show_notes;
   pretty_print_commit(ctx, commit, buf);
   if (revs-graph) {
   if (buf.len) {

Makes sense. We were just failing to propagate the show_notes flag to
the pretty-print code, as log-tree does.

 @@ -159,6 +161,12 @@ static void show_commit(struct commit *commit, void 
 *data)
   } else {
   if (graph_show_remainder(revs-graph))
   putchar('\n');
 + if (revs-show_notes_given) {
 + struct strbuf buf = STRBUF_INIT;
 + format_display_notes(commit-object.sha1, buf, 0, 
 NOTES_SHOW_HEADER|NOTES_INDENT); 
 + fwrite(buf.buf, 1, buf.len, stdout);
 + strbuf_release(buf);
 + }

But why are we using show_notes_given here instead of show_notes? The
former is about did we get any kind of --notes option on the
command-line. So doing git rev-list --no-notes would trigger it,
which seems wrong. We should simply be checking show_notes again, no?

Also, it seems odd to me to show the notes after graph_show_remainder.
Your first hunk is about passing the notes option to the pretty-printer,
which handles graph output already, and looks like this:

  $ git rev-list --oneline --graph --notes -2 HEAD
  * f6bbb09 Fix notes handling in rev-list
  | Notes:
  | foobar
  | 
  * 31c7954 Update draft release notes for 7th batch

Just like log, the notes are part of the commit information to the right
of the graph. But this second hunk is for when we are not using the
pretty-printer at all, and the output looks like this:

  $ git rev-list --graph --notes -2 HEAD
  * f6bbb09529a4cc73446c7c115ac1468477bd0cc6

  Notes:
  foobar
  * 31c79549b85c6393be4f40432f5b86ebc097fc7e

which doesn't make sense; we've broken the graph with our notes output.
I think you would need to feed the output to the graph code. Something
like:

diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index ff5a383..dbe7349 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -157,6 +159,13 @@ static void show_commit(struct commit *commit, void *data)
}
strbuf_release(buf);
} else {
+   if (revs-show_notes) {
+   struct strbuf buf = STRBUF_INIT;
+   format_display_notes(commit-object.sha1, buf, 0,
+NOTES_SHOW_HEADER|NOTES_INDENT);
+   graph_show_commit_msg(revs-graph, buf);
+   strbuf_release(buf);
+   }
if (graph_show_remainder(revs-graph))
putchar('\n');
}

Except that it seems to introduce an extra newline before the notes, and
it is probably an abuse of graph_show_commit_msg (there is a
graph_show_strbuf which graph_show_commit_msg is built around, and it
could perhaps be made public). I'd look at how log-tree handles it for
inspiration.

 diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh
 index f94f0c4..ab616a0 100755
 --- a/t/t6006-rev-list-format.sh
 +++ b/t/t6006-rev-list-format.sh
 [...]
 @@ -19,6 +20,25 @@ test_cmp expect.$1 output.$1
  
  }
  
 +test_expect_success 'notes switch' 
 +cat expect.notes_switch 'EOF'
 +131a310eb913d107dd3c09a65d1651175898735d
 +
 +Notes:
 +note foo
 +86c75cfd708a0e5868dc876ed5b8bb66c80b4873
 +EOF
 +git rev-list --notes master output.notes_switch 
 +test_cmp expect.notes_switch output.notes_switch
 +
 +
 +test_format notes %N 'EOF'
 +commit 131a310eb913d107dd3c09a65d1651175898735d
 +note foo
 +
 +commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
 +EOF
 +

Nice. Of the four behaviors I mentioned in my previous review:

  1. --notes shows notes

  2. --no-notes does not show notes

  3. when no options are given, notes are not displayed

  4. --format=%N shows notes

this tests 2 of them (1 and 4). I don't know if it is worth testing (2),
as it should not do anything (though it actually is broken with your
patch). It is definitely worth making sure (3) works, but it is
implicitly checked by the other tests in the script (which would break
if we started showing notes). Still, it might be worth adding an
explicit rev-list does not show notes by default to make sure it is
clearly documented with a test.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Fix notes handling in rev-list

2012-07-16 Thread Jeff King 
On Mon, Jul 16, 2012 at 08:40:24PM -0700, Junio C Hamano wrote:

 Jeff King p...@peff.net writes:
 
  ... But whatever we call it, I think it is an
  improvement.
 
 I didn't say it makes things worse in any way, did I?

No, you did not. That was my attempt to end the paragraph on a positive
and constructive note. What I meant was I think you are wrong and it is
a bugfix, but I do not care overly what we call it as long as we do it.
:)

Do note that my as long as we do it is about the direction, not the
patch. There are a few issues with the patch itself, and I just posted a
review.

 I was reacting on the Subject: line because that will what I later
 have to work from when reading shortlog, summarizing changes, etc.

That is a fair point. From the release notes perspective, it probably is
a feature (there is a documentation bug, but it happens to be fixed at
the same time).

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] Fix notes handling in rev-list

2012-07-16 Thread Junio C Hamano 
Jeff King p...@peff.net writes:

 On Mon, Jul 16, 2012 at 09:30:09PM +0300, Jukka Lehtniemi wrote:

 @@ -111,6 +112,7 @@ static void show_commit(struct commit *commit, void 
 *data)
  ctx.date_mode = revs-date_mode;
  ctx.date_mode_explicit = revs-date_mode_explicit;
  ctx.fmt = revs-commit_format;
 +ctx.show_notes = revs-show_notes;
  pretty_print_commit(ctx, commit, buf);
  if (revs-graph) {
  if (buf.len) {

 Makes sense. We were just failing to propagate the show_notes flag to
 the pretty-print code, as log-tree does.

 @@ -159,6 +161,12 @@ static void show_commit(struct commit *commit, void 
 *data)
  } else {
  if (graph_show_remainder(revs-graph))
  putchar('\n');
 +if (revs-show_notes_given) {
 +struct strbuf buf = STRBUF_INIT;
 +format_display_notes(commit-object.sha1, buf, 0, 
 NOTES_SHOW_HEADER|NOTES_INDENT); 
 +fwrite(buf.buf, 1, buf.len, stdout);
 +strbuf_release(buf);
 +}

 But why are we using show_notes_given here instead of show_notes? The
 former is about did we get any kind of --notes option on the
 command-line. So doing git rev-list --no-notes would trigger it,
 which seems wrong. We should simply be checking show_notes again, no?

 Also, it seems odd to me to show the notes after graph_show_remainder.
 Your first hunk is about passing the notes option to the pretty-printer,
 which handles graph output already, and looks like this:

   $ git rev-list --oneline --graph --notes -2 HEAD
   * f6bbb09 Fix notes handling in rev-list
   | Notes:
   | foobar
   | 
   * 31c7954 Update draft release notes for 7th batch

 Just like log, the notes are part of the commit information to the right
 of the graph. But this second hunk is for when we are not using the
 pretty-printer at all, and the output looks like this:

   $ git rev-list --graph --notes -2 HEAD
   * f6bbb09529a4cc73446c7c115ac1468477bd0cc6

   Notes:
   foobar
   * 31c79549b85c6393be4f40432f5b86ebc097fc7e

 which doesn't make sense

I actually have quite a different feeling about this.  As I said in
the separate message, I think --graph, or anything that makes the
output unparsable or harder to parse for machines for that matter,
in rev-list are not something we have because we wanted to support
them, but that which just happen to work because the large part of
rev-list and log can share building blocks to do similar things.
The key phrase is can share here; it does not necessarily mean
they should [*1*].

First and foremost, rev-list is a tool for people who hate what our
vanilla git log Porcelain does enough that they want to write
their own Porcelain scripts using it.

I do not mind having an option to show the notes text, but I doubt
it is a sane thing to do to make rev-list --notes unconditionally
show the payload of the notes blob.  rev-list --objects only shows
the object names of trees and blobs, not the payload in these
objects, and this is very much on purpuse.  It allows the downstream
process that reads its output from the pipe to easily parse the
output and choose to do whatever it wants to do using them.

I wonder if we should show the blob object names that store the
notes payload if we were given --notes option in a format that is
easy for readers to mechanically parse its output.

In any case, the use of format_display_notes() that is meant for
human consumption feels very wrong to me, especially it seems to be
placed outside the if (revs-verbose_header  commit-buffer)
block in this patch.  I do not have any problem if the patch makes
the notes text shown in the other side of the if block that uses
pretty_print_commit(), though.


[Footnote]

*1* A simple litmus test is to ask this question: if somebody comes
up with a better way to show the same output for the option,
would we accept that update without worrying about breaking
existing scripts?  If the answer is yes, that is a secondary
feature in the context of rev-list plumbing like --graph is.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html