Jaime Soriano Pastor [off-list ref] writes:
On Thu, Aug 14, 2014 at 1:04 AM, Junio C Hamano [off-list ref] wrote:
quoted
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 ...
quoted
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.
I'd like to add some tests too for this, but I don't know how to
reproduce this state with git commands only, is there any way to add
entries to the index without checkings?
Or maybe it could be done by creating a "test-" command that adds the
entries to an index?
Thanks.
On Fri, Aug 15, 2014 at 11:45 PM, Junio C Hamano [off-list ref] wrote:
Jaime Soriano Pastor [off-list ref] writes:
quoted
On Thu, Aug 14, 2014 at 1:04 AM, Junio C Hamano [off-list ref] wrote:
quoted
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 ...
quoted
quoted
Yes, it would be more work,...
... moot, hopefully ;-)
quoted
git reset will clean the index anyway if the loop finishes, would it
be ok?
Surely.
quoted
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.
--
Jaime Soriano Pastor - Software Developer