On Mon, Jun 3, 2013 at 7:20 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Sandro Santilli <s...@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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
