From: Thomas Rast <tr@thomasrast.ch>
Date: Sat, 26 Oct 2013 14:40:22 GMT
Subject: Re: [PATCH 0/3] merge -Xindex-only
Message-ID: <87ob6cm6y1.fsf@linux-k42r.v.cablecom.net>
In-Reply-To: <87wqozbj0d.fsf@hexa.v.cablecom.net>

Thomas Rast <trast@inf.ethz.ch> writes:

> Michael Haggerty <mhagger@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
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@thomasrast.ch