On Tue, 23 Jan 2007, Linus Torvalds wrote: > > If you have just one simple merge-base, you'd do something like > > git merge-one-file \ > $(git merge-base HEAD other):filename \ > HEAD:filename \ > other:filename \ > filename > > (where those last three things are just the file mode) That comment made no sense. I removed the file modes entirely, and forgot to remove the comment. It turns out that you can just drop the file modes entirely from the invocation of least the current "git-merge-one-file", so I did that, to keep it cleaner and simpler. Anyway, the way "git merge-one-file" works, you pass it: - the SHA1 of the "base object" $(git merge-base HEAD other):filename - the SHA1 of the "current branch version of the file" HEAD:filename - the SHA1 of the "other branch version of the file" other:filename - the filename as you want the end result to be in the index filename - normally, you'd pass the file modes for the three cases too 0644 0644 0644 but those are the ones I skipped because the shell script actually only uses them to see if they are different (so dropping them means that it all works fine - the empty arguments are all the same). but additionally, since "git merge-one-file" expects to be in the middle of a real merge (and not just some faked-out single-file merging thing) it also expects the index to be populated in stage2 with the current branch version of the file - which it won't be outside of a merge. Which is why it ends up complaining. It would be kind of cool to have the whole "merge-recursive" logic (which can handle multiple ancestors etc - unlike the above) able to do this, but that's a whole 'nother kettle of fish. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html