Matthew DeVore <matvore@xxxxxxxxxx> writes:
> -List commits that are reachable by following the `parent` links from the
> -given commit(s), but exclude commits that are reachable from the one(s)
> -given with a '{caret}' in front of them. The output is given in reverse
> -chronological order by default.
> +List objects that are reachable by following references from the given
> +object(s), but exclude objects that are reachable from the one(s) given
> +with a '{caret}' in front of them.
>
> +By default, only commit objects are shown, and the commits are shown in
> +reverse chronological order. The '--object' flag causes non-commit objects
> +to also be shown.
>
> +You can think of this as a set operation. Objects given on the command
> +line form a set of objects that are reachable from any of them, and then
> +objects reachable from any of the ones given with '{caret}' in front are
> +subtracted from that set. The remaining objects are what come out in the
> command's output. Various other options and paths parameters can be used
> to further limit the result.
I am not sure if this is a good rewrite. It gives a false
impression as if you'd not see anything if I did this:
git rev-list --objects ^master md/filter-trees:t/valgrind
especially if you change the SYNOPSIS and make it claim that the
command takes <object> as starting point. Updating <commit> to
<object> for those that are _shown_ is OK, but the s/commit/object/
for those that are given as the starting points is not a good change
at all, if I understand what the code is designed to do correctly.
It is more like "this is a set operation across commits. We also
show objects that are reachable from the commits in the resulting
set and are not reachable from the commits in the set that were
excluded when --objects option is given".
