On 2018-03-11 11:52 AM, Nick Østergaard wrote:
That sounds a bit risky. Using the stash and popping can make you lose your local changes if you decide to abort a potential merge conflict. IIRC. Commiting changes are generally safer. Or you could use git stash apply instead.

The risk of lose comes from how you try to resolve the merge conflict that arises from trying to apply the stashed changes whether you use pop or apply. When applying stashed changes triggers a merge conflict the stashed changes stay stashed. If you try to abort a merge git will say there is no merge in progress. If you tell git to reset the source tree it will tell you that there is a merge in progress so it won't reset the tree.

You then have code in a Heisenberg box situation. The code is simultaneously in the middle of a merge and not in the middle of a merge. The only really safe way to protect against potential merge conflict when you go to apply the stashed changes is to save the output of a "git diff" before you stash changes not yet commited.

Subversion was much better about dealing with conflicts. It would tell you there is a conflict but apply changes to files so you could see the before and after. You then had to manually fix the conflicts. No loss of changes and no being unable to access what the changes were. I've had no success trying to save stashed changes as a file so I could manually fix a merge conflict.



http://www.ve3syb.ca/            |"Nerds make the shiny things that distract
https://patreon.html/KevinCozens | the mouth-breathers, and that's why we're
                                 | powerful"
Owner of Elecraft K2 #2172       |
#include <disclaimer/favourite>  |             --Chris Hardwick

Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to