Re: [RFC 1/3] sequencer: Signal failed ff as an aborted, not a conflicted merge

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 10, 2014, 19:17 UTC
Message-ID: <xmqqvbs88tht.fsf@gitster.dls.corp.google.com>
In-Reply-To: <539753C3.2020101@cisco.com>

Phil Hord <hordp@cisco.com> writes:

Show 6 quoted lines

>> In any case, I agree that exiting with 1 that signals "failed with
>> conflict" can be confusing to the caller.  Can we have a test to
>> demonstrate when this fix matters?
>
> I think you are asking for a test and not for clarification.  But a test
> was provided in 3/3 in this series.  Was it not related directly enough?

X-< Somehow I missed the "3" in "1/3" above and did not look beyond this first patch.

Show 5 quoted lines

> For clarification, this tri-state return value matters when the caller
> is planning to do some cleanup and needs to handle the fallout
> correctly.  Maybe changing this return value is not the correct way
> forward, though.  It might be better if the caller could examine the
> result after-the-fact instead.

I am not sure about that. For merge strategies "exit with 1 iff you left the conflict in the index" is the contract between "git merge" frontend and the strategies backend; if a similar contract is needed between the sequencer and its users, it is good to follow the same pattern for consistency. The resulting index and/or the working tree may or may not match the contents recorded in the HEAD commit but without the backend telling the caller, the caller cannot tell if the difference was from before the operation or created by the operation.