Re: [RFC PATCH] Documentation: rev-list-options: clarify history simplification with paths
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 10, 2008, 19:19 UTC
- Message-ID
- <7vabfk3cge.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <1218375840-4292-1-git-send-email-trast@student.ethz.ch>
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.
Show 7 quoted lines
> $ 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.