Re: What's cooking in git.git (Apr 2016, #06; Thu, 21)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 22, 2016, 14:04 UTC
Message-ID: <alpine.DEB.2.20.1604221601270.6812@virtualbox>
In-Reply-To: <xmqqy486r4co.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On Thu, 21 Apr 2016, Junio C Hamano wrote:

Show 21 quoted lines

> * js/am-3-merge-recursive-direct (2015-10-12) 2 commits
>  - am: make a direct call to merge_recursive
>  - merge_recursive_options: introduce the "gently" flag
> 
>  The merge_recursive_generic() function has been made a bit safer to
>  call from inside a process.  "git am -3" was taught to make a direct
>  call to the function when falling back to three-way merge.
> 
>  Being able to make a direct call would be good in general, but as a
>  performance thing, the change needs to be backed up by numbers.
> 
>  Needs review.
> 
>  I haven't gone through the "gently" change with fine toothed comb;
>  I can see that the change avoids calling die(), but I haven't made
>  sure that the program states (e.g. what's in the in-core index) are
>  adjusted sensibly when it returns to the caller instead of dying,
>  or the codepaths that used to die() are free of resource leaks.
>  The original code certainly did not care the program states at the
>  point of dying exactly because it knew it is going to exit, but now
>  they have to care, and they need to be audited.

I actually found a bug in my implementation, when I needed it in my rebase--helper branch: at some point, we should return 128 instead of -1, to indicate that we won't even start merging (because we would overwrite untracked files).

I hope to find the time next week to go through the entire call graph and verify that we are only die()ing in case if really critical errors (such as out-of-memory, in which case we traditionally just die).

Ciao, Dscho