Re: [PATCH] read-cache.c: Ensure unmerged entries are removed

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 15, 2014, 21:45 UTC
Message-ID: <xmqqmwb5zatx.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAPuZ2NFJiUt1p_OfefswS8O8_BA6mQy=PStmYyNw=ABZCOQprQ@mail.gmail.com>

Jaime Soriano Pastor <jsorianopastor@gmail.com> writes:

Show 7 quoted lines

> On Thu, Aug 14, 2014 at 1:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Being a conservative, I'd rather avoid doing any magic during
>> read_cache() time. "ls-files -s" for example should show the four
>> stages so that the "broken" state can be inspected.
>>
> Well, only read_cache_unmerged() is modified in the sent patch, so no
> magic is done in read_cache(), I'd also avoid changes there.

Ahh, I must have overlooked that; changes being only in _unmerged() variant makes me feel much better, and it probably would make much of ...

>> Yes, it would be more work,...

... moot, hopefully ;-)

> git reset will clean the index anyway if the loop finishes, would it
> be ok?

Surely.

> git merge is also affected by the loop in read_cache_unmerged(), but
> any of the solutions would be enough for it as only by finishing the
> loop with unmerged entries it will die without commiting the cache to
> the index file.

Again, true. The mergy operations want to start from a clean slate and they call _unmerged() variant primarily to learn that there were unmerged entries in the index, only to abort the operation in that case, so a change to _unmerged() variant should be safe for them.

I'll take another look at your patch later, but not before the 2.1 final, and by that time you may already have sent a reroll ;-)

Thanks.