Thomas Rast <trast@xxxxxxxxxxx> writes: > Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > > On IRC you said you would like a version that always acts as > --no-commit, and simply returns the conflict/no conflict bit as usual. > The caller would then proceed using commit-tree itself. I think that is > probably a saner solution than this "output ref" idea. I just had a huge facepalm moment. We already have this option. It is called git-merge-recursive. That is, git merge-recursive $(git merge-base --all HEAD other) -- HEAD other will internally do all the work that 'git merge other' would do, but not update any refs. With this series, you can therefore say git merge-recursive --index-only $(git merge-base --all HEAD other) -- HEAD other and get an *index-only* merge of HEAD and other. Can you see if this is enough to build git-imerge on top of it? Otherwise I'm glad to help with building the git-merge infrastucture to support it. I'll send v2 of the series in a minute; the only change is that I changed the internal flag semantics as per Junio's comment in http://thread.gmane.org/gmane.comp.version-control.git/229787/focus=229797 -- Thomas Rast tr@xxxxxxxxxxxxx -- 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