Commit Message

Allow easier parsing by cat-file by giving rev-list an option to print
only the OID of a non-commit object without any additional information.
This is a short-term shim; later on, rev-list should be taught how to
print the types of objects it finds in a format similar to cat-file's.
Before this commit, the output from rev-list needed to be massaged
before being piped to cat-file, like so:
git rev-list --objects HEAD | cut -f 1 -d ' ' |
git cat-file --batch-check
This was especially unexpected when dealing with root trees, as an
invisible whitespace exists at the end of the OID:
git rev-list --objects --filter=tree:1 --max-count=1 HEAD |
xargs -I% echo "AA%AA"
Now, it can be piped directly, as in the added test case:
git rev-list --objects --no-object-names HEAD | git cat-file --batch-check
Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
Change-Id: I489bdf0a8215532e540175188883ff7541d70e1b
---
Since v4, added the new options to `git help rev-list`.
Documentation/git-rev-list.txt | 1 +
Documentation/rev-list-options.txt | 10 ++++++++++
builtin/rev-list.c | 19 ++++++++++++++++++-
t/t6000-rev-list-misc.sh | 20 ++++++++++++++++++++
4 files changed, 49 insertions(+), 1 deletion(-)

Comments

On Wed, Jun 19, 2019 at 01:56:56PM -0700, Emily Shaffer wrote:
> Allow easier parsing by cat-file by giving rev-list an option to print> only the OID of a non-commit object without any additional information.> This is a short-term shim; later on, rev-list should be taught how to> print the types of objects it finds in a format similar to cat-file's.> [...]
I missed some of the intermediate rounds, but fortunately Junio already
said everything I was going to. :) This version looks good to me, though
with one minor nit:
> diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt> index 88609ff435..9392760b25 100644> --- a/Documentation/git-rev-list.txt> +++ b/Documentation/git-rev-list.txt> @@ -48,6 +48,7 @@ SYNOPSIS> [ --date=<format>]> [ [ --objects | --objects-edge | --objects-edge-aggressive ]> [ --unpacked ]> + [ --object-names | --no-object-names ]> [ --filter=<filter-spec> [ --filter-print-omitted ] ] ]> [ --missing=<missing-action> ]> [ --pretty | --header ]
Here you put --object-names along with the --objects. Which kind of
makes sense, but everything else in that block is about choosing _which_
commits to show. In the short help, you put it near --pretty:
> @@ -49,6 +49,7 @@ static const char rev_list_usage[] => " --objects | --objects-edge\n"> " --unpacked\n"> " --header | --pretty\n"> +" --[no-]object-names\n"> " --abbrev=<n> | --no-abbrev\n"> " --abbrev-commit\n"> " --left-right\n"
which I think makes more sense. I think maybe you were trying to imply
that "--object-names" is not useful unless you're also using
"--objects". Which is true, but I'm not sure it's obvious from that mass
of brackets (and I think is sufficiently covered in the actual option
descriptions you give later).
> +test_expect_success '--no-object-names and --object-names are last-one-wins' '> + git rev-list --objects --no-object-names --object-names --all >output &&> + grep wanted_file output &&> + git rev-list --objects --object-names --no-object-names --all >output &&> + ! grep wanted_file output> +'
We don't generally test this behavior for each option, since it would
lead to a ton of uninteresting tests (and parse-options generally just
handles it). But after our discussion about --no-abbrev, I can see how
you might be more interested in the topic. :) So I'm OK with it either
way.
-Peff