4 ms·

I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. I have used i

by mamcx 2y ago

I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. I have used it already for a few years and can't for the life of me figure out how to solve problems with it. I just have a bunch of aliases that abstract away for the inconsistency of its commands. Now, I switched to `jj` a month ago and basically, I have learned around 60%-ish of it. And more importantly, I have gotten out of a bunch of serious trouble (you can UNDO!!!!) already. But if this rant is not enough: * You can UNDO. Everything. That is the major thing * You can switch from one `branch` to `another` and leave things incomplete, even conflicts, that is nice. * The command made sense * Nobody else knows you use `jj`, so no barrier to adoption. * Rebases are not painful anymore. Stacking prs are finally nice to author, even of NOBODY ELSE KNOW IT! The major troubles: * Not yet support for major tools, ides for it. It stays in `detached head` which is not as nice as showing the current branch on IDEs, and when you are fixing conflicts some tools do not get the diffs. * No mature UI tool. I use `gg` which is fine enough But the above is just temporal problems. Git will never be `fixed` or improved, so is pain forever.

12_throw_away 2y ago
> I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. Right? I even started with git, and had been somewhat comfortable with it for years. Then I joined a mercurial shop, and was more proficient with `hg` in 1 month than I had been with `git` after 5 years. It ruined me on git forever, I can't see it as anything other than a mess of wrong abstractions. And unfortunately, these days I'm back using git with the rest of the world. Can't wait for the day when Jetbrains gets a good plugin for either `jj` or `sapling`, and I never have to google another git command again ...
- pkulak 2y ago
  I just use the CLI, even when using IntelliJ. I may be wrong, but JJ seems to have recently moved to a new model where your most recent change is (always?) stored in git as "unstaged". That means when you use an editor, you can be using the CLI to add a description, diff, or other things, and the editor will still show all the UI hints about changes, let you see the diffs there, revert there, etc. You can blame, see history, everything. There's almost no need for a dedicated plugin. When I first started using jj, I remember just doing a "jj st" would commit everything and I'd lose all my editor support. It was pretty much the only part that got worse after switching. And now it's "fixed". If anyone knows more about jj than me, I'd love to know if I'm right about this, or just hallucinating. :D
  - cube2222 2y ago
    Can confirm this. I’ve also configured my jj to use the goland/intellij terminal command for diff viewing and conflict resolution, so I can still use the (imo great) visual tooling built into JetBrains IDEs.
    - pkulak 2y ago
      Great idea! I just did this, and it's a very nice QOL improvement.
pkulak 2y ago
> Nobody else knows you use `jj`, so no barrier to adoption. All my PRs now have branches named "push-kjasdfkhdf", so it's not terribly well hidden. :D
- BeetleB 2y ago
  You can name them if you want.
  - zellyn 2y ago
    Hah. I didn't even realize you could _not_ name them. I just do: jj b c zellyn/appname-update-plugh-tests jj git push
    - steveklabnik 2y ago
      jj git push -c <changeid> will create a bookmark for you and automatically give it a random name. Most folks who do this configure it to add a prefix, often a username.
      - pkulak 2y ago
        Oh, I didn't know you could do that. Nice. EDIT: Docs here: https://github.com/jj-vcs/jj/blob/main/docs/config.md#prefix-for-generated-bookmarks-on-push https://github.com/jj-vcs/jj/blob/main/docs/config.md#prefix...
