Git merge disappointment

[Aristotle Pagaltzis]

* chombee <chombee at lavabit.com> [2010-04-25 16:40]:
> I was thinking that there should be some way to coerce git's
> merge algorithm into producing the results I want.

It’s really the diff algorithm that’s getting fouled up. Because
the empty lines are common to both copies of the file, it gets
hung up on using those as fixed points and never realises that
the lines with content would line up if it matched more lazily.
So it ends up comparing each paragraph in one copy with the next
one in the other so it interleaves them in the output.

The solution is to use a better common marker than empty lines,
eg. you could end all your notes with a `----` paragraph, or
a `<!-- -->` line if you don’t want a horizontal rule in the
HTML output.

Git will still find a conflict, but it’ll be just one hunk at the
top of the file, containing one side on each side of the
conflict, so to resolve the file you can just delete the conflict
markers. That’s quick and easy.

> In my case I wouldn't want to add each entry in a random place,
> the notes file is supposed to be (more or less) chronological.
> But I wonder if there's some change I could make to how I write
> notes that would protect each entry, preventing it from being
> split into pieces by git's Merge algorithm. You probably can't
> beat a custom merge script though.

Well, at least in one sense, it’s correct that git treats this as
a conflict: do you want the lines from head A in front of the
lines from head B or vice versa? It cannot know. Eg. if you
wanted to keep your notes in *strictly* chronological order,
across branches, then git wouldn’t know to merge two diverged
copies of such a file correctly, no matter what you do. (Unless
you always immediately commit after changing the file, then it
could use the commit timestamp as a proxy for time at which the
file timestamp it doesn’t have. But that doesn’t generalise to
other orderings.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>