3 ms·

> I personally never use rebase Probably a lot of that is because it is painful. When it becomes a no-op, suddenly a lot of things become easy to do. Do you e

> I personally never use rebase Probably a lot of that is because it is painful. When it becomes a no-op, suddenly a lot of things become easy to do. Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard. Do you ever want to maintain a linear chain of branches? Branch A needs to be merged before Branch B needs to be merged before Branch C. It’s a massive pain with git, especially if you need to change Branch A. It’s a no-op in jj. There are a ton of straightforward and useful workflows in git that are just completely impractical.

Izkata 2y ago
> Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard. Also unnecessary, "git rebase -i" has an "edit" command that pauses the rebase at that commit to let you do whatever.
- Valodim 2y ago
  This is roughly the reaction I meant going into this discussion :) The rebase next level part is not about using git rebase in the right way, it's about every command including status sometimes doing 15 rebases without even mentioning it.
- steveklabnik 2y ago
  What jj does is not require you to pause. It’s fine with leaving stuff in a conflicted state, letting you do whatever you want as a next step. That may be resolving the rebase, but maybe you didn’t realize you were gonna have a conflict and want to get something else done real quickly. In-memory, always succeeding rebases are just really nice.
  - stouset 2y ago
    And also you can just… edit a commit. It’s not some special side effect of a certain flag to a different command. You can just say “gosh I really wish I’d made some changes here” and either move changes in, or just jump in and live-edit it directly. It’s really a completely different way of thinking, but shockingly, one that essentially directly maps to what your actual intentions are.
bayindirh 2y ago
No, not because it's painful, I just don't need it. > Do you ever want to go back and edit a previous unpublished commit? Honestly, no? I plan what I'm going to change, do it, commit it, and if I messed up, I don't hide it, just fix it and write "I messed up X in $HASH. This fixes that". > Do you ever want to maintain a linear chain of branches? No, I always keep a single thing moving at one time. If the project is big, I use a branch per feature, if it's a smaller branch, there's a development branch. That's all. I have a habit of designing before touching code, so I always move in well planned moves. It's not like that because I'm afraid of rebase. It's just how I design/implement software. Yes, it's generally not a group work, but I do what I do, and it works. > There are a ton of straightforward and useful workflows in git that are just completely impractical. That's fine. I don't claim otherwise. I just don't do to prefer source code / branch acrobatics. I'd love to share a seven year development tree to show how I work, but unfortunately that repo is not meant to be open, at least for now.

Izkata 2y ago

> Do you ever want to go back and edit a previous unpublished commit? Yes fixups exist, but that’s a band aid over the fact that editing a previous one is annoying and hard. Also unnecessary, "git rebase -i" has an "edit" command that pauses the rebase at that commit to let you do whatever.

Valodim 2y ago
This is roughly the reaction I meant going into this discussion :) The rebase next level part is not about using git rebase in the right way, it's about every command including status sometimes doing 15 rebases without even mentioning it.
steveklabnik 2y ago
What jj does is not require you to pause. It’s fine with leaving stuff in a conflicted state, letting you do whatever you want as a next step. That may be resolving the rebase, but maybe you didn’t realize you were gonna have a conflict and want to get something else done real quickly. In-memory, always succeeding rebases are just really nice.
- stouset 2y ago
  And also you can just… edit a commit. It’s not some special side effect of a certain flag to a different command. You can just say “gosh I really wish I’d made some changes here” and either move changes in, or just jump in and live-edit it directly. It’s really a completely different way of thinking, but shockingly, one that essentially directly maps to what your actual intentions are.

bayindirh 2y ago

No, not because it's painful, I just don't need it. > Do you ever want to go back and edit a previous unpublished commit? Honestly, no? I plan what I'm going to change, do it, commit it, and if I messed up, I don't hide it, just fix it and write "I messed up X in $HASH. This fixes that". > Do you ever want to maintain a linear chain of branches? No, I always keep a single thing moving at one time. If the project is big, I use a branch per feature, if it's a smaller branch, there's a development branch. That's all. I have a habit of designing before touching code, so I always move in well planned moves. It's not like that because I'm afraid of rebase. It's just how I design/implement software. Yes, it's generally not a group work, but I do what I do, and it works. > There are a ton of straightforward and useful workflows in git that are just completely impractical. That's fine. I don't claim otherwise. I just don't do to prefer source code / branch acrobatics. I'd love to share a seven year development tree to show how I work, but unfortunately that repo is not meant to be open, at least for now.