3 ms·

I use it all the time! I do really messy stuff locally, and then I rebase to organize it into commits that tell a story, which makes it easier for reviewers (an

I use it all the time! I do really messy stuff locally, and then I rebase to organize it into commits that tell a story, which makes it easier for reviewers (and archaeologists, such as me in 5 months) to understand. Most common pattern: Commit 1 does a preliminary refactoring, commit 2 does the actual feature change. If you squash them together, the changes are harder to understand. But in the editing process, I often end up doing additional refactoring before I'm done with the feature work, so I use rebase -i to reorder and squash the changes appropriately. (I also run tests at both commits to make sure that my story is true, heh.) (This way, you can even do things like later revert the feature change without undoing the refactoring work.)

lmm 7y ago
> I do really messy stuff locally, and then I rebase to organize it into commits that tell a story, which makes it easier for reviewers (and archaeologists, such as me in 5 months) to understand. So people review commit-by-commit? What review tool are you using for that? Github and Bitbucket very much nudge you towards reviewing the PR's diff as a whole, IME. And do you find that you actually look at the history in 5 months' time? People worry about this a lot but I find it's pretty rare to actually need more history than what's in the diffs. > But in the editing process, I often end up doing additional refactoring before I'm done with the feature work, so I use rebase -i to reorder and squash the changes appropriately. (I also run tests at both commits to make sure that my story is true, heh.) I do that but without the reordering - it just seems like a lot of overhead (and lots of potential for conflicts since the refactoring will almost necessarily be in the same code area as the feature work) plus running the build/tests again etc. > (This way, you can even do things like later revert the feature change without undoing the refactoring work.) You can do that either way, though I guess if all the refactoring commits were before the feature commits then that means fewer conflicts (though you still have to worry about subsequent refactorings in the same area). Is that something that happens often?
- dharmab 7y ago
  > Github and Bitbucket very much nudge you towards reviewing the PR's diff as a whole, IME. That's if you're using the merge or squash options. There's an enforceable rebase option in GitHub which preserves the original commits. > And do you find that you actually look at the history in 5 months' time? I often go back 2-3 years to do archaeology on code written by people who are no longer in the org.
  - lmm 7y ago
    > That's if you're using the merge or squash options. There's an enforceable rebase option in GitHub which preserves the original commits. A rebase by definition doesn't preserve the original commits (whereas a merge does). But I'm talking about what the workflow for reviewing the PR looks like, before you approve it for merge (in any form) - that's the usual time for review, no?

lmm 7y ago

> I do really messy stuff locally, and then I rebase to organize it into commits that tell a story, which makes it easier for reviewers (and archaeologists, such as me in 5 months) to understand. So people review commit-by-commit? What review tool are you using for that? Github and Bitbucket very much nudge you towards reviewing the PR's diff as a whole, IME. And do you find that you actually look at the history in 5 months' time? People worry about this a lot but I find it's pretty rare to actually need more history than what's in the diffs. > But in the editing process, I often end up doing additional refactoring before I'm done with the feature work, so I use rebase -i to reorder and squash the changes appropriately. (I also run tests at both commits to make sure that my story is true, heh.) I do that but without the reordering - it just seems like a lot of overhead (and lots of potential for conflicts since the refactoring will almost necessarily be in the same code area as the feature work) plus running the build/tests again etc. > (This way, you can even do things like later revert the feature change without undoing the refactoring work.) You can do that either way, though I guess if all the refactoring commits were before the feature commits then that means fewer conflicts (though you still have to worry about subsequent refactorings in the same area). Is that something that happens often?

dharmab 7y ago
> Github and Bitbucket very much nudge you towards reviewing the PR's diff as a whole, IME. That's if you're using the merge or squash options. There's an enforceable rebase option in GitHub which preserves the original commits. > And do you find that you actually look at the history in 5 months' time? I often go back 2-3 years to do archaeology on code written by people who are no longer in the org.
- lmm 7y ago
  > That's if you're using the merge or squash options. There's an enforceable rebase option in GitHub which preserves the original commits. A rebase by definition doesn't preserve the original commits (whereas a merge does). But I'm talking about what the workflow for reviewing the PR looks like, before you approve it for merge (in any form) - that's the usual time for review, no?