Jaime Soriano Pastor <jsorianopas...@gmail.com> writes:
> On Thu, Aug 14, 2014 at 1:04 AM, Junio C Hamano <gits...@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
>> Yes, it would be more work,...
... moot, hopefully ;-)
> git reset will clean the index anyway if the loop finishes, would it
> be ok?
> 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 ;-)
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html