Thomas Rast <tr...@inf.ethz.ch> writes:
> Michael Haggerty <mhag...@alum.mit.edu> 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
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
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
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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html