4 ms·

Git rebase is, frankly, a massive pain in the ass. It's worth doing if you care about it. I used a rebase-heavy workflow for a decade and a half. But having to

Git rebase is, frankly, a massive pain in the ass. It's worth doing if you care about it. I used a rebase-heavy workflow for a decade and a half. But having to drop everything you're in the middle of to fix an endless list of rebase conflicts sucks. And it sucks even worse when you screw up the conflict resolution halfway through and have to start over from scratch. Rebases also don't play nicely with stacked branches. Branches based off your original changes don't get rewritten to be on top of the rebased change, so now multiple rebases are in your future. It turns out that basically none of the rebase friction most people experience is necessary in practice. Rebases can be automatic, implicit, and conflicts can be fixed at your leisure and in whatever order that you feel is best. jj also has a ton of other powers, but you asked about rebase :)

1718627440 1y ago
> having to drop everything you're in the middle of to fix an endless list of rebase conflicts sucks You can use git commit --fixup to record what you want to change in an earlier commit. > start over from scratch rerere > Branches based off your original changes don't get rewritten As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto.
- baq 1y ago
  > You can use git commit --fixup to record what you want to change in an earlier commit. jj just does it correctly by default. > rerere jj just does it correctly by default. > As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto. jj just does it correctly by default. defaults matter.
  - 1718627440 1y ago
    >> git commit --fixup > jj just does it correctly by default. JJ adds changes to random old commits instead of the newest one? Yikes. > rerere by default Takes space and time. > --update-refs by default Maybe sensible, don't need it most of the time.
    - baq 1y ago
      > JJ adds changes to random old commits instead of the newest one? Yikes. jj adds changes to the current commit, which is the staging area, which is the index, which is the working copy. I get you don't like it, no need to be an ass about it, but denying that it works is just that, denial. > > rerere by default > Takes space and time. doesn't take my time. I'll take it. > > --update-refs by default > Maybe sensible, don't need it most of the time. No reason to waste time thinking when it's needed.
      - 1718627440 1y ago
        > no need to be an ass about it That wasn't what I meant, git --fixup is for changing earlier commits, you answered as if it didn't that's what I wanted to point out. (I tried to be sarcastic, because it was obvious that you didn't mean that.) >> Maybe sensible, don't need it most of the time. As in I want the opposite behaviour most of the time. That's why that is the default.
- stouset 1y ago
  Yes, there are a million weird band-aids that git has grown over time. Some of them work better than others. Or we could just not have the problems to begin with.
  - 1718627440 1y ago
    There are some later additions like git switch, but git rebase and git commit ain't one.
    - stouset 1y ago
      `--update-refs` was added in 2.38, in 2022. `--fixup` was added in 1.7.3. Like I said, git has grown additional features and workarounds. Knowing all of them is a lot of work.

1718627440 1y ago

> having to drop everything you're in the middle of to fix an endless list of rebase conflicts sucks You can use git commit --fixup to record what you want to change in an earlier commit. > start over from scratch rerere > Branches based off your original changes don't get rewritten As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto.

baq 1y ago
> You can use git commit --fixup to record what you want to change in an earlier commit. jj just does it correctly by default. > rerere jj just does it correctly by default. > As written elsewhere: git rebase --update-refs. If you want to do it manually git rebase --onto. jj just does it correctly by default. defaults matter.
- 1718627440 1y ago
  >> git commit --fixup > jj just does it correctly by default. JJ adds changes to random old commits instead of the newest one? Yikes. > rerere by default Takes space and time. > --update-refs by default Maybe sensible, don't need it most of the time.
  - baq 1y ago
    > JJ adds changes to random old commits instead of the newest one? Yikes. jj adds changes to the current commit, which is the staging area, which is the index, which is the working copy. I get you don't like it, no need to be an ass about it, but denying that it works is just that, denial. > > rerere by default > Takes space and time. doesn't take my time. I'll take it. > > --update-refs by default > Maybe sensible, don't need it most of the time. No reason to waste time thinking when it's needed.
    - 1718627440 1y ago
      > no need to be an ass about it That wasn't what I meant, git --fixup is for changing earlier commits, you answered as if it didn't that's what I wanted to point out. (I tried to be sarcastic, because it was obvious that you didn't mean that.) >> Maybe sensible, don't need it most of the time. As in I want the opposite behaviour most of the time. That's why that is the default.
stouset 1y ago
Yes, there are a million weird band-aids that git has grown over time. Some of them work better than others. Or we could just not have the problems to begin with.
- 1718627440 1y ago
  There are some later additions like git switch, but git rebase and git commit ain't one.
  - stouset 1y ago
    `--update-refs` was added in 2.38, in 2022. `--fixup` was added in 1.7.3. Like I said, git has grown additional features and workarounds. Knowing all of them is a lot of work.