git rev-list formatting

Possible bug -- IIUC, this:

  git rev-list --pretty="%w(40,2,2)%b" $rev

should show all bodies wrapped as specified, but with 1.7.0.3 I see
only the first one wrapped, and the rest don't show up.  In one of my
attempts to sort this, I saw all bodies, but all bodies after the
first were not wrapped as specified.

Also, is there a way to avoid the "commit <sha1>" line, print some
information that I specify in the format string, and show the whole
message as is (without wrapping or other tweaks)?

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Eli Barzilay [off-list ref] writes:

[...]

Also, is there a way to avoid the "commit <sha1>" line, print some
information that I specify in the format string, and show the whole
message as is (without wrapping or other tweaks)?

Looks like `git log' does something similar to what I want anyway,
which leads me to a related question -- it's not clear to me what are
the differences between `git rev-list', `git log', `git diff', and
`git show', since it looks like they can all be tweaked to produce
similar outputs.  Are they all the same with different outputs?  Is
there some description of them with the differences explained?

Also related, it looks like `--abbrev-commit' has no effect on `git
rev-list', but does on `git log', even through it's documented in the
former's man page.  So it looks like either there are more
(undocumented?) differences, or maybe that's also a bug?

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Eli Barzilay venit, vidit, dixit 22.03.2010 12:39:

Eli Barzilay [off-list ref] writes:

quoted

[...]

Also, is there a way to avoid the "commit <sha1>" line, print some
information that I specify in the format string, and show the whole
message as is (without wrapping or other tweaks)?

Looks like `git log' does something similar to what I want anyway,
which leads me to a related question -- it's not clear to me what are
the differences between `git rev-list', `git log', `git diff', and
`git show', since it looks like they can all be tweaked to produce
similar outputs.  Are they all the same with different outputs?  Is
there some description of them with the differences explained?

The rev-list man page lists all commands of that family, with rev-list
being the bare bones version, and log and friends being more "high
level". log and rev-list walk the revision tree, show does not. Most of
that can be changed through options. whatchanged is a special family
member...

diff is from a completely different family (see git help diff or git
help diffcore). It never walks, but compares revisions (or other things).

The log family never compares things, but can show a patch, i.e. the
difference to the ancestor(s).

Also related, it looks like `--abbrev-commit' has no effect on `git
rev-list', but does on `git log', even through it's documented in the
former's man page.  So it looks like either there are more
(undocumented?) differences, or maybe that's also a bug?

I consider this a bug. In fact, it has an effect, but not a visible one.
You would have to use --abbrev=7 or such.

A patch is upcoming.

Cheers,
Michael

Currently, rev-list has a default of "0" for abbrev which means that
switching on abbreviations with --abbrev-commit has no visible effect,
even though the option is documented.

Set abbrev to DEFAULT_ABBREV so that --abbrev-commit has the same effect
as for log.

Signed-off-by: Michael J Gruber <redacted>
Reported-by: Eli Barzilay <redacted>
---
I'm actually wondering why log and rev-list don't share the relevant
part of that code.

 builtin/rev-list.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 5679170..eb8e2c2 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c

@@ -313,7 +313,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
 
 	git_config(git_default_config, NULL);
 	init_revisions(&revs, prefix);
-	revs.abbrev = 0;
+	revs.abbrev = DEFAULT_ABBREV;
 	revs.commit_format = CMIT_FMT_UNSPECIFIED;
 	argc = setup_revisions(argc, argv, &revs, NULL);
 

-- 
1.7.0.3.435.g097f4

Michael J Gruber [off-list ref] writes:

The rev-list man page lists all commands of that family, with
rev-list being the bare bones version, and log and friends being
more "high level". log and rev-list walk the revision tree, show
does not. Most of that can be changed through options. whatchanged
is a special family member...

diff is from a completely different family (see git help diff or git
help diffcore). It never walks, but compares revisions (or other things).

The log family never compares things, but can show a patch, i.e. the
difference to the ancestor(s).

(That's why I put `git diff' into the mix...)

Anyway -- thanks for the overview.  So IIUC, `rev-list' and `log' are
different in that the second can also format diffs -- ?

quoted

Also related, it looks like `--abbrev-commit' has no effect on `git
rev-list', but does on `git log', even through it's documented in the
former's man page.  So it looks like either there are more
(undocumented?) differences, or maybe that's also a bug?

I consider this a bug. In fact, it has an effect, but not a visible one.
You would have to use --abbrev=7 or such.

A patch is upcoming.

Thanks.

