4 ms·
Totally agree! When I work in this way I'll rebase all the nits up top where possible. I like to try to get the history to tell a sort of 'story of development
by tyleo 3y ago
Totally agree!
When I work in this way I'll rebase all the nits up top where possible. I like to try to get the history to tell a sort of 'story of development'. Though this can be time consuming so I wouldn't fret about it if it becomes burdensome. When it works, this has a nice impact of dividing the PR into:
1. Here is what we were trying to do.
2. Here is all the stuff we also cleaned up which is somewhat unrelated but in the hot path of these other changes.
- tome 3y agoThis is great to hear. It's exactly how I work as well, and I find it very effective. In case anyone's interested I published a small shell script for splitting off smaller commits out of bigger ones. It aids my workflow a lot. https://github.com/tomjaguarpaw/git-split/ https://github.com/tomjaguarpaw/git-split/
- jonhohle 3y agoThat looks really nice. I like the idea of a sub-shell where all the work is either committed or reverted. I would like to see something like a “workspace” where even untracked files can be shelved in a named space and returned (or picked) after some operation. I could imagine a tool like yours where a snapshot of the current working set is made and a subshell with a clean repo created. Do some work, commit or not, and when the shell is exited, everything is back to the way it was (garbage and all).