3 ms·

Ultimately, jj is trying to make the "branches are a mutable series of patches" workflow easier. The problem is that that workflow is still ultimately harmful

Ultimately, jj is trying to make the "branches are a mutable series of patches" workflow easier. The problem is that that workflow is still ultimately harmful nonsense[0] that is based on a misunderstanding of version control. [0]: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

motorest 2y ago
> The problem is that that workflow is still ultimately harmful nonsense[0] that is based on a misunderstanding of version control. The problem with that article is that it's utter nonsense and completely misses the whole point of rebase. No one cares if under the hood a rebase is technically a merge that forgets where it came from. I mean, isn't that the whole point of a rebase? The whole point of a rebase is to move your local branch onto the tip of another branch while preserving the local history. The goal is to simplify the repository history by eliminating irrelevant noise. That's not a problem, it's a solution. Is this too hard to understand? How can they possibly miss the extra forks and joins in their commit graph? Do they not see that? Do they spend any time looking at commit graphs? It's ok if Fossil's devs want to force their opinionated take on VCS onto Fossil's users, but this does not mean they are right or have a point. In this case they are not only missing the whole point but also taking a completely wrong approach to mitigate it. The fact that they felt compelled to put up a page trying to present their case (and failing) is already telling. If there is criticism to throw at Git, rebases clearly ain't it.
- Nullabillity 2y ago
  > No one cares if under the hood a rebase is technically a merge that forgets where it came from. I mean, isn't that the whole point of a rebase? Hurting people is the point of a gun, that doesn't mean guns are suddenly excused from doing so. > The whole point of a rebase is to move your local branch onto the tip of another branch while preserving the local history. But you aren't; history is as much about where you came from as where you are now. > The goal is to simplify the repository history by eliminating irrelevant noise. Because merges aren't noise, they are fallible events just like manual changes. They also help to group changes together and provide helpful context. > That's not a problem, it's a solution. How can they possibly miss the extra forks and joins in their commit graph? Do they not see that? Do they spend any time looking at commit graphs? If you don't want to see the merges, hide them. `git log --first-parent` shows you the commit history as if all merges were squashes instead. Meanwhile, the rest of us can suddenly appreciate having the extra context available when it's actually needed. > It's ok if Fossil's devs want to force their opinionated take on VCS onto Fossil's users, but this does not mean they are right or have a point. Deleting data is opinionated, preserving it leaves it up to the reader to judge. But my point isn't that you should use Fossil, but that Git is a far better VCS if you use it as if it was Fossil. > If there is criticism to throw at Git, rebases clearly ain't it. In my, uh, decade or so of using Git, every single avoidable problem that I have seen people have with Git turns out to originally come from rebasing.
  - exceptione 2y ago
    > In my, uh, decade or so of using Git, every single avoidable problem that I have seen people have with Git turns out to originally come from rebasing. That means that both you and those people do not fully grasp the concept. The problem I have is that those misunderstandings are spread such that I have to deal with it. Especially those that do not understand Git at all keep merging balls of merges of merges. Then they lose track, and decide to just merge main again because something broke and they hope that Git will solve it with just one more merge. I have no problem with incompetence, I myself am incompetent in a lot of areas, and I know that. When I have to work with people, I have a problem with those that are not able or willing to acknowledge they lack some overview.
    - Nullabillity 2y ago
      Merges go wrong sometimes. That's life. That mismerge would have been just as bad if they had rebased instead, except you wouldn't have had the context to go back and fix it. How would that be better?
      - exceptione 2y ago
        If your merge goes wrong, you should rip it out of your feature branch. You use git rebase -i for that, or git reset even. But you shouldn't merge into your feature branch at all. We are interested in how your commits change what becomes before it in mainline. We are not interested in how main differed from your feature branch at various points in time. Git rebase is wonderful for people that create mess when working. Your feature branch can contain lots of WIPs for all the times you hit five 'o clock. With interactive rebase you can clean up your mess: squash, split, delete and reorder commits. You can do this all graphically even, like drag-drop reordering of commits. Also read up about git fixup and friends for quick fixes. There is also git rebase abort if you think you are doing something wrong.
    - motorest 2y ago
      > That means that both you and those people do not fully grasp the concept. The problem I have is that those misunderstandings are spread such that I have to deal with it. Especially those that do not understand Git at all keep merging balls of merges of merges. Then they lose track, and decide to just merge main again because something broke and they hope that Git will solve it with just one more merge. I would take a step further and say the root cause is not users who do not fully grasp a concept of Git, but who fail to grasp one of the most fundamental aspects of version control systems: branching and merging. Git just happens to take a bad rap because it's ubiquitous and for some it's the only VCS they ever used. Of course a bad workman blames his tools. If the tool they are using is Git then of course that's the one being thrown under the bus. What is perplexing is how this problem is then approached by people who are expected to know better by framing it as something only a bad tool would do, and thus they roll out yet another tool that does the same thing and poses the same problems. In the case of jj, they even claim to fix git by running git as the backend. Think about that for a second.
hhjinks 2y ago
The author of that article clearly doesn't understand rebasing. They state that "the golden rule of rebasing" in the "Git rebase documentation" (actually just an Atlassian git tutorial) says that you should "never rebase on a public branch", when the tutorial they reference unambiguously states you shouldn't rebase a public branch onto your own local changes. Rebasing on public branches is the raison d'être of rebasing. The entire article seems like cope, the author deciding to bash rebase because they don't understand it.
exceptione 2y ago
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.

