Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> (a) Both A and D bring the same subdirectory contents. 'rev-list >> --parents -- $subdir' drops one side of the merge during pruning. It >> does not look past the merge to see whether the contents were >> arrived at via different changesets. Thus the history becomes >> >> A' -- C' >> >> D' >> >> and even that only if D was reachable by a different ref, >> otherwise D' is simply dropped. > > And this is what I call wrong. Simply dropping one side of the equation > is not what I call "sane". > > If you drop information, you are disagreeing with "content is king". I think the aggressive merge simplification that gives "one simplest explanation for the contents of the paths specified" is a wrong mode of operation to use when you are filtering branches. It might be a good thing to support as an option, but I agree with you that it should not be the default. Perhaps --full-history is needed to the rev-list call (and the recent invention --simplify-merges that will hopefully appear sometime after 1.6.0)? See recent discussion of --full-history and the default merge simplification between Linus and Roman Zippel. I suspect that back when the original cg-rewritehistory was written, not many people understood the issues explained in that thread. -- 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
