Re: Git merge disappointment

[Aristotle Pagaltzis]

* chombee chom...@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/
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: Git merge disappointment

[chombee]

Thanks all. Patience diff may be what I was looking for. I don't want to
patch git, but perhaps I can implement patience-diff in my merge driver.
I haven't tested but apparently bzr uses patience diff, it may be that
if I put my notes file in bzr it will just work.

___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: Git merge disappointment

[chombee]

On Sat, Apr 24, 2010 at 12:22:13PM -0700, Gary Johnson wrote:
 Git (or the merge tool that git uses) doesn't know that those
 changes are unrelated.  From its perspective, the top of the file
 has been added to with different sets of lines that should resolve
 to one change.  It does its best, making some assumptions, to merge
 those lines.

Yeah, I understand. I was surprised by the result though. In theory git
does know that entry A and entry B each constitutes a coherent whole.
Entry A was added, all as one hunk, but commit a, and entry B by commit
b, and then git interleaves the two hunks.

 I wrote a script that merges two revisions of a file by assuming
 that the user simply wants to insert the changes in the local copy
 of the file ahead of the latest version in the repository.

Yeah. I've been looking around, and it looks like there are a couple of
options. You can get diff3 style or svn style merge conflicts, but
neither seems like it will be any more useful. And you can provide your
own program to carry out the merge, git calls this a custom merge
driver. It should be possible to write a simple one for my case.
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home