I've got used to a slight variant: staging and stashing my latest changes, pulling (with no merge, since changes are gone) and reapplying the stash. Repeatable until I'm ready to make a commit and push it.
Not really, I only have a trivial shell script to pull from about 160 mostly quiescent repositories.
When a pull fails, I use SourceTree to review modified files (which, for technical reasons, are mostly spurious tool-made harmless changes that should be discarded but are usually included in commits and conflicting).
Discarding, staging and stashing files and then applying a stash are particularly convenient operations with the SourceTree client (much better than merging or rebasing), and avoiding extra commits is a major advantage.
7 comments
[ 3.9 ms ] story [ 16.9 ms ] threadThis is it. This is whole article.
When a pull fails, I use SourceTree to review modified files (which, for technical reasons, are mostly spurious tool-made harmless changes that should be discarded but are usually included in commits and conflicting).
Discarding, staging and stashing files and then applying a stash are particularly convenient operations with the SourceTree client (much better than merging or rebasing), and avoiding extra commits is a major advantage.