Re: preventing evil merges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 3, 2013 at 7:20 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Sandro Santilli <strk@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]