4 ms·

I have colleagues who are big fans of it. I gave it a try, but I really don't get what is the problem it is trying to solve. Like, what is it that I will be abl

I have colleagues who are big fans of it. I gave it a try, but I really don't get what is the problem it is trying to solve. Like, what is it that I will be able to do that I couldn't do with git, and why bother learning it at all

martinvonz 2y ago
Have you tried asking your colleagues? What did they say?
- ozornin 2y ago
  I considered it, but it would inevitably involve talking to people, and it is a little too far for me
baq 2y ago
If you ever did stacked prs and then had to rebase them all on top of each other, this is why. Otherwise I also find it not really an improvement and a downgrade in terms of other tooling (editor etc.)
- ks6g10 2y ago
  I do this regularly with magit, but mby I am missing something? I.e. the typical Gerrit workflow
Skinney 2y ago
I find JJ to be what you get when you take a step back, evaluate everything that works in Git and try to find a design that accomplishes all those things with the fewest amount of concepts possible. Like a Git 2.0, if you will. You can do most of the same things, but it's easier to understand it intuitively so you don't need to google or give up on the more advanced usages. And the things you do everyday you can do with fewer steps. Couple that with colocated repos, meaning I can use JJ while everyone keeps on using Git, there wasn't really anything holding me back.
- motorest 2y ago
  > You can do most of the same things, but it's easier to understand it intuitively so you don't need to google or give up on the more advanced usages. And the things you do everyday you can do with fewer steps. Care to point out any concrete example?
  - Skinney 2y ago
    Sure. I think what comes up most often for me is when I want to fix something on a different branch than the one I'm at now, or when I want to fix something that feels like it should be separate commit. In git you can `git stash`, commit the unrelated change and then run `git stash pop` to get your in-progress changes back. In jj your work is already added to the current commit whenever you run a jj command, so you can simply switch to the other branch and do the work, and when you switch back your work is as you left it. It saves you the `git stash` commands. I also like that anonymous branches are completely normal in jj, so I don't need to create branches just to find my way back to a change. Similarly, jj removes most usages of `git rebase --interactive` by allowing you to checkout a previous commit, and as you're making changes to it all descendant commits are being rebased automatically. This makes it easy to insert changes between two commits, simply create a new commit where you'd like it to go and then descendant commits will automatically be rebased on this new commit as you make changes. To me this is more intuitive, and it removes `stash` and `rebase --interactive` as concepts.
    - motorest 2y ago
      > In git you can `git stash`, commit the unrelated change and then run `git stash pop` to get your in-progress changes back. Not necessarily. You can just commit your changes, switch to whatever branch you want to work on, and then when you switch back to the old branch you can resume working as always. This is not a Git thing. Even Mercurial advocated for this approach, and sold it as the only and true way of stashing changes. Mercurial only received support for a stash-like feature much later and in the form of an extension. Also, even though git stash can be used in workflows that involve switching branches, it is suitable primarily for very short-lived tasks that prevent you from committing changes to a branch. Things like pulling changes from a remote branch or switching brsnched when you have random local changes in place (I.e., changed to config files for troubleshooting purposes)
Nullabillity 2y ago
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.

martinvonz 2y ago

Have you tried asking your colleagues? What did they say?

ozornin 2y ago
I considered it, but it would inevitably involve talking to people, and it is a little too far for me

baq 2y ago

If you ever did stacked prs and then had to rebase them all on top of each other, this is why. Otherwise I also find it not really an improvement and a downgrade in terms of other tooling (editor etc.)

ks6g10 2y ago
I do this regularly with magit, but mby I am missing something? I.e. the typical Gerrit workflow

Skinney 2y ago

I find JJ to be what you get when you take a step back, evaluate everything that works in Git and try to find a design that accomplishes all those things with the fewest amount of concepts possible. Like a Git 2.0, if you will. You can do most of the same things, but it's easier to understand it intuitively so you don't need to google or give up on the more advanced usages. And the things you do everyday you can do with fewer steps. Couple that with colocated repos, meaning I can use JJ while everyone keeps on using Git, there wasn't really anything holding me back.

motorest 2y ago
> You can do most of the same things, but it's easier to understand it intuitively so you don't need to google or give up on the more advanced usages. And the things you do everyday you can do with fewer steps. Care to point out any concrete example?
- Skinney 2y ago
  Sure. I think what comes up most often for me is when I want to fix something on a different branch than the one I'm at now, or when I want to fix something that feels like it should be separate commit. In git you can `git stash`, commit the unrelated change and then run `git stash pop` to get your in-progress changes back. In jj your work is already added to the current commit whenever you run a jj command, so you can simply switch to the other branch and do the work, and when you switch back your work is as you left it. It saves you the `git stash` commands. I also like that anonymous branches are completely normal in jj, so I don't need to create branches just to find my way back to a change. Similarly, jj removes most usages of `git rebase --interactive` by allowing you to checkout a previous commit, and as you're making changes to it all descendant commits are being rebased automatically. This makes it easy to insert changes between two commits, simply create a new commit where you'd like it to go and then descendant commits will automatically be rebased on this new commit as you make changes. To me this is more intuitive, and it removes `stash` and `rebase --interactive` as concepts.
  - motorest 2y ago
    > In git you can `git stash`, commit the unrelated change and then run `git stash pop` to get your in-progress changes back. Not necessarily. You can just commit your changes, switch to whatever branch you want to work on, and then when you switch back to the old branch you can resume working as always. This is not a Git thing. Even Mercurial advocated for this approach, and sold it as the only and true way of stashing changes. Mercurial only received support for a stash-like feature much later and in the form of an extension. Also, even though git stash can be used in workflows that involve switching branches, it is suitable primarily for very short-lived tasks that prevent you from committing changes to a branch. Things like pulling changes from a remote branch or switching brsnched when you have random local changes in place (I.e., changed to config files for troubleshooting purposes)

Nullabillity 2y ago

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.