4 ms·

Rebase is not harmful, but thanks for your link. There are quite some people that do not understand rebase, and this link helps to get a grasp of how people can

Rebase is not harmful, but thanks for your link. There are quite some people that do not understand rebase, and this link helps to get a grasp of how people can be confused. - in section 2.2, they think that in a feature branch only the latest commit counts. You should not just be interested in how the tip of your feature branch compares to the latest main, but also into the logical sequence of steps your feat branch builds up a feature. In a rebase model, every step of your feature can be compared to main. - in section 2.2, they conveniently omit what happens if you keep merging main into your feat branch. Your feat branch will show all useless commits telling you that "at this time, my feature diffed such and such from how main looked at at that time". "Oh, and here again a useless diff" "Oh and here again." "By the way, have a nice ball of diffs again". I don't fucking care. Why don't you just commit some info about the local weather at that time too or that your back was hurting on Wednesday 23th? - "Rebase encourages siloed development". That claim is just ridiculous. If you don't want people to take ownership of a feature, by all means, forego branches. If someone wants to work on my feature, then we just agree that the public feat branch is to be considered public history. When the work finishes, someone can take ownership, (possibly clean up the mess with rebasing) and get it into mainline by rebasing on top of main.

Nullabillity 2y ago
> You should not just be interested in how the tip of your feature branch compares to the latest main, but also into the logical sequence of steps your feat branch builds up a feature. Absolutely. And we should work to preserve that history. > In a rebase model, every step of your feature can be compared to main. No it can't (unless you just rebased again before running the diff). What it can be compared to is the closest common ancestor. git diff main...<commit> Which is exactly the same operation that you'd run in a merge workflow. > I don't fucking care. Why don't you just commit some info about the local weather at that time too or that your back was hurting on Wednesday 23th? But those events do go wrong, and having the context to understand what happened matters. Have you never had a mismerge or a merge conflict?
- exceptione 2y ago
  When you rebase your feat branch on top of latest main, all commits in your feat branch are YOUR commits. Each of those commits change something relative to main. Unless your are committing against yourself. So if you are confusing yourself (which should be rare because --I repeat-- all commits in your feat branch are your own commits) you have a good opportunity to clean up your own mess with git rebase -i.
- MrJohz 2y ago
  > But those events do go wrong, and having the context to understand what happened matters. Have you never had a mismerge or a merge conflict? Interestingly, despite being designed for a very rebase-heavy workflow, this is one of the things that Jujutsu does really well. You work with mutable changes rather than immutable commits, and each change references one or more commits that represent (roughly) the history of that change. So locally, you can see how a particular change has evolved, and you can easily undo some action or reference an older state while working on that change itself. Then when you push to a remote, the other people will only see the end-result of the change. Which is typically what I want: I want to retain a good sense of the history of the changes I'm working on at the moment, so I can go back and forth, try out different things, and not worry about losing any data or handling conflicts badly or whatever. But, when I've finished with my change, and it's been pushed, reviewed, etc, that history is now superfluous. I don't need to know that, while I was developing a feature, I accidentally committed a typo and then needed to make another commit to remove that typo. (And if there is information I do think is important, then I can create additional changes, or add the information to the commit message or the code itself as a comment.)
  - Nullabillity 2y ago
    > Interestingly, despite being designed for a very rebase-heavy workflow, this is one of the things that Jujutsu does really well. [snip] Then when you push to a remote, the other people will only see the end-result of the change. Yes, jujutsu is designed to hide (some of) the problems with rebase from yourself, while still inflicting them on everyone else . History for me, but not for thee! While also complicating the interaction model because you now have two sorts of history to contend with. Which actually sucks, because jj could have had been a much better alternative to Quilt for maintaining patch series over third-party software (á la Linux distributions) if it supported collaboration over the metahistory/oplog. > But, when I've finished with my change, and it's been pushed, reviewed, etc, that history is now superfluous. I don't need to know that, while I was developing a feature, I accidentally committed a typo and then needed to make another commit to remove that typo. This assumes that you'll actually find all the issues during the review. Do you also erase your history after every release?

Nullabillity 2y ago

> You should not just be interested in how the tip of your feature branch compares to the latest main, but also into the logical sequence of steps your feat branch builds up a feature. Absolutely. And we should work to preserve that history. > In a rebase model, every step of your feature can be compared to main. No it can't (unless you just rebased again before running the diff). What it can be compared to is the closest common ancestor. git diff main...<commit> Which is exactly the same operation that you'd run in a merge workflow. > I don't fucking care. Why don't you just commit some info about the local weather at that time too or that your back was hurting on Wednesday 23th? But those events do go wrong, and having the context to understand what happened matters. Have you never had a mismerge or a merge conflict?

exceptione 2y ago
When you rebase your feat branch on top of latest main, all commits in your feat branch are YOUR commits. Each of those commits change something relative to main. Unless your are committing against yourself. So if you are confusing yourself (which should be rare because --I repeat-- all commits in your feat branch are your own commits) you have a good opportunity to clean up your own mess with git rebase -i.
MrJohz 2y ago
> But those events do go wrong, and having the context to understand what happened matters. Have you never had a mismerge or a merge conflict? Interestingly, despite being designed for a very rebase-heavy workflow, this is one of the things that Jujutsu does really well. You work with mutable changes rather than immutable commits, and each change references one or more commits that represent (roughly) the history of that change. So locally, you can see how a particular change has evolved, and you can easily undo some action or reference an older state while working on that change itself. Then when you push to a remote, the other people will only see the end-result of the change. Which is typically what I want: I want to retain a good sense of the history of the changes I'm working on at the moment, so I can go back and forth, try out different things, and not worry about losing any data or handling conflicts badly or whatever. But, when I've finished with my change, and it's been pushed, reviewed, etc, that history is now superfluous. I don't need to know that, while I was developing a feature, I accidentally committed a typo and then needed to make another commit to remove that typo. (And if there is information I do think is important, then I can create additional changes, or add the information to the commit message or the code itself as a comment.)
- Nullabillity 2y ago
  > Interestingly, despite being designed for a very rebase-heavy workflow, this is one of the things that Jujutsu does really well. [snip] Then when you push to a remote, the other people will only see the end-result of the change. Yes, jujutsu is designed to hide (some of) the problems with rebase from yourself, while still inflicting them on everyone else . History for me, but not for thee! While also complicating the interaction model because you now have two sorts of history to contend with. Which actually sucks, because jj could have had been a much better alternative to Quilt for maintaining patch series over third-party software (á la Linux distributions) if it supported collaboration over the metahistory/oplog. > But, when I've finished with my change, and it's been pushed, reviewed, etc, that history is now superfluous. I don't need to know that, while I was developing a feature, I accidentally committed a typo and then needed to make another commit to remove that typo. This assumes that you'll actually find all the issues during the review. Do you also erase your history after every release?