Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > Am 4/21/2010 9:34, schrieb Johan Herland: >> I can confirm that this patch works with my original (more complicated) >> scenario. I've also played around with combinations of --ancestry-path, -- >> graph and --parents (and even --boundary), and AFAICS, the new option does >> not clobber the other options, and (IMHO) it all behaves correctly in the >> scenarios I've tested. > > How about possible interactions with --reverse; --date-order/--topo-order, > --parents (important for gitk); --simplify-by-decoration (useful for your > problem that triggered this); --full-history and --simplify-merges with > path limiting? These are all good points. I am reasonably sure that parents (specifically, "rewrite_parents") is broken. The new function should cull parents that do not appear on the ancestry path from merges (that is what "NEEDSWORK" is about). It may or may not break gitk, though---these off-path parents are shown as parents of an on-path merge but will be marked as UNINTERESTING. I do not think reverse/date-order/topo-order would be affected by this change, as they only change the presentation order of what limit_list() returns; Also simplify-merges and full-history should be Ok, as they control what is done in the current logic in limit_list(), which is an input to the new logic, meaning that the new logic will work on already simplified history. This is not a new problem, but I strongly suspect that cherry-pick is broken the same way wrt "rewrite_parents". -- 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