Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> On 07/09/2013 02:08 PM, Thomas Rast wrote:
>> Michael Haggerty <mhagger@xxxxxxxxxxxx> 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
trast@{inf,student}.ethz.ch
--
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