From: Thomas Rast Date: Tue, 09 Jul 2013 20:01:06 GMT Subject: Re: [PATCH 0/3] merge -Xindex-only Message-ID: <87wqozbj0d.fsf@hexa.v.cablecom.net> In-Reply-To: <51DC66A5.80500@alum.mit.edu> Michael Haggerty writes: > On 07/09/2013 02:08 PM, Thomas Rast wrote: >> Michael Haggerty 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