threads / discuss / 17290

Merging adjacent deleted lines?

Subject: Merging adjacent deleted lines?

## tl;dr

9 messages between Jan 21, 2009 and Jan 23, 2009.

replies: 8people: 4as markdown or json

Jonathan del Strother· Jan 21, 2009, 19:20 UTC · lore
Say I have a file that started out with the following content :

line1 line2 line3 line4

I create a branch, which deletes line2.  Someone else's branch deletes line 3.
When I merge those two branches, the conflict looks like :

line1 <<<<<<< HEAD:lines line3 ======= line2

>>>>>>> SomeoneElse:lines
line4

Which in my cursory overview, looked an awful lot like the obvious merge resolution ought to be

line1 line3 line4

After all - I know I want to delete line 2, and wasn't aware of the other person deleting line 3.

It was only later that we discovered that the merge was broken and both lines should have been deleted. Thinking about it, I guess that the conflict if the other branch _hadn't_ deleted line 3 would have looked something like

line1 <<<<<<< HEAD:lines ======= line2

>>>>>>> SomeoneElse:lines

line3 line4

 - which wouldn't have resulted in a conflict anyway.

So, it looks like I need to be way more careful when merging conflicts. Which leads me to - what tools do you use when studying conflicts like that? git blame seems the obvious one, for getting the context of each deletion, but it seems like I need to run it once as git blame HEAD lines, and once as git blame MERGE_HEAD lines. Is there something a little more integrated for comparing the origin of each change from both merge branches simultaneously?

Would welcome any thoughts on how you guys approach conflict-resolution -Jon

Robin Rosenberg· Jan 21, 2009, 19:49 UTC · re: Jonathan del Strother · lore

Re: Merging adjacent deleted lines?

onsdag 21 januari 2009 20:20:50 skrev Jonathan del Strother: [...]

Show 9 quoted lines
> So, it looks like I need to be way more careful when merging
> conflicts.  Which leads me to - what tools do you use when studying
> conflicts like that?  git blame seems the obvious one, for getting the
> context of each deletion, but it seems like I need to run it once as
> git blame HEAD lines, and once as git blame MERGE_HEAD lines.  Is
> there something a little more integrated for comparing the origin of
> each change from both merge branches simultaneously?
> 
> Would welcome any thoughts on how you guys approach conflict-resolution

I think you've illustrated a case for graphical merge resolution tools, i.e. run git mergetool to help resolve the conlicts. It will run a graphical tool for you.

The list seems to be: kdiff3 kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
None of the tools can run blame in the merge tool also. That would be nice.
-- robin
Junio C Hamano· Jan 21, 2009, 21:08 UTC · re: Jonathan del Strother · lore

Re: Merging adjacent deleted lines?

Jonathan del Strother <maillist@steelskies.com> writes:
Show 28 quoted lines
> Say I have a file that started out with the following content :
>
> line1
> line2
> line3
> line4
>
>
> I create a branch, which deletes line2.  Someone else's branch deletes line 3.
>
> When I merge those two branches, the conflict looks like :
>
> line1
> <<<<<<< HEAD:lines
> line3
> =======
> line2
>>>>>>>> SomeoneElse:lines
> line4
>
>
>
> Which in my cursory overview, looked an awful lot like the obvious
> merge resolution ought to be
>
> line1
> line3
> line4
Why?  The obvious resolution would be:
    line1
    line4

as it is obvious that you do not want line2 and the other does not want line3.

But that is only true if it is obvious to you. When you cannot remember what each side did since they forked, there are two ways you can use to understand the history better without resorting to graphical merge tools.

  $ git log -p --merge <path>

which shows you the commits involved in the conflict, what they did, and why they did what they did (of course, this assumes that your project participant did their commits properly).

  $ git checkout --conflict=diff3 <path>

This will add an extra block to the conflicted output to show the common ancestor's version, after showing yours. The conflicts left in <path> would look like this:

    line1
    <<<<<<< ours
    line3
    |||||||
    line2
    line3
    =======
    line2
    >>>>>>> theirs
    line4
which may make it clearer that you deleted line2 and they deleted line3.
Jonathan del Strother· Jan 22, 2009, 10:57 UTC · re: Junio C Hamano · lore

Re: Merging adjacent deleted lines?

On Wed, Jan 21, 2009 at 7:49 PM, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:

Show 6 quoted lines
> onsdag 21 januari 2009 20:20:50 skrev Jonathan del Strother:
> [...]
> I think you've illustrated a case for graphical merge resolution tools, i.e.
> run git mergetool to help resolve the conlicts. It will run a graphical tool
> for you.
>

Mmm. I use opendiff, which is generally ok, but in this case produced a merge looking like this : http://pastie.org/paste/asset/367587/Picture_6.png Which, in my mind, isn't any clearer about the fact that both lines ought to be deleted than the text conflict markers are. Do any of the other graphical tools present conflicts like that differently?

