Re: Do not raise conflict when a code in a patch was already added

2018-08-21 Thread Igor Djordjevic
Hi Konstantin, On 21/08/2018 11:37, Konstantin Kharlamov wrote: > > > There's another possibility (and I think it is what happens > > actually in Konstantin's case): When one side added lines 1 2 and the > > other side added 1 2 3, then the actual conflict is > > << 1 2 == 1 2 3 >>, but our

Re: Do not raise conflict when a code in a patch was already added

2018-08-21 Thread Konstantin Kharlamov
On 20.08.2018 22:22, Johannes Sixt wrote: Am 20.08.2018 um 19:40 schrieb Phillip Wood: On 20/08/2018 11:22, Konstantin Kharlamov wrote: It's spectacular, that content of one of inserted conflict markers is empty, so all you have to do is to remove the markers, and use `git add` on the file,

Re: Do not raise conflict when a code in a patch was already added

2018-08-20 Thread Johannes Sixt
Am 20.08.2018 um 19:40 schrieb Phillip Wood: On 20/08/2018 11:22, Konstantin Kharlamov wrote: It's spectacular, that content of one of inserted conflict markers is empty, so all you have to do is to remove the markers, and use `git add` on the file, and then `git rebase --continue` Its a lot

Re: Do not raise conflict when a code in a patch was already added

2018-08-20 Thread Phillip Wood
On 20/08/2018 11:22, Konstantin Kharlamov wrote: > So, steps-to-reproduce below rather full of trivia like setting up a > repo, but the TL;DR is: > > Upon using `git rebase -i HEAD~1` and then `git add -p` to add part of a > "hunk" as one commit, and then using `git rebase --continue` so the >

Do not raise conflict when a code in a patch was already added

2018-08-20 Thread Konstantin Kharlamov
So, steps-to-reproduce below rather full of trivia like setting up a repo, but the TL;DR is: Upon using `git rebase -i HEAD~1` and then `git add -p` to add part of a "hunk" as one commit, and then using `git rebase --continue` so the other part of hunk would be left in top commit; git raises a