=== re: ===
Have pull detect this case and stash if so, with a message to the user
to pop the stash after they have committed the merge results? Or would
it make more sense to do it in merge? Maybe a pre-merge hook?
===end===
I've wondered a couple times how to abort a merge. I ended up just deleting all the funny files. Did I understand correctly that "git reset --merge" is a new feature?
Perhaps best practice, if I have stuff I've added but don't want to commit yet (why? add the files as you touch them so you don't forget? keep them from getting confused with the ones you intend to not add at all?), or changes I've not added yet,
would be to "stash" first, do the pull, then "stash apply".
With the existence of a clean way to abort the merge, I could just pull with the assumption that there will be no conflicts, then abort, stash, pull again if needed. Without the ability to abort the merge, the stakes are high to risk the assumption that all will go well. So, always stash first.
Assuming that is correct, it inspires this behavior:
Automatically stash and apply first, then merge.
If merge is clean, delete the stash.
If intervention is needed, I have the stash state to reset to if necessary, and to show me what was already changed if I need to know that.
But I'm still mixed up. What is the requirement here? I can understand the need to pull to keep current but not publish my own changes yet. But why is it necessary to preserve the fact that _some_ (not all) of the changes are in the index?
--John
��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
