Thomas Rast <trast@xxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
