I typically use this command during big refactoring when I have plenty of modified files in my working copy and I start a "small subtask" and don't want to spend time using
rebase -i to isolate my small changes amongst my whole refactoring.
So I :
git wip(see https://gist.github.com/dgageot/492227) to make a commit with my current refactoring state
- make my small changes, then commit it
git flip-lastto "store" this small commit before my wip refactoring
git unwip(see https://gist.github.com/dgageot/492227) to come back to my initial state
Mainly for 2 reasons :
- Sometimes, we want to flip 2 commits "after" the commit has been performed .. so the commit cannot be "introduced" between
- Sometimes, we want to test our small commit with our work in progress. Using
stashwill not allow this.
Example : renaming a function used at 10 location calls. Let's consider 1 location call has been added during our "work in progress".
If I use
git stash, then my function rename will be applied at only 9 locations. I will have to ensure that my 10th location is taken into consideration when I will
git stash pop(on dynamic language, I can miss it)
If I use
git flip-last, I will perform the rename after my
wipcommit, so it will be impacted on the 10th location. I will have a conflict during
flip-last(because the 10th location will not exist in the codebase) but this won't be a complicated conflict to solve at that time.
Yes I could
git commit +
git rebase -i HEAD^^ + swap latest 2 commit in editor and validate +
My concern here is I don't want to spend 4-5s to open editor and swap 2 first lines : this will fluidize my workflow and will encourage me to make those small commits more frequently