>> See the thread [1] for a few relevant side-notes. > > > > [1] http://thread.gmane.org/gmane.comp.version-control.git/188904 > > As I understand this thread, the user only requested all commits that > "modify a file". Our merge-commit strictly speaking did not modify the > file but simply kept one of the versions, completely swamping all > modifications from one branch. Exactly the case that is still not > covered by --full-history. The thread was prompted by the difficulty I had in figuring out where a co-worker had accidentally squashed changes in a branch that was being merged in; I think that's the same issue that you have described. Re: the merge: it kept one of the versions, but not the other; I would consider that a change. This is particularly problematic if you do a "git log --full-history --simplify-merges". The simplified history that is presented will not show the merge, even though in the simplified history the merge turns into a regular commit that differs from its parent. It seems that the history is being simplified to the point of being inaccurate. I believe that this is a result checking for TREESAME-ness before the history simplification occurs, rather than after. I would love to see this behavior changed, or at the least, an option added to allow the user to control it. -- 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