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