Jaime Soriano Pastor <jsorianopastor@xxxxxxxxx> writes: > On Thu, Aug 14, 2014 at 1:04 AM, Junio C Hamano <gitster@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html