From: Neal Groothuis Date: Thu, 02 Feb 2012 15:09:36 GMT Subject: Re: How to find and analyze bad merges? Message-ID: <8489.38.96.167.131.1328195376.squirrel@mail.lo-cal.org> In-Reply-To: >> 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.