Thinking about a possible solution:
Is there a way to re-do a merge-commit and diff the result against the
recorded merge without touching the working tree? This would be the
killer-feature to analyze a recorded merge-commit.
Am 02.02.12 09:10, schrieb norbert.nemec:
Hi there,
a colleague of mine happened to produce a bad merge by unintenionally
picking the version of the remote branch ("R") for all conflicting
files. Effectively, he eliminated a whole bunch of bugfixes that were
already on his local branch ("L").
Obviously this was a mistake on his side, but hey: everyone makes
mistakes. The real problem is to find this problem afterwards, possibly
weeks later, when you suddenly realize that a bug that you had fixed
suddenly reappears.
A "git log" on the whole repository shows both branches R and L.
A "git show" on the bugfix commit shows the bugfix as you expect it.
BUT:
A "git log" on the file itself shows neither the problematic merge nor
the bugfix commit. Git considers the merge of this file trivial because
the content is identical to that of parent R. Therefore, whatever
happened on branch L is not considered relevant history of the file.
FURTHERMORE:
A "git show" of the merge itself does not show the conflicting file
either. Obviously, "git show" on a merge decides which files are
relevant not based on conflicts but based on resolutions.
To sort out what happened, you first need to have a suspicion and then
dig fairly deep in the manuals to set the correct options to show what
happened.
I think, both "git log" and "git show" should by default be a bit more
conservative in hiding "insignificant" merges:
* In "git log" a branch should only be hidden if it never touched the file.
* In "git show" a merge should display all files that did have a
conflict independent of the resolution. (I am open to discuss whether
auto-resolvable conflicts should be displayed by default. Non-trivial
conflicts definitely should)
Greetings,
Norbert
--
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