motorest 2y ago

> The problem is that that workflow is still ultimately harmful nonsense[0] that is based on a misunderstanding of version control. The problem with that article is that it's utter nonsense and completely misses the whole point of rebase. No one cares if under the hood a rebase is technically a merge that forgets where it came from. I mean, isn't that the whole point of a rebase? The whole point of a rebase is to move your local branch onto the tip of another branch while preserving the local history. The goal is to simplify the repository history by eliminating irrelevant noise. That's not a problem, it's a solution. Is this too hard to understand? How can they possibly miss the extra forks and joins in their commit graph? Do they not see that? Do they spend any time looking at commit graphs? It's ok if Fossil's devs want to force their opinionated take on VCS onto Fossil's users, but this does not mean they are right or have a point. In this case they are not only missing the whole point but also taking a completely wrong approach to mitigate it. The fact that they felt compelled to put up a page trying to present their case (and failing) is already telling. If there is criticism to throw at Git, rebases clearly ain't it.

Nullabillity 2y ago
> No one cares if under the hood a rebase is technically a merge that forgets where it came from. I mean, isn't that the whole point of a rebase? Hurting people is the point of a gun, that doesn't mean guns are suddenly excused from doing so. > The whole point of a rebase is to move your local branch onto the tip of another branch while preserving the local history. But you aren't; history is as much about where you came from as where you are now. > The goal is to simplify the repository history by eliminating irrelevant noise. Because merges aren't noise, they are fallible events just like manual changes. They also help to group changes together and provide helpful context. > That's not a problem, it's a solution. How can they possibly miss the extra forks and joins in their commit graph? Do they not see that? Do they spend any time looking at commit graphs? If you don't want to see the merges, hide them. `git log --first-parent` shows you the commit history as if all merges were squashes instead. Meanwhile, the rest of us can suddenly appreciate having the extra context available when it's actually needed. > It's ok if Fossil's devs want to force their opinionated take on VCS onto Fossil's users, but this does not mean they are right or have a point. Deleting data is opinionated, preserving it leaves it up to the reader to judge. But my point isn't that you should use Fossil, but that Git is a far better VCS if you use it as if it was Fossil. > If there is criticism to throw at Git, rebases clearly ain't it. In my, uh, decade or so of using Git, every single avoidable problem that I have seen people have with Git turns out to originally come from rebasing.
- exceptione 2y ago
  > In my, uh, decade or so of using Git, every single avoidable problem that I have seen people have with Git turns out to originally come from rebasing. That means that both you and those people do not fully grasp the concept. The problem I have is that those misunderstandings are spread such that I have to deal with it. Especially those that do not understand Git at all keep merging balls of merges of merges. Then they lose track, and decide to just merge main again because something broke and they hope that Git will solve it with just one more merge. I have no problem with incompetence, I myself am incompetent in a lot of areas, and I know that. When I have to work with people, I have a problem with those that are not able or willing to acknowledge they lack some overview.
  - Nullabillity 2y ago
    Merges go wrong sometimes. That's life. That mismerge would have been just as bad if they had rebased instead, except you wouldn't have had the context to go back and fix it. How would that be better?
    - exceptione 2y ago
      If your merge goes wrong, you should rip it out of your feature branch. You use git rebase -i for that, or git reset even. But you shouldn't merge into your feature branch at all. We are interested in how your commits change what becomes before it in mainline. We are not interested in how main differed from your feature branch at various points in time. Git rebase is wonderful for people that create mess when working. Your feature branch can contain lots of WIPs for all the times you hit five 'o clock. With interactive rebase you can clean up your mess: squash, split, delete and reorder commits. You can do this all graphically even, like drag-drop reordering of commits. Also read up about git fixup and friends for quick fixes. There is also git rebase abort if you think you are doing something wrong.
  - motorest 2y ago
    > That means that both you and those people do not fully grasp the concept. The problem I have is that those misunderstandings are spread such that I have to deal with it. Especially those that do not understand Git at all keep merging balls of merges of merges. Then they lose track, and decide to just merge main again because something broke and they hope that Git will solve it with just one more merge. I would take a step further and say the root cause is not users who do not fully grasp a concept of Git, but who fail to grasp one of the most fundamental aspects of version control systems: branching and merging. Git just happens to take a bad rap because it's ubiquitous and for some it's the only VCS they ever used. Of course a bad workman blames his tools. If the tool they are using is Git then of course that's the one being thrown under the bus. What is perplexing is how this problem is then approached by people who are expected to know better by framing it as something only a bad tool would do, and thus they roll out yet another tool that does the same thing and poses the same problems. In the case of jj, they even claim to fix git by running git as the backend. Think about that for a second.

hhjinks 2y ago

The author of that article clearly doesn't understand rebasing. They state that "the golden rule of rebasing" in the "Git rebase documentation" (actually just an Atlassian git tutorial) says that you should "never rebase on a public branch", when the tutorial they reference unambiguously states you shouldn't rebase a public branch onto your own local changes. Rebasing on public branches is the raison d'être of rebasing. The entire article seems like cope, the author deciding to bash rebase because they don't understand it.

exceptione 2y ago

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.