tripple6 2y ago
I would never work with hg anymore since and I consider git much and much more flexible from both user and scripting perspective. Yes, git also suffers of command inconsistency, and unfortunately it seems to be never fixed. > You can UNDO. Everything. That is the major thing Everything is what? The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index for the first time and then reset. Maybe rebase in mid-rebase is a way to lose some changes so one has re-rebase again (it's really annoying, but reflog holds all rebase changes if I recall). I can't really see what you mean. > You can switch from one `branch` to `another` and leave things incomplete, even conflicts, that is nice. It's nice. I use git-worktree for multiple branches I work on, so my working copies may remain dirty even in conflict stage. > The command made sense It's nice. > Nobody else knows you use `jj`, so no barrier to adoption. It's really nice, but I'm not sure whether I understand it, but does it work as a front-end tool over git/other VCS? > Rebases are not painful anymore. Stacking prs are finally nice to author, even of NOBODY ELSE KNOW IT! I don't get it. What does make rebase hard? It's just re-applying a bunch of patches or possibly merges on top of the new base, and it doesn't even require interactive mode. Interactive mode makes magic I'm happy with. Seriously, what's wrong with it?
- cube2222 2y ago
  Generally, most things jj does can be done in Git, it's just much more pleasant / seamless / consistent in jj - maybe with the exception of the "Working on Two Things at the Same Time" pattern[0], that one might be really hard to achieve in Git. > but does it work as a front-end tool over git/other VCS? citing from the article > Before we dive in, one last thing you should take note of, is that most people use jj with its Git backend. You can use jj with your existing Git repos and reap its benefits in a way that is completely transparent to others you’re collaborating with. Effectively, you can treat it like a Git frontend. > I don't get it. What does make rebase hard? It's hard when you work on a set of stacked PRs and make frequent changes to arbitrary PRs in that stack, because every time you make a change, you have to manually rebase and push all of the other PRs. There's SaaS's specifically built and used for solving this problem in Git[1]. Maybe hard is the wrong word, it's just annoying and tedious. jj makes this completely seamless, as shown in the article[2]. [0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs/#pattern-working-on-two-things-at-the-same-time https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs... [1]: https://graphite.dev/ https://graphite.dev/ [2]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs/#pattern-stacked-prs https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...
eikenberry 2y ago
> I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. IMO Mercurial did a lot of this to themselves. I also preferred it at first but switched away from it due to their stance on no in-repo branching. They, of course, also lost due to git's author and network effects (github), but it wasn't all just "market forces".

by mamcx 2y ago

12_throw_away 2y ago

> I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. Right? I even started with git, and had been somewhat comfortable with it for years. Then I joined a mercurial shop, and was more proficient with `hg` in 1 month than I had been with `git` after 5 years. It ruined me on git forever, I can't see it as anything other than a mess of wrong abstractions. And unfortunately, these days I'm back using git with the rest of the world. Can't wait for the day when Jetbrains gets a good plugin for either `jj` or `sapling`, and I never have to google another git command again ...

pkulak 2y ago
I just use the CLI, even when using IntelliJ. I may be wrong, but JJ seems to have recently moved to a new model where your most recent change is (always?) stored in git as "unstaged". That means when you use an editor, you can be using the CLI to add a description, diff, or other things, and the editor will still show all the UI hints about changes, let you see the diffs there, revert there, etc. You can blame, see history, everything. There's almost no need for a dedicated plugin. When I first started using jj, I remember just doing a "jj st" would commit everything and I'd lose all my editor support. It was pretty much the only part that got worse after switching. And now it's "fixed". If anyone knows more about jj than me, I'd love to know if I'm right about this, or just hallucinating. :D
- cube2222 2y ago
  Can confirm this. I’ve also configured my jj to use the goland/intellij terminal command for diff viewing and conflict resolution, so I can still use the (imo great) visual tooling built into JetBrains IDEs.
  - pkulak 2y ago
    Great idea! I just did this, and it's a very nice QOL improvement.

pkulak 2y ago

> Nobody else knows you use `jj`, so no barrier to adoption. All my PRs now have branches named "push-kjasdfkhdf", so it's not terribly well hidden. :D

BeetleB 2y ago
You can name them if you want.
- zellyn 2y ago
  Hah. I didn't even realize you could _not_ name them. I just do: jj b c zellyn/appname-update-plugh-tests jj git push
  - steveklabnik 2y ago
    jj git push -c <changeid> will create a bookmark for you and automatically give it a random name. Most folks who do this configure it to add a prefix, often a username.
    - pkulak 2y ago
      Oh, I didn't know you could do that. Nice. EDIT: Docs here: https://github.com/jj-vcs/jj/blob/main/docs/config.md#prefix-for-generated-bookmarks-on-push https://github.com/jj-vcs/jj/blob/main/docs/config.md#prefix...

tripple6 2y ago

I would never work with hg anymore since and I consider git much and much more flexible from both user and scripting perspective. Yes, git also suffers of command inconsistency, and unfortunately it seems to be never fixed. > You can UNDO. Everything. That is the major thing Everything is what? The things git cannot undo is removing untracked files (well they're untracked) on git-clean, or files added to the index for the first time and then reset. Maybe rebase in mid-rebase is a way to lose some changes so one has re-rebase again (it's really annoying, but reflog holds all rebase changes if I recall). I can't really see what you mean. > You can switch from one `branch` to `another` and leave things incomplete, even conflicts, that is nice. It's nice. I use git-worktree for multiple branches I work on, so my working copies may remain dirty even in conflict stage. > The command made sense It's nice. > Nobody else knows you use `jj`, so no barrier to adoption. It's really nice, but I'm not sure whether I understand it, but does it work as a front-end tool over git/other VCS? > Rebases are not painful anymore. Stacking prs are finally nice to author, even of NOBODY ELSE KNOW IT! I don't get it. What does make rebase hard? It's just re-applying a bunch of patches or possibly merges on top of the new base, and it doesn't even require interactive mode. Interactive mode makes magic I'm happy with. Seriously, what's wrong with it?

cube2222 2y ago
Generally, most things jj does can be done in Git, it's just much more pleasant / seamless / consistent in jj - maybe with the exception of the "Working on Two Things at the Same Time" pattern[0], that one might be really hard to achieve in Git. > but does it work as a front-end tool over git/other VCS? citing from the article > Before we dive in, one last thing you should take note of, is that most people use jj with its Git backend. You can use jj with your existing Git repos and reap its benefits in a way that is completely transparent to others you’re collaborating with. Effectively, you can treat it like a Git frontend. > I don't get it. What does make rebase hard? It's hard when you work on a set of stacked PRs and make frequent changes to arbitrary PRs in that stack, because every time you make a change, you have to manually rebase and push all of the other PRs. There's SaaS's specifically built and used for solving this problem in Git[1]. Maybe hard is the wrong word, it's just annoying and tedious. jj makes this completely seamless, as shown in the article[2]. [0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs/#pattern-working-on-two-things-at-the-same-time https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs... [1]: https://graphite.dev/ https://graphite.dev/ [2]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs/#pattern-stacked-prs https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs...

eikenberry 2y ago

> I was a happy mercurial user until market forces and consulting needs made me, regrettably, use the inferior, more complex, more error-prone git. IMO Mercurial did a lot of this to themselves. I also preferred it at first but switched away from it due to their stance on no in-repo branching. They, of course, also lost due to git's author and network effects (github), but it wasn't all just "market forces".