And one more question -- is there some %-escape that shows the whole
contents?  Something like "%(contents)" in `for-each-ref'?  (Which has
a different set of escapes...)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Am 22.03.2010 12:30, schrieb Eli Barzilay:

Possible bug -- IIUC, this:

  git rev-list --pretty="%w(40,2,2)%b" $rev

should show all bodies wrapped as specified, but with 1.7.0.3 I see
only the first one wrapped, and the rest don't show up.  In one of my
attempts to sort this, I saw all bodies, but all bodies after the
first were not wrapped as specified.

I can't reproduce this when running this command against git's own repo.
 Or perhaps I just fail to see it.  Is the one you're trying this on
public?  Does it work as expected with some other version of git?

Thanks,
René

René Scharfe [off-list ref] writes:

Am 22.03.2010 12:30, schrieb Eli Barzilay:

quoted

Possible bug -- IIUC, this:

  git rev-list --pretty="%w(40,2,2)%b" $rev

should show all bodies wrapped as specified, but with 1.7.0.3 I see
only the first one wrapped, and the rest don't show up.  In one of my
attempts to sort this, I saw all bodies, but all bodies after the
first were not wrapped as specified.

I can't reproduce this when running this command against git's own
repo.  Or perhaps I just fail to see it.  Is the one you're trying
this on public?  Does it work as expected with some other version of
git?

Sorry, I've lost track of all the different things I tried, but here's
something that I can reproduce reliably now, which seems to be a
similar problem (or at least nothing in the man page explain why it
would do what it does).  If this is helpful, I'll tar up the
repository and put it up somewhere.  This is all running in the repo
-- and it case it matters, it's a bare repo, created with 1.7.0.

  $ git rev-list --pretty="%b" foo

shows one "commit <sha1>" line, then the body, and then the rest of
the commits (13 of them) with no body at all (just the "commit <sha1>"
lines).

  $ git rev-list --pretty="%b" 267d60518

Same output -- 267d60518 is the commit that `foo' points to.

  $ git rev-list --pretty="%b" 84482

This is for a commit that is somewhere in the middle of these commits,
the output has *only* "commit <sha1>" lines -- no body shown.

  $ git rev-list --pretty 84482

This one works fine, showing all of the commits and their log
messages.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Eli Barzilay venit, vidit, dixit 23.03.2010 02:57:

René Scharfe [off-list ref] writes:

quoted

Am 22.03.2010 12:30, schrieb Eli Barzilay:

quoted

Possible bug -- IIUC, this:

  git rev-list --pretty="%w(40,2,2)%b" $rev

should show all bodies wrapped as specified, but with 1.7.0.3 I see
only the first one wrapped, and the rest don't show up.  In one of my
attempts to sort this, I saw all bodies, but all bodies after the
first were not wrapped as specified.

I can't reproduce this when running this command against git's own
repo.  Or perhaps I just fail to see it.  Is the one you're trying
this on public?  Does it work as expected with some other version of
git?

Sorry, I've lost track of all the different things I tried, but here's
something that I can reproduce reliably now, which seems to be a
similar problem (or at least nothing in the man page explain why it
would do what it does).  If this is helpful, I'll tar up the
repository and put it up somewhere.  This is all running in the repo
-- and it case it matters, it's a bare repo, created with 1.7.0.

I'd say that certainly matters (can't reproduce this one on non-bare
either).

When you say "in the repo", do you mean that you're current directory is
within yourbarerepo.git? Do you have GIT_DIR set explicitly?

  $ git rev-list --pretty="%b" foo

shows one "commit <sha1>" line, then the body, and then the rest of
the commits (13 of them) with no body at all (just the "commit <sha1>"
lines).

[snip]

Michael

Michael J Gruber [off-list ref] writes:

Eli Barzilay venit, vidit, dixit 23.03.2010 02:57:

quoted

René Scharfe [off-list ref] writes:

quoted

Am 22.03.2010 12:30, schrieb Eli Barzilay:

quoted

Possible bug -- IIUC, this:

  git rev-list --pretty="%w(40,2,2)%b" $rev

should show all bodies wrapped as specified, but with 1.7.0.3 I see
only the first one wrapped, and the rest don't show up.  In one of my
attempts to sort this, I saw all bodies, but all bodies after the
first were not wrapped as specified.

I can't reproduce this when running this command against git's own
repo.  Or perhaps I just fail to see it.  Is the one you're trying
this on public?  Does it work as expected with some other version of
git?

Sorry, I've lost track of all the different things I tried, but here's
something that I can reproduce reliably now, which seems to be a
similar problem (or at least nothing in the man page explain why it
would do what it does).  If this is helpful, I'll tar up the
repository and put it up somewhere.  This is all running in the repo
-- and it case it matters, it's a bare repo, created with 1.7.0.

