How to find and analyze bad merges?

How to find and analyze bad merges?

[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

Re: How to find and analyze bad merges?

[Junio C Hamano]

"norbert.nemec" <norbert.nemec@native-instruments.de> writes:

> 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.

Bisect?

Re: How to find and analyze bad merges?

[norbert.nemec]

Am 02.02.12 09:16, schrieb Junio C Hamano:
> "norbert.nemec"<norbert.nemec@native-instruments.de>  writes:
>
>> 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.
>
> Bisect?

This is not the point: My colleague knew exactly which commit contained 
the bugfix. The trouble was finding out why this bugfix disappeared even 
though everything indicated that it was cleanly merged into the current 
branch.

Re: How to find and analyze bad merges?

[Junio C Hamano]

"norbert.nemec" <norbert.nemec@native-instruments.de> writes:

>> Bisect?
>
> This is not the point: My colleague knew exactly which commit
> contained the bugfix. The trouble was finding out why this bugfix
> disappeared even though everything indicated that it was cleanly
> merged into the current branch.

Then again "Bisect?"

I wasn't and I am not suggesting to use Bisect to find the original fix. I
was suggesting to use Bisect to find the _merge_ you were looking for.

Re: How to find and analyze bad merges?

[norbert.nemec]

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
>

Re: How to find and analyze bad merges?

[Norbert Nemec]

To be yet more precise:

My complaint is that you need this kind of sledge-hammer solutions to 
analyze the situation. I, as an semi-expert with git did manage to find 
the problem without even having to resort to bisect or manually redoing 
the merge. My complaint is about the perspective of the 
medium-experienced user who is completely puzzled by the fact that a
"git log <filename>" silently skips the critical merge commit.




Am 02.02.12 11:40, schrieb Thomas Rast:
> "norbert.nemec"<norbert.nemec@native-instruments.de>  writes:
>
>> 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.
>
>    git checkout M^
>    git merge M^2
>    git diff M HEAD
>
> You'd have to resolve conflicts though.  If you want to skip that, I
> think you could still see some information if you said
>
>    git reset
>    git diff M
>
> to see the differences between the (unmerged, with conflict hunks) state
> in the worktree and M.
>
> (Remember to re-attach your HEAD after playing around like this.)
>
>> Am 02.02.12 09:16, schrieb Junio C Hamano:
>>>
>>> Bisect?
>>
>> This is not the point: My colleague knew exactly which commit
>> contained the bugfix. The trouble was finding out why this bugfix
>> disappeared even though everything indicated that it was cleanly
>> merged into the current branch.
>
> But that makes it a prime candidate for bisect: you know the good commit
> (the original bugfix), and you know that the newest version is bad.
> Bonus points if you have an automated test for it, in which case bisect
> can nail the offender while you get coffee.
>
> Or am I missing something?
>

-- 
Dr. Norbert Nemec
Teamleader Software Development

Tel +49-30-611035-1882
norbert.nemec@native-instruments.de

KOMPLETE 8 ULTIMATE - the premium NI producer collection
=>  http://www.native-instruments.com/komplete8

TRAKTOR KONTROL S2 - the professional 2.1 DJ system
=>  http://www.native-instruments.com/s2

->>>>>> NATIVE INSTRUMENTS - The Future of Sound <<<<<<-

Registergericht: Amtsgericht Charlottenburg
Registernummer: HRB 72458
UST.-ID.-Nr. DE 20 374 7747

Geschäftsführung: Daniel Haver (CEO), Mate Galic

Re: How to find and analyze bad merges?

[David Barr]

On Thu, Feb 2, 2012 at 10:17 PM, Norbert Nemec
<norbert.nemec@native-instruments.de> wrote:
> To be yet more precise:
>
> My complaint is that you need this kind of sledge-hammer solutions to
> analyze the situation. I, as an semi-expert with git did manage to find the
> problem without even having to resort to bisect or manually redoing the
> merge. My complaint is about the perspective of the medium-experienced user
> who is completely puzzled by the fact that a
> "git log <filename>" silently skips the critical merge commit.

Do the -c --cc or -m flags for git log help in this case?
They alter the way merge diffs are presented, as described under Diff Formatting
in the git-log(1)  man page.
--
David Barr

Re: How to find and analyze bad merges?

[Jonathan Nieder]

David Barr wrote:

> Do the -c --cc or -m flags for git log help in this case?
> They alter the way merge diffs are presented, as described under Diff Formatting
> in the git-log(1)  man page.

I suspect Norbert was running into history simplification, so the --full-history
flag would be the relevant one.

See the thread [1] for a few relevant side-notes.

[1] http://thread.gmane.org/gmane.comp.version-control.git/188904

Re: How to find and analyze bad merges?

[norbert.nemec]

Am 02.02.12 13:03, schrieb Jonathan Nieder:
> David Barr wrote:
>
>> Do the -c --cc or -m flags for git log help in this case?
>> They alter the way merge diffs are presented, as described under Diff Formatting
>> in the git-log(1)  man page.
>
> I suspect Norbert was running into history simplification, so the --full-history
> flag would be the relevant one.

Not quite.

As far as I understand it, history simplification hides the whole branch 
if its changes did not end up in the current branch.

When I tried it out, the --full-history prevented hiding the 
bugfix-commit itself, but it did not show the critical merge commit in 
the log.

> 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.

Re: How to find and analyze bad merges?

[Neal Groothuis]

>> 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.

Re: How to find and analyze bad merges?

[norbert.nemec]

Am 02.02.12 12:41, schrieb David Barr:
> On Thu, Feb 2, 2012 at 10:17 PM, Norbert Nemec
> <norbert.nemec@native-instruments.de>  wrote:
>> To be yet more precise:
>>
>> My complaint is that you need this kind of sledge-hammer solutions to
>> analyze the situation. I, as an semi-expert with git did manage to find the
>> problem without even having to resort to bisect or manually redoing the
>> merge. My complaint is about the perspective of the medium-experienced user
>> who is completely puzzled by the fact that a
>> "git log<filename>" silently skips the critical merge commit.
>
> Do the -c --cc or -m flags for git log help in this case?
> They alter the way merge diffs are presented, as described under Diff Formatting
> in the git-log(1)  man page.

Indeed, these help somewhat. This way, the changes are not hidden, but 
instead lost in the multitude of trivially-resolved conflicts...