Re: preventing evil merges

[Antoine Pelisse <apelisse@gmail.com>]

On Mon, Jun 3, 2013 at 7:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Sandro Santilli <strk@keybit.net> writes:
>
>>  git merge anotherbranch
>>  git add something
>>  git commit --amend
>>
>> After the steps above the addition of "something" can't be found in
>> the history anymore, but the file is there.
>
> This is a very common and sensible thing to do when dealing with
> semantic conflict.  Imagine that you changed the name of a global
> variable in the code on your current branch since the anotherbranch
> you are pulling from forked from you.  Then imagine further that the
> anotherbranch added one location that refers to that variable.
>
> Since they are not aware of the name change, they added the new
> reference with the old variable name.  The part they added is a new
> code, so it is very likely that there is no textual conflict when
> you did "git merge anotherbranch".  But now the result is broken.
>
> And you fix that semantic conflict by editing the file they added
> the new reference to the variable under the old name and make it use
> the variable with the new name.  You "git add something" and amend
> the merge.
>
> "git show" of the result will show you what happened, I think.

Also, you need to use --cc option of log to see the change in history
(in addition to -p):

    git log --cc -p