On Wed, Jan 21, 2009 at 9:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
> But that is only true if it is obvious to you.  When you cannot remember
> what each side did since they forked, there are two ways you can use to
> understand the history better without resorting to graphical merge tools.
>
>  $ git log -p --merge <path>
>
Ahh, that's very helpful - thanks.
Robin Rosenberg· Jan 22, 2009, 20:13 UTC · re: Jonathan del Strother · lore

Re: Merging adjacent deleted lines?

torsdag 22 januari 2009 11:57:41 skrev Jonathan del Strother:
Show 15 quoted lines
> On Wed, Jan 21, 2009 at 7:49 PM, Robin Rosenberg
> <robin.rosenberg.lists@dewire.com> wrote:
> > onsdag 21 januari 2009 20:20:50 skrev Jonathan del Strother:
> > [...]
> > I think you've illustrated a case for graphical merge resolution tools, i.e.
> > run git mergetool to help resolve the conlicts. It will run a graphical tool
> > for you.
> >
> 
> Mmm.  I use opendiff, which is generally ok, but in this case produced
> a merge looking like this :
> http://pastie.org/paste/asset/367587/Picture_6.png
> Which, in my mind, isn't any clearer about the fact that both lines
> ought to be deleted than the text conflict markers are.  Do any of the
> other graphical tools present conflicts like that differently?
Try a three-way merge tool instead like, e.g. xxdiff.
-- robin
Jay Soffian· Jan 23, 2009, 07:18 UTC · re: Robin Rosenberg · lore

Re: Merging adjacent deleted lines?

On Thu, Jan 22, 2009 at 3:13 PM, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:

Show 11 quoted lines
> torsdag 22 januari 2009 11:57:41 skrev Jonathan del Strother:
>> Mmm.  I use opendiff, which is generally ok, but in this case produced
>> a merge looking like this :
>>
>> http://pastie.org/paste/asset/367587/Picture_6.png
>>
>> Which, in my mind, isn't any clearer about the fact that both lines
>> ought to be deleted than the text conflict markers are.  Do any of the
>> other graphical tools present conflicts like that differently?
>
> Try a three-way merge tool instead like, e.g. xxdiff.

opendiff (aka FileMerge) *is* a three-way merge tool. If the screenshot above is not clear, I'm not sure what would be. The left pane shows your copy of the file with only line1, line3, and line4. The right pane shows the other copy, with only line1, line2, and line4.

The lower pane shows the merge resolution, which currently has the single conflict highlighted, and is being resolved toward the right. You can use the Action drop down menu to resolve the conflict one of five ways: left, right, both (left first), both (right first), neither. You've currently got "right" selected. The appropriate resolution is "neither", which keeps neither line3 from the left, nor line2 from the right.

Shrug.
j.
Robin Rosenberg· Jan 23, 2009, 10:32 UTC · re: Jay Soffian · lore

Re: Merging adjacent deleted lines?

fredag 23 januari 2009 08:18:15 skrev Jay Soffian:
> On Thu, Jan 22, 2009 at 3:13 PM, Robin Rosenberg
> <robin.rosenberg.lists@dewire.com> wrote:
[...]
Show 7 quoted lines
> > Try a three-way merge tool instead like, e.g. xxdiff.
> 
> opendiff (aka FileMerge) *is* a three-way merge tool. If the
> screenshot above is not clear, I'm not sure what would be. The left
> pane shows your copy of the file with only line1, line3, and line4.
> The right pane shows the other copy, with only line1, line2, and
> line4.

Where's the ancestor? I'm used to having four panes for doing three-way merges, but your screenshot showed only three.

> 
> Shrug.
You have the option to ignore me....
-- robin
Jay Soffian· Jan 23, 2009, 15:51 UTC · re: Robin Rosenberg · lore

Re: Merging adjacent deleted lines?

On Fri, Jan 23, 2009 at 5:32 AM, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:

> Where's the ancestor? I'm used to having four panes for doing three-way
> merges, but your screenshot showed only three.

I installed xxdiff to compare w/opendiff, meld, and vimdiff and I see what you mean with xxdiff.

opendiff/meld/vimdiff don't show the ancestor directly, but they are still using it in order to show how one version differs from the ancestor in the left pane, and how the other version differs in the right pane.

>> Shrug.
>
> You have the option to ignore me....
Doh, I meant only "I don't understand." My apologies.
j.
Jay Soffian· Jan 23, 2009, 15:59 UTC · re: Jay Soffian · lore

Re: Merging adjacent deleted lines?

On Fri, Jan 23, 2009 at 10:51 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> opendiff/meld/vimdiff don't show the ancestor directly, but they are
> still using it in order to show how one version differs from the
> ancestor in the left pane, and how the other version differs in the
> right pane.

Hmm, okay. I see that meld/vimdiff are apparently not doing a 3-way merge. So I guess after all this, I don't have an explanation about opendiff. It claims to do a 3-way diff and mergetool is passing it the ancestor as an argument. Sorry for the confusion.

j.

← back to recent threads