Re: [PATCH v10 33/36] merge-recursive: fix was_tracked() to quit lying with some renamed paths

On Fri, Apr 20, 2018 at 5:23 AM, SZEDER Gábor wrote: > This patch causes memory corruption when the split index feature is in > use, making several tests fail. Now, while the split index feature > sure has its own set of problems, AFAIK those are not that bad to > cause

Re: [PATCH v10 33/36] merge-recursive: fix was_tracked() to quit lying with some renamed paths

> In commit aacb82de3ff8 ("merge-recursive: Split was_tracked() out of > would_lose_untracked()", 2011-08-11), was_tracked() was split out of > would_lose_untracked() with the intent to provide a function that could > answer whether a path was tracked in the index before the merge. Sadly, > it

Re: [PATCH v10 33/36] merge-recursive: fix was_tracked() to quit lying with some renamed paths

On Thu, Apr 19, 2018 at 1:39 PM, Martin Ågren wrote: > On 19 April 2018 at 19:58, Elijah Newren wrote: >> + /* Free the extra index left from git_merge_trees() */ >> + /* >> +* FIXME: Need to also data allocated by >>

Re: [PATCH v10 33/36] merge-recursive: fix was_tracked() to quit lying with some renamed paths

On 19 April 2018 at 19:58, Elijah Newren wrote: > + /* Free the extra index left from git_merge_trees() */ > + /* > +* FIXME: Need to also data allocated by > setup_unpack_trees_porcelain() > +* tucked away in o->unpack_opts.msgs, but the problem is

[PATCH v10 33/36] merge-recursive: fix was_tracked() to quit lying with some renamed paths

In commit aacb82de3ff8 ("merge-recursive: Split was_tracked() out of would_lose_untracked()", 2011-08-11), was_tracked() was split out of would_lose_untracked() with the intent to provide a function that could answer whether a path was tracked in the index before the merge. Sadly, it instead