2 ms·

Yeah, that’s my method as well. Start big and even fix nits along the way. Anything that’s in the way is fair game as long as all of the tests are passing. As f

Yeah, that’s my method as well. Start big and even fix nits along the way. Anything that’s in the way is fair game as long as all of the tests are passing. As fundamental, atomic changes are discovered, peel those off into separate commits and PRs justifying their current and future benefit. Rebase those changes on the big branch and repeat until all the changes in the big branch are merged. I’ve found that having a lot of small commits in my dev branch also helps makes rebasing easier. When there are conflicts, it’s easier to reason about what atomic set of changes they might affect than the whole wad. It also makes peeling off those changes into their own branch easier if things get to hairy.

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 ago
  This 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 ago
    That 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).

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 ago
This 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 ago
  That 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).