5 ms·

Nice to see some seemingly jujutsu inspired features getting into Git core. git history reword ~= jj describe git history split ~= jj split https://git-s

Nice to see some seemingly jujutsu inspired features getting into Git core. git history reword ~= jj describe git history split ~= jj split https://git-scm.com/docs/git-history https://git-scm.com/docs/git-history https://www.jj-vcs.dev/latest/cli-reference/#jj-describe https://www.jj-vcs.dev/latest/cli-reference/#jj-describe https://www.jj-vcs.dev/latest/cli-reference/#jj-split https://www.jj-vcs.dev/latest/cli-reference/#jj-split

aulin 5mo ago
Not familiar with jj and don't want to get into bike shedding, but how is describe supposed to be a good name for history rewrites?
- roblabla 5mo ago
  jj describe gives a name to a commit. In jj, everything rewrites the history, so there's no real point in calling it out in the command name since it's just the default behavior.
  - locknitpicker 5mo ago
    > In jj, everything rewrites the history (...) Surely that isn't true, otherwise it would be completely unusable for auditing.
    - baq 5mo ago
      it is true. some history is marked immutable by default; in git, everything is mutable by default and you have to add branch protection on the server side. (granted, you can change what is immutable in jj relatively easily, so you shouldn't ignore branch protection if you're using jj exclusively with a git repo, either.)
    - kps 5mo ago
      It's not true, in that sense. Commits in jj are basically the same as commits in git as far as mutability is concerned. But in jj you normally work with changes, rather than commits, and open changes are mutable (by altering which immutable commit they point to in the backing store). And there is effectively an append-only audit trail of these alterations (which is what makes `jj undo`/`jj redo` simple). Some comments here are confusing the issue by saying ‘commit’ when they mean ‘change’ in the jj sense. Re the grandparent comment, `jj describe` provides a change description, analogous to `git commit --amend --edit` in git terms.
    - BeetleB 5mo ago
      By default, if you push to main/master, it marks those commits as immutable (you can still force change). You can configure this to other branches. But ... is it really that different from git? You can always rewrite history in git, correct?
- skydhash 5mo ago
  Not really familiar too, but jj has everything committed by default (no index, staging area, and uncommitted changes). You use ‘jj new’ to stop adding changes to the current commit. ‘jj describe’ lets you add a message to a commit as it’s not there by default.
- deleted 5mo ago
  [deleted]