I'd say that certainly matters (can't reproduce this one on non-bare
either).

When you say "in the repo", do you mean that you're current
directory is within yourbarerepo.git?

Yes.

Do you have GIT_DIR set explicitly?

No.

[...]

I've made a copy of the repository at

  http://tmp.barzilay.org/testing.git.tgz

which shows what I said when I run

  git rev-list --pretty="%b" 267d60518
  git rev-list --pretty="%b" 84482

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

On Tue, Mar 23, 2010 at 07:06:38AM -0400, Eli Barzilay wrote:

quoted

[...]

I've made a copy of the repository at

  http://tmp.barzilay.org/testing.git.tgz

which shows what I said when I run

  git rev-list --pretty="%b" 267d60518
  git rev-list --pretty="%b" 84482

The problem is that most of those commits don't _have_ bodies. Remember
that "%b" is about everything in the commit message after the first
first paragraph.

Now one might argue that rev-list should still put in the extra newline
separator in this case. I haven't been paying attention, but hasn't that
been discussed in another thread recently?

-Peff

On Tue, Mar 23, 2010 at 1:26 PM, Jeff King [off-list ref] wrote:

On Tue, Mar 23, 2010 at 07:06:38AM -0400, Eli Barzilay wrote:

quoted

quoted

[...]

I've made a copy of the repository at

  http://tmp.barzilay.org/testing.git.tgz

which shows what I said when I run

  git rev-list --pretty="%b" 267d60518
  git rev-list --pretty="%b" 84482

The problem is that most of those commits don't _have_ bodies. Remember
that "%b" is about everything in the commit message after the first
first paragraph.

Now one might argue that rev-list should still put in the extra newline
separator in this case. I haven't been paying attention, but hasn't that
been discussed in another thread recently?

If you're thinking of the stuff I've been working on, that's about
multiple commits ending up at the same line with --pretty=oneline, and
not _really_ about unconditionally adding that new-line. But it is
closely related, and it looks like it's the same code that is
responsible for the current behavior. Commit 55246aa is what made then
new-line conditional in the first place.

-- 
Erik "kusma" Faye-Lund

Jeff King [off-list ref] writes:

On Tue, Mar 23, 2010 at 07:06:38AM -0400, Eli Barzilay wrote:

quoted

quoted

[...]

I've made a copy of the repository at

  http://tmp.barzilay.org/testing.git.tgz

which shows what I said when I run

  git rev-list --pretty="%b" 267d60518
  git rev-list --pretty="%b" 84482

The problem is that most of those commits don't _have_ bodies.
Remember that "%b" is about everything in the commit message after
the first first paragraph.

*Ugh*...  Yes, I've seen that a lot, yet somehow I managed to
completely miss it.  Sorry about the noise.

Now one might argue that rev-list should still put in the extra
newline separator in this case. I haven't been paying attention, but
hasn't that been discussed in another thread recently?

(That might have made it more confusing, but I should still have
guessed what's wrong...)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Michael J Gruber [off-list ref] writes:

Currently, rev-list has a default of "0" for abbrev which means that
switching on abbreviations with --abbrev-commit has no visible effect,
even though the option is documented.

Hmm, I actually think this was deliberate.  rev-list is designed to be a
low level machinery for getting full object names, and in that context,
setting the default abbreviation length to "don't abbreviate" gave us some
safety, with additional safety of requiring a separate --abbrev-commit
option to affect the main "show the commit object names" codepath (the
latter of which would not likely to change).  The caller sets explicitly
how long an output it wants (see git-rebase--interactive for an example).

Having said that, I don't think this would break existing scripts, so
let's queue it and see what happens.

Junio C Hamano venit, vidit, dixit 26.03.2010 20:32:

Michael J Gruber [off-list ref] writes:

quoted

Currently, rev-list has a default of "0" for abbrev which means that
switching on abbreviations with --abbrev-commit has no visible effect,
even though the option is documented.

Hmm, I actually think this was deliberate.  rev-list is designed to be a
low level machinery for getting full object names, and in that context,
setting the default abbreviation length to "don't abbreviate" gave us some
safety, with additional safety of requiring a separate --abbrev-commit
option to affect the main "show the commit object names" codepath (the
latter of which would not likely to change).  The caller sets explicitly
how long an output it wants (see git-rebase--interactive for an example).

My thinking was that unless --abbrev-commit is specified, nothing is
abbreviated, so that one has reproducible (plumbing) behaviour.

I learned that --abbrev= implies --abbrev-commit, but again, this means
explicitly requiring non-plumbing behavior.

Having said that, I don't think this would break existing scripts, so
let's queue it and see what happens.

OK!
Michael