Stefan Beller <sbeller@xxxxxxxxxx> writes:
> diff --git a/list-objects.c b/list-objects.c
> index bf46f80dff..5e114c9a8a 100644
> --- a/list-objects.c
> +++ b/list-objects.c
> @@ -237,6 +237,8 @@ void traverse_commit_list(struct rev_info *revs,
> if (commit->tree)
> add_pending_tree(revs, commit->tree);
> show_commit(commit, data);
> + if (revs->tree_blobs_in_commit_order)
> + traverse_trees_and_blobs(revs, &base_path, show_object, data);
> }
> traverse_trees_and_blobs(revs, &base_path, show_object, data);
This one is interesting. While we walk the ancestry chain, we may
add the tree for each commit that we discover to the "pending. We
used to sweep the pending array at the end after we run out of the
commits, but now we do the sweeping as we process each commit.
Would this make the last call to traverse_trees_and_blobs() always a
no-op? I am not suggesting to add a new conditional in front of it;
I am just asking for curiosity's sake.
> diff --git a/t/t6100-rev-list-in-order.sh b/t/t6100-rev-list-in-order.sh
> new file mode 100755
> index 0000000000..67ebe815d2
> --- /dev/null
> +++ b/t/t6100-rev-list-in-order.sh
> @@ -0,0 +1,44 @@
> +#!/bin/sh
> +
> +test_description='miscellaneous rev-list tests'
> +
> +. ./test-lib.sh
> +
> +
> +test_expect_success 'setup' '
> + for x in one two three four
> + do
> + echo $x >$x &&
> + git add $x &&
> + git commit -m "add file $x"
> + done &&
> + for x in four three
> + do
> + git rm $x
> + git commit -m "remove $x"
> + done &&
There is break in &&-chain in the second loop, but in any case, for
loops and &&-chains do not mix very well unless done carefully.
Imagine what happens if "git commit" in the first loop failed when
x is two; it won't stop and keep going to create three and four and
nobody would noice any error.
> + git rev-list --in-commit-order --objects HEAD >actual.raw &&
> + cut -c 1-40 > actual < actual.raw &&
> +
> + >expect &&
> + git rev-parse HEAD^{commit} >>expect &&
> + git rev-parse HEAD^{tree} >>expect &&
> +...
> + git rev-parse HEAD~5^{tree} >>expect &&
Ooooh, ugly ;-). I wish we had --stdin interface or something.
Short of that, I'd probably write this more like...
git rev-parse >expect \
A B C D \
E F
Even though we do not have --stdin for rev-parse, you can still do:
git cat-file --batch-check='%(objectname)' >expect <<-\EOF &&
HEAD^{commit}
HEAD^{tree}
HEAD:one
HEAD:two
...
EOF
> + test_cmp expect actual
> +'
> +
> +test_done
