3 ms·
stash is supposed to be a short term thing, if you are doing the whole "apply/verify/list/drop" cycle, named branches are a superior approach. I find the power
by theamk 6y ago
stash is supposed to be a short term thing, if you are doing the whole "apply/verify/list/drop" cycle, named branches are a superior approach.
I find the power of the stash in "stash pop", which applies, and drops if there were no conflicts:
git stash push
git checkout -b newbranch upstream/right
git stash pop
and yeah, if your keep your branches long-term stash is not a good solution for this.
- wutbrodo 6y agoYea, exactly. The author's git workflow is eerily like the one I've converged too over a decade, but "never stash" (without acknowledging the existence of the quick stash use-case) is wrong enough that it's enough to give me pause about his general competency with git (or more likely and more charitably, that he just didn't put too much effort into that section of the article). The advantage of stash is that it's quicker and easier than creating and cleaning up branches. If you're naming stashes and keeping them longterm, then you're basically using them like branches and should consider what benefit you're getting from adding a separate workflow.
- MaulingMonkey 6y agoA lot of my "short term" things end up being multi-month distractions or worse - and the verify/list/drop cycle is reflexive paranoia after one too many botched merges lost data. Sometimes those botched mergeds have been due to my own incompetence, sometimes due to P4Merge literally corrupting my file and saving out something totally different than what I'd resolved, and sometimes due to unexpected refactoring between branches causing enough of a mess that reapplying the work by hand is easier than "resolving" the conflict.