logging disjoint sets of commits in a single command

I'm trying to use "git log" to display only a handful of commits, where
the commits are not necessarily linearly related to each other.

On 2012-01-31 16:15 , "Bryan O'Sullivan" [off-list ref] wrote:

I'm trying to use "git log" to display only a handful of commits, where
the commits are not necessarily linearly related to each other.

And I beautifully fat-fingered the "send" key. Oops.

What I was *going* to say was that it looks like revision.c:limit_list is
(whether intentionally or not) getting in the way of this.

Here's a sample command line against a kernel tree:

git log 373af0c^..373af0c 590dfe2^..590dfe2

I want git to log those two specific commits, but in fact it looks like
limit_list is marking 590dfe2 as UNINTERESTING while processing 373af0c,
and so it gets pruned.

Is there some way around this, or would a patch to fix it be acceptable?

On Wed, 2012-02-01 at 00:27 +0000, Bryan O'Sullivan wrote:

On 2012-01-31 16:15 , "Bryan O'Sullivan" [off-list ref] wrote:

quoted

I'm trying to use "git log" to display only a handful of commits, where
the commits are not necessarily linearly related to each other.

And I beautifully fat-fingered the "send" key. Oops.

What I was *going* to say was that it looks like revision.c:limit_list is
(whether intentionally or not) getting in the way of this.

Here's a sample command line against a kernel tree:

git log 373af0c^..373af0c 590dfe2^..590dfe2

I want git to log those two specific commits, but in fact it looks like
limit_list is marking 590dfe2 as UNINTERESTING while processing 373af0c,
and so it gets pruned.

Is there some way around this, or would a patch to fix it be acceptable?

From my reading of the manpage (and the way most git commands work) log
accepts one range of commits. They all get bunched up together.

You might find cat-file's --batch mode interesting.

    git rev-list 373af0c^..373af0c | git cat-file --batch
    git rev-list 590dfe2^..590dfe2 | git cat-file --batch

looks a lot like what you're looking for.

   cmn

On Wed, Feb 01, 2012 at 01:39:29AM +0100, Carlos Martín Nieto wrote:

quoted

Here's a sample command line against a kernel tree:

git log 373af0c^..373af0c 590dfe2^..590dfe2

I want git to log those two specific commits, but in fact it looks like
limit_list is marking 590dfe2 as UNINTERESTING while processing 373af0c,
and so it gets pruned.

Is there some way around this, or would a patch to fix it be acceptable?

From my reading of the manpage (and the way most git commands work) log
accepts one range of commits. They all get bunched up together.

Right. That command is equivalent to:

  373af0c 590dfe2 --not 373af0c^ 590dfe2^

So the limiting for one range you're interested in ends up marking part
of the other as uninteresting, and that's by design. This topic came up
recently, and I think the general consensus is that it would be cool to
be able to do totally independent ranges, but that would be backwards
incompatible with the current behavior.

In the general case, you can emulate this with:

  { git log 373af0c^..373af0c
    git log 590dfe2^..590dfe2
  } | $PAGER

which is of course slightly more annoying to type. If you're just
interested in _single_ commits, though, you can just give the commits
and turn off walking:

  git log --no-walk 373af0c 590dfe2

You might find cat-file's --batch mode interesting.

    git rev-list 373af0c^..373af0c | git cat-file --batch
    git rev-list 590dfe2^..590dfe2 | git cat-file --batch

looks a lot like what you're looking for.

I think you could even drop the rev-lists in this case, since he just
wants a single commit. However, cat-file lacks the niceties of "log",
like fancy --pretty formatting and automatic diffing against parents.

-Peff

On 2012-01-31, "Jeff King" [off-list ref] wrote:

This topic came up
recently, and I think the general consensus is that it would be cool to
be able to do totally independent ranges, but that would be backwards
incompatible with the current behavior.

That's totally sensible. I hadn't been able to tell from inspection
whether the behaviour was deliberate or not.

which is of course slightly more annoying to type. If you're just
interested in _single_ commits, though, you can just give the commits
and turn off walking:

 git log --no-walk 373af0c 590dfe2

Oh, nice! I hadn't seen that option.

By the way, the reason I'm even interested in this in the first place is
that the performance of commands like "git blame" and "git log" on files
and subtrees has become a problem for us (> 10 seconds per invocation,
forecast to get much worse), and I wanted to see whether I could feed "git
log" a specific list of revisions, and if so, whether that could yield
good performance.

I have it in mind to build a secondary index (maintained externally) so
that I can supply these git commands with precise lists of revisions for
much faster response times.

Thanks, guys!

On Wed, Feb 01, 2012 at 01:02:57AM +0000, Bryan O'Sullivan wrote:

By the way, the reason I'm even interested in this in the first place is
that the performance of commands like "git blame" and "git log" on files
and subtrees has become a problem for us (> 10 seconds per invocation,
forecast to get much worse), and I wanted to see whether I could feed "git
log" a specific list of revisions, and if so, whether that could yield
good performance.

That sounds kind of slow. Is your repository really gigantic? Have you packed
everything? I'm just curious if there's some other way to make things
faster. Is the repository publicly available?

-Peff

On 2012-01-31 19:03 , "Jeff King" [off-list ref] wrote:

That sounds kind of slow. Is your repository really gigantic?

Bigger than a kernel tree, but not as many commits. Beyond that, can't say.

Have you packed
everything?

Yep.

I'm just curious if there's some other way to make things
faster.

It would be nice if there was, but the fundamental problem is the lack of
an index from filename to commit. Walking every commit is the limiting
factor, I believe.

Is the repository publicly available?

No, sorry.