3 ms·
Stashes should cover your first scenario; put those changes (both staged and unstaged, optionally also untracked files) in a bag and re-apply them when you are
by rzzzt 9y ago
Stashes should cover your first scenario; put those changes (both staged and unstaged, optionally also untracked files) in a bag and re-apply them when you are back from your short expedition: https://git-scm.com/docs/git-stash https://git-scm.com/docs/git-stash
To clean up outgoing changes, you can run an interactive rebase of the current branch onto its remote tracking counterpart. This will list all affected commits in a text editor, and allows you to reorder, squash, change the commit message or the content, much like how you describe it works in hg: https://git-scm.com/docs/git-rebase#_interactive_mode https://git-scm.com/docs/git-rebase#_interactive_mode
- bringtheaction 9y agoProblem with stashing is that you then need to redo the work of staging afterward.
- maccam94 9y agoyou can --keep-index to avoid stashing it, and then make an additional stash. If you have modifications within the same file it'll complain about conflicts though, so on the second sash you'll have to `git stash show -p | git apply -R` and then drop the stash, which is super clunky.
- zaarn 9y agoYou only need to git stash pop and the staging area is back as it where, there is no need to redo the work of staging.
- __david__ 9y agoStashing saves/restores the staging area so you shouldn't need to redo anything.