On 04/21/2015 12:11 AM, Junio C Hamano wrote:
But the said file, if it had conflicted, would have had only the
conflicted higher stage entries in the index, no? That is, the
failed merge wouldn't have touched the index for the path if it
already had changes there in the first place.
I'm not really sure what "higher stage entries" are, but this scenario
seems to be a counter-example:
git init
echo "aaaaa" > test
git add test
git commit -m "first"
echo "aaa" > test
git stash save
echo "bbbbb" > test
git add test
git stash pop
Either that, or 'git stash pop' was a destructive operation, and ate the
staged changes.
If you want to keep them then you do not have to reset, but your
question is about resolving conflict only in the working tree and
leave the index clean, so I do not think "git reset -- $path" would
not lose anything "irreversibly".
Rather, I'd prefer to leave the index as-is, if it makes sense.
Basically, this is about tool automation, see the context here:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20292
--
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
