Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > The return value of do_recursive_merge() may be positive (indicating merge > conflicts), so let's OR later error conditions so as not to overwrite them > with 0. Are the untold assumptions as follows? - The caller wants to act on positive (not quite an error), zero (success) or negative (error); - do_recursive_merge() can return positive (success with reservation), zero or negative, and the call to it would return immediately if it got negative; - all other functions that come later may return either zero or negative, and never positive; - Hence the caller can be assured that "res" being positive can only mean do_recursive_merge() succeeded with reservation and everything else succeeded. This can be extended if the only thing the caller cares about is positive/zero/negative and it does not care what exact positive value it gets--in such a case, we can loosen the condition on the return values from other functions whose return values are OR'ed together; they may also return positive to signal the same "not quite an error", i.e. updating the latter two points to - all other functions that come later can return positive (success with reservation), zero or negative. - Hence the caller can be assured that "res" being positive can mean nobody failed with negative return, but it is not an unconditional success, which is signalled by value "res" being 0. I cannot quite tell which is the case, especially what is planned in the future. The proposed log message is a good place to explain the future course this code will take. > This is not yet a problem, but preparing for the patches to come: we will > teach the sequencer to do rebase -i's job. Thanks.