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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

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

> * 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