3 ms·

I tried StGit recently, having used rebases for a while now. In practice, StGit operations are much more intuitive and easy to learn than rebasing. Conflicts ar

I tried StGit recently, having used rebases for a while now. In practice, StGit operations are much more intuitive and easy to learn than rebasing. Conflicts are much easier to track down and resolve compared to rebases. Personally, I find rebase operations so confusing that I often do multiple rebases on the same branch, a few operations at a time. It's easier for me to track down rebase conflicts that way. Rebases and merges use diffs behind the scenes, although git stores the commits as snapshots. There is always a conflict of the two mental models while rebasing. With StGit, it's explicitly just patches that you can inspect anytime. I assume that this is the reason why StGit operations make more sense than rebasing. Another important fact is that you don't need to wait till a feature-branch is complete to edit the history. With StGit, you can craft the ideal commit history along the way while you develop. I treat a stack of patches as multiple staging areas - each with specific purpose/feature and a predefined commit message. That way, you can develop code hunks in whatever order that makes sense, and then check them into (refresh the patch) the appropriate patch. It's even possible to edit or reorder these patches as we progress. Finally, the patches can be committed when the series of features are complete.

Quekid5 5y ago
> Another important fact is that you don't need to wait till a feature-branch is complete to edit the history. Why would you need to wait until it's complete? I don't feel any need to do that, and I'm constantly rebasing. I guess I must be something about your workflow here.
- sreevisakh 5y ago
  You miss the important point here. With rebases, crafting the history is a separate step that can be done only after you've made a few commits. Whether you do it continuously or as one batch makes no difference. With StGit, crafting the history can start at the very beginning of the feature development. It goes hand in hand with the development and can be refactored any time.
  - Quekid5 5y ago
    I'm afraid I still don't understand the workflow. I continually rebase my branch(es) on top of upstream. At any time, I can choose to consolidate a few of my WIP commits into a more (logically) cohesive commit and keep that around for further rebasing. I must be missing something here, but I'm not sure what. (If it helps understanding, we work with Gerrit which basically expects a 'list of patches' on top of the branch you want to commit your changes to. So that's already part of our mentality, but we just use plain git.)

Quekid5 5y ago

> Another important fact is that you don't need to wait till a feature-branch is complete to edit the history. Why would you need to wait until it's complete? I don't feel any need to do that, and I'm constantly rebasing. I guess I must be something about your workflow here.

sreevisakh 5y ago
You miss the important point here. With rebases, crafting the history is a separate step that can be done only after you've made a few commits. Whether you do it continuously or as one batch makes no difference. With StGit, crafting the history can start at the very beginning of the feature development. It goes hand in hand with the development and can be refactored any time.
- Quekid5 5y ago
  I'm afraid I still don't understand the workflow. I continually rebase my branch(es) on top of upstream. At any time, I can choose to consolidate a few of my WIP commits into a more (logically) cohesive commit and keep that around for further rebasing. I must be missing something here, but I'm not sure what. (If it helps understanding, we work with Gerrit which basically expects a 'list of patches' on top of the branch you want to commit your changes to. So that's already part of our mentality, but we just use plain git.)