Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > I was expecting that it works like "First follow the first-parent, and > then simplify the history with respect to builtin-fetch.c." If you first follow the first-parent, the result will by definition not have any merges, so there is nothing left to simplify. History simplification is about merge removal, looking at all parents. Removing commits from a single strand of pearls that do not touch the specified pathspecs is called "--dense" (which is on the default) and can be disabled with "--sparse". So, no, it is not a matter of definition, as "first follow the first-parent then simplify" does not make much sense. - 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
