Re: [RFC PATCH] Documentation: rev-list-options: clarify history simplification with paths

[Junio C Hamano <gitster@pobox.com>]

Thomas Rast <trast@student.ethz.ch> writes:

>   $ g rev-list --pretty=oneline --full-history HEAD -- dir
> ...
> But --parents --full-history magically revives the merge:
> ...

Personally I do not think --full-history without --parents is of much
usefulness (I'd let Linus or somebody else defend this usage, or make it
imply revs.rewrite_parents otherwise).  If you remove that case from your
set of experiments in the equation, do the rest of the results make sense?

> More to the point, --simplify-merges actually shows the merge when
> --full-history does not, resulting in ...

One thing I forgot to mention (but the code of course does not forget to
do) in the series is that --simplify-merges implies revs.rewrite_parents
which roughly translates to your experiments from the command line to
always have --parents option.

>   $ git rev-list --pretty=oneline --sparse --parents --simplify-merges HEAD -- dir
>   e0083e6... aad9982... 984aa48... b3127f4... Merge branches 'side' and 'unrelated'
>   b3127f4... b60c459... d: unrelated
>   984aa48... b60c459... C: dir=B
>   aad9982... b60c459... B: dir
>   b60c459... ad7052b... A: dir
>   ad7052b... initial

I am not sure what one should expect from combination between these two
options.  --sparse says do not drop commits that are of no interest with
respect to the paths specified, while --simplify-merges tells it to
simplify merges so that the remaining graph shows only the ones that have
relevance to !TREESAME (iow "has some changes") nodes.