Michael Haggerty <mhag...@alum.mit.edu> writes:

> On 07/09/2013 02:08 PM, Thomas Rast wrote:
>> Michael Haggerty <mhag...@alum.mit.edu> writes:
>>> Since you've already implemented a way to merge into the index (even an
>>> alternative index) without touching the working copy, I'll just cross my
>>> fingers and hope for the appearance of an option that makes merge leave
>>> HEAD, MERGE_HEAD, etc. untouched.
>> The most annoying part is probably where to put the output, since
>> merging is more or less defined to do one of:
>> - update HEAD and return 0
>> - update MERGE_HEAD and return 1
> I don't understand what you mean here. [...]

I was simply trying to describe what the status quo is, as a basis for
the next paragraph.  Does that clarify it?

>> I'm not sure how much flexibility is worth having.  Would it be
>> sufficient if you had an option, e.g. -Xresult-ref=refs/heads/foo, that
>> changes it to:
>> - update refs/heads/foo and return 0
>> - return 1, not updating any refs
>> That would mean that it would only work for noninteractive use.  In the
>> conflicting case, the driving script would need to remember what it
>> wanted to merge so as have the information when finally committing.
> That would be fine with me.

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.

Thomas Rast
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

Reply via email to