4 ms·

> do people actually find stashing easier than branching? Branching wouldn't be enough, you'd need to commit your entire working copy to approximate a stash.

by pkamb 10y ago

> do people actually find stashing easier than branching? Branching wouldn't be enough, you'd need to commit your entire working copy to approximate a stash. I'd say it's generally a bug-prone mistake any time you commit your entire working copy (rather than staging lines/hunks on a one-commit-per-feature/bug basis). So branching and committing and pushing into a `backupForTomorrow` branch is fine, but you have to be sure to get rid of that commit via something like a mixed reset when you start working on it again. If that temporary backup commit somehow stays around in the final feature branch, a stash would be much preferred.

randallsquared 10y ago
Committing your entire working copy to a separate branch can work just like a safe stash: $ git branch master * cool-feature-1 $ git checkout -b stash-2016.09.30T01.10 $ git add -A; git commit -m "stashing WIP for later; maybe add some commentary to remind myself what I'm doing" $ git branch master cool-feature-1 * stash-2016.09.30T01.10 $ git checkout master $ git branch * master cool-feature-1 stash-2016.09.30T01.10 # do other things # later... $ git checkout cool-feature-1 $ git merge --no-commit --no-ff stash-2016.09.30T01.10 Automatic merge went well; stopped before committing as requested $ git reset $ git status On branch cool-feature-1 Untracked files: ... And now your old WIP is back, ready to keep working, and in the meantime you could have pushed up your "stash" to a remote and grabbed it back. There might be something terribly wrong with this, but if there's not, then I don't understand why git stash doesn't do something similar to this by default.
dahart 10y ago
> Branching wouldn't be enough, you'd need to commit ... Yes, you're right. I mentioned both committing I branching. I imagine commits only as the alternative to a single stash/pop, and commits & branching as the alternative to using multiple stashes. > I'd say it's generally a bug-prone mistake any time you commit your entire working copy The workflow I'd use instead of stash is to commit, do things, then reset --soft. Exact same effect as stash, except that it's less bug-prone, there's an easier & safer recovery mechanism in case of problems. > If that temporary backup commit somehow stays around in the final feature branch, a stash would be much preferred. You're comparing making a small mess to losing work. Your opinion is your own, I'm not here to argue, but in my book the downside of losing work while using a revision control system is much larger than the downside of accidentally preserving imperfect commit refactoring. You're preferring something superficially nice over the actual safety mechanisms that is git's sole purpose.
- pkamb 10y ago
  I use stash in one of the two workflows below, neither of which have ever caused problems. Stash's advantage is in not needing to create branches, commit, or un-commit the code back into your working copy. Very quick, and I've never had problems. - Paired operations `git stash` / `git stash pop` to quickly get rid of everything then reapply it a few minutes later. - Stash as a "I probably don't want this code, but may as well keep a stashed copy" alternative to a hard reset. These stashes all then show up in my SourceTree sidebar to easily peruse or apply if needed (or copy/paste individual lines). Not a big deal if lost. If I'm actually backing up code that I'll likely use, or need a remote backup of my current working copy to protect against laptop theft or HDD failure, I'll branch/commit/push the backup. Then use a mixed reset later to get rid of the commit itself and return everything to the working copy.
- convolvatron 10y ago
  there's no sense arguing. to many git users I have met, the software isn't the product, the git repository is. I have met someone who will happily spend an entire day refactoring all the commit boundaries by teasing apart and combining diffs so that they match some retroactive narrative that looks prettier. you must be one of those squash haters

by pkamb 10y ago

randallsquared 10y ago

Committing your entire working copy to a separate branch can work just like a safe stash: $ git branch master * cool-feature-1 $ git checkout -b stash-2016.09.30T01.10 $ git add -A; git commit -m "stashing WIP for later; maybe add some commentary to remind myself what I'm doing" $ git branch master cool-feature-1 * stash-2016.09.30T01.10 $ git checkout master $ git branch * master cool-feature-1 stash-2016.09.30T01.10 # do other things # later... $ git checkout cool-feature-1 $ git merge --no-commit --no-ff stash-2016.09.30T01.10 Automatic merge went well; stopped before committing as requested $ git reset $ git status On branch cool-feature-1 Untracked files: ... And now your old WIP is back, ready to keep working, and in the meantime you could have pushed up your "stash" to a remote and grabbed it back. There might be something terribly wrong with this, but if there's not, then I don't understand why git stash doesn't do something similar to this by default.

dahart 10y ago

> Branching wouldn't be enough, you'd need to commit ... Yes, you're right. I mentioned both committing I branching. I imagine commits only as the alternative to a single stash/pop, and commits & branching as the alternative to using multiple stashes. > I'd say it's generally a bug-prone mistake any time you commit your entire working copy The workflow I'd use instead of stash is to commit, do things, then reset --soft. Exact same effect as stash, except that it's less bug-prone, there's an easier & safer recovery mechanism in case of problems. > If that temporary backup commit somehow stays around in the final feature branch, a stash would be much preferred. You're comparing making a small mess to losing work. Your opinion is your own, I'm not here to argue, but in my book the downside of losing work while using a revision control system is much larger than the downside of accidentally preserving imperfect commit refactoring. You're preferring something superficially nice over the actual safety mechanisms that is git's sole purpose.

pkamb 10y ago
I use stash in one of the two workflows below, neither of which have ever caused problems. Stash's advantage is in not needing to create branches, commit, or un-commit the code back into your working copy. Very quick, and I've never had problems. - Paired operations `git stash` / `git stash pop` to quickly get rid of everything then reapply it a few minutes later. - Stash as a "I probably don't want this code, but may as well keep a stashed copy" alternative to a hard reset. These stashes all then show up in my SourceTree sidebar to easily peruse or apply if needed (or copy/paste individual lines). Not a big deal if lost. If I'm actually backing up code that I'll likely use, or need a remote backup of my current working copy to protect against laptop theft or HDD failure, I'll branch/commit/push the backup. Then use a mixed reset later to get rid of the commit itself and return everything to the working copy.
convolvatron 10y ago
there's no sense arguing. to many git users I have met, the software isn't the product, the git repository is. I have met someone who will happily spend an entire day refactoring all the commit boundaries by teasing apart and combining diffs so that they match some retroactive narrative that looks prettier. you must be one of those squash haters