the surprising success of dive notes merging

[Dirk Hohndel]

So based on Linus' comments about the potential risks with my merge
stategy in the case of multi line dive notes I went out to write a test
case that showed how things were breaking and then planned to fix what got
damaged.

I'll push the test that I wrote soon, the basic idea was to have three
dives which started with identical multi line notes:

	Create multi line dive notes
	Line 2
	Line 3
	Line 4
	Line 5
	That should be enough

And then modify them offline to read

	Create multi line dive notes
	Different line 2 and removed 3-5

	That should be enough

and

	Line 2
        Line 3
        Line 4
        Line 5

and

	single line dive notes

And modify the cloud repository to contain

	Completely different dive notes
        But also multi line

and

	single line dive notes

and
	
	Line 2
        Line 3
        Line 4
        Line 5

I'm not sure if maybe I just didn't hit the right weird cases, but this
all merged perfectly (and I define this as "no problems parsing the data
and the result is at least consistent".

The three dives (when looking at the git repo cache) now contain this:

notes "Create multi line dive notes
        Different line 2 and removed 3-5

        That should be enough"
notes "Completely different dive notes
        But also multi line"


and


notes "Line 2
        Line 3
        Line 4
        Line 5"
notes "single line dive notes"


and


notes "single line dive notes"
notes "Line 2
        Line 3
        Line 4
        Line 5"


So the merge added both notes fields completely.  And when written back
out, in each case simply the second set of notes is picked.

Now one could argue we should keep both - I don't know what's best... but
I'm rather surprised that git kept the strings intact and didn't create
anything that would cause us a parsing error.

Cool. Another worry off my list :-)

/D