- auscompgeek 5mo ago
  describe is also the command you can use to edit the commit message of the change you're currently drafting. In jj there's no staging area, every modification to the working tree immediately gets integrated into the current commit. (This means if you have no diff in your working tree, you're actually on an empty commit.)
- baq 5mo ago
  in jj the history has mutable and immutable commits.
wakawaka28 5mo ago
If this is meant to be a dig, you should keep in mind how much jj owes to git.
- IshKebab 5mo ago
  I don't know if it was meant to be a dig but I hope you don't think the fact that Git was a big advancement on SVN means it doesn't deserve any criticism. It's very widely remarked that the Git CLI is pretty miserable, and as soon as a better (so I hear) alternative comes along they suddenly realise and start improving it... This happens all the time in software. Some software has crap UX or missing obvious features (e.g. comments in package.json). People try and improve it but are rebuffed because the maintainers claim it's fine as it is. Effort goes elsewhere to a competitor project which starts to attract users. Maintains of the original project have a sudden and coincidental change of heart!
  - locknitpicker 5mo ago
    > It's very widely remarked that the Git CLI is pretty miserable, (...) You hear some very vocal critics expressing hyperbolic personal opinions on the topic, but I find that in the majority of the cases the opinions aren't objective or grounded on reality. It's just people whining. The litmus test is asking what is the worst example of this "pretty miserable" CLI they talk about. More often than not it's just baseless nitpicking. I recommend you give the litmus test a try to see how far this myth flies.
    - WorldMaker 5mo ago
      I feel like a lot of this is an "elephant memory" problem, too. ("An elephant never forgets.") Git was built very quickly and its early CLI was intentionally rough. Git was originally built with the idea that it was going to be all "plumbing" and to leave the good UX decisions to whatever "porcelain" people wanted to use on top, with some even expecting that there might be multiple competing "official" "porcelain" CLIs. Eventually that debate got settled in the surprise way to some of the earlier decisions about git being plumbing-first in that eventually git picked up both the "plumbing" and the official "porcelain". There's a lot of arguments that still seem to think of the git CLI before a lot of the porcelain projects started merging into git upstream. There's a lot of people that mostly only learned the plumbing tools and don't care for the porcelain projects. It certainly doesn't help that much of the best porcelain still isn't the default experience. You have to remember `git rebase -i` for the best porcelain rebase experience. You have to remember `git add -p` for the best porcelain add experience. (This article even indirectly hints at the silliness that the best interactive `git add` is `-p` for "pinteractive" because `-i` "interactive" was already taken by a weaker one.) That said, a lot of the porcelain is there today to take advantage of. Git has improved significantly from its plumbing-first worst CLIs. `git checkout` finally got split into `git switch` and `git restore` and both of those are great. (And no longer marked "experimental", they are official daily-use approved porcelain now.) That's also sort of the highlight of this post that a lot of the porcelain continues to improve. The UX of the git CLI isn't etched in stone. New, better commands are possible, and indeed are getting built by smart people, some of who even care about UX for themselves and their fellow developers. Git is no longer the rush project it once was. Git no longer sees itself as "plumbing-first" at the expense of the "porcelain". It will just maybe take a while for more of the elephants to forget the past horror stories and befuddlement.
NewsaHackO 5mo ago
jj is a "unofficial" Google project that one has to sign a Google CLA to contribute to. I don't think it would be a good idea to trust/transition to a system like that from git.
- baq 5mo ago
  what has one to do with the other...?
  - codygman 5mo ago
    I'll consider avoiding jj because of this, personally.
    - NewsaHackO 5mo ago
      It's always the first step. The second step would be switching the license and only supporting the changed licensed version, then "donating" the unmaintained version to the community.
      - gucci-on-fleek 5mo ago
        Has Google ever done this before though? I'm not much of a fan of Google either, but they tend to just abandon products outright rather than relicence them.
chrishill89 5mo ago
Yeah it’s a direct inspiration.
semanticc 5mo ago
It's not documented, but unfortunately neither of these re-signs the commits even if GPG signing is configured. They are based on `git replay`, and that doesn't sign either (at least yet).

aulin 5mo ago

Not familiar with jj and don't want to get into bike shedding, but how is describe supposed to be a good name for history rewrites?

roblabla 5mo ago
jj describe gives a name to a commit. In jj, everything rewrites the history, so there's no real point in calling it out in the command name since it's just the default behavior.
- locknitpicker 5mo ago
  > In jj, everything rewrites the history (...) Surely that isn't true, otherwise it would be completely unusable for auditing.
  - baq 5mo ago
    it is true. some history is marked immutable by default; in git, everything is mutable by default and you have to add branch protection on the server side. (granted, you can change what is immutable in jj relatively easily, so you shouldn't ignore branch protection if you're using jj exclusively with a git repo, either.)
  - kps 5mo ago
    It's not true, in that sense. Commits in jj are basically the same as commits in git as far as mutability is concerned. But in jj you normally work with changes, rather than commits, and open changes are mutable (by altering which immutable commit they point to in the backing store). And there is effectively an append-only audit trail of these alterations (which is what makes `jj undo`/`jj redo` simple). Some comments here are confusing the issue by saying ‘commit’ when they mean ‘change’ in the jj sense. Re the grandparent comment, `jj describe` provides a change description, analogous to `git commit --amend --edit` in git terms.
  - BeetleB 5mo ago
    By default, if you push to main/master, it marks those commits as immutable (you can still force change). You can configure this to other branches. But ... is it really that different from git? You can always rewrite history in git, correct?
skydhash 5mo ago
Not really familiar too, but jj has everything committed by default (no index, staging area, and uncommitted changes). You use ‘jj new’ to stop adding changes to the current commit. ‘jj describe’ lets you add a message to a commit as it’s not there by default.
deleted 5mo ago
[deleted]
auscompgeek 5mo ago
describe is also the command you can use to edit the commit message of the change you're currently drafting. In jj there's no staging area, every modification to the working tree immediately gets integrated into the current commit. (This means if you have no diff in your working tree, you're actually on an empty commit.)
baq 5mo ago
in jj the history has mutable and immutable commits.

wakawaka28 5mo ago

If this is meant to be a dig, you should keep in mind how much jj owes to git.

IshKebab 5mo ago
I don't know if it was meant to be a dig but I hope you don't think the fact that Git was a big advancement on SVN means it doesn't deserve any criticism. It's very widely remarked that the Git CLI is pretty miserable, and as soon as a better (so I hear) alternative comes along they suddenly realise and start improving it... This happens all the time in software. Some software has crap UX or missing obvious features (e.g. comments in package.json). People try and improve it but are rebuffed because the maintainers claim it's fine as it is. Effort goes elsewhere to a competitor project which starts to attract users. Maintains of the original project have a sudden and coincidental change of heart!
- locknitpicker 5mo ago
  > It's very widely remarked that the Git CLI is pretty miserable, (...) You hear some very vocal critics expressing hyperbolic personal opinions on the topic, but I find that in the majority of the cases the opinions aren't objective or grounded on reality. It's just people whining. The litmus test is asking what is the worst example of this "pretty miserable" CLI they talk about. More often than not it's just baseless nitpicking. I recommend you give the litmus test a try to see how far this myth flies.
  - WorldMaker 5mo ago
    I feel like a lot of this is an "elephant memory" problem, too. ("An elephant never forgets.") Git was built very quickly and its early CLI was intentionally rough. Git was originally built with the idea that it was going to be all "plumbing" and to leave the good UX decisions to whatever "porcelain" people wanted to use on top, with some even expecting that there might be multiple competing "official" "porcelain" CLIs. Eventually that debate got settled in the surprise way to some of the earlier decisions about git being plumbing-first in that eventually git picked up both the "plumbing" and the official "porcelain". There's a lot of arguments that still seem to think of the git CLI before a lot of the porcelain projects started merging into git upstream. There's a lot of people that mostly only learned the plumbing tools and don't care for the porcelain projects. It certainly doesn't help that much of the best porcelain still isn't the default experience. You have to remember `git rebase -i` for the best porcelain rebase experience. You have to remember `git add -p` for the best porcelain add experience. (This article even indirectly hints at the silliness that the best interactive `git add` is `-p` for "pinteractive" because `-i` "interactive" was already taken by a weaker one.) That said, a lot of the porcelain is there today to take advantage of. Git has improved significantly from its plumbing-first worst CLIs. `git checkout` finally got split into `git switch` and `git restore` and both of those are great. (And no longer marked "experimental", they are official daily-use approved porcelain now.) That's also sort of the highlight of this post that a lot of the porcelain continues to improve. The UX of the git CLI isn't etched in stone. New, better commands are possible, and indeed are getting built by smart people, some of who even care about UX for themselves and their fellow developers. Git is no longer the rush project it once was. Git no longer sees itself as "plumbing-first" at the expense of the "porcelain". It will just maybe take a while for more of the elephants to forget the past horror stories and befuddlement.

NewsaHackO 5mo ago

jj is a "unofficial" Google project that one has to sign a Google CLA to contribute to. I don't think it would be a good idea to trust/transition to a system like that from git.

baq 5mo ago
what has one to do with the other...?
- codygman 5mo ago
  I'll consider avoiding jj because of this, personally.
  - NewsaHackO 5mo ago
    It's always the first step. The second step would be switching the license and only supporting the changed licensed version, then "donating" the unmaintained version to the community.
    - gucci-on-fleek 5mo ago
      Has Google ever done this before though? I'm not much of a fan of Google either, but they tend to just abandon products outright rather than relicence them.

chrishill89 5mo ago

Yeah it’s a direct inspiration.

semanticc 5mo ago

It's not documented, but unfortunately neither of these re-signs the commits even if GPG signing is configured. They are based on `git replay`, and that doesn't sign either (at least yet).