4 ms·

I feel pretty dense, because I still struggle to get my head around automatically adding changes to a revision. Sometimes, I'll make a change locally to a file

I feel pretty dense, because I still struggle to get my head around automatically adding changes to a revision. Sometimes, I'll make a change locally to a file that I'll use during the development process that I have no intention of committing. With regular git, I never stage that file so there's no danger of accidentally pushing my change to the remote repo, but it seems with jj I'll need to somehow unstage that change or something to prevent this. Perhaps it's just habit, but I feel more comfortable explicitly saying what I want to commit rather that defaulting to everything. Or have I totally misunderstood jj?

do_not_redeem 1y ago
If you want this workflow, you can treat jj's `@` (nominally equivalent to git's HEAD) as the git index, then at commit time, manually squash changes to `@-` just like you would with `git add --patch`.
- 000ooo000 1y ago
  FWIW, @ is a shortcut for HEAD in Git.
- Nzen 1y ago
  When I've asked about using a jj stage, that's the workflow people pointed me to, as described in this tutorial [0]. I've not tried it, nor jujutsu, but I felt it worth pointing at a concrete example to allay or stoke fears of people on the fence. [0] https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-squash-workflow.html https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...
0cf8612b2e1e 1y ago
No that is correct, and also a habit I am trying to break. The reasonable argument is that we should stop running code with untracked state. Either the changes are important and should be committed or not. Otherwise you are recording code versions that never truly existed during development. Where this gets extra sticky for me is tooling which refuses to distinguish repo wide config vs a local only version. VSCode being a huge offender where there is only a ‘launch.json’ and no ‘launch.local.json’ suitable for per host customization (eg maybe I am already running something on port 8888, so I need to map it to 9000, that does not mean a quirk of my environment should be committed).
- oxidant 1y ago
  Counterpoint: Why should my println debugging get committed? They're not "important" for the final product but important for development.
  - 0cf8612b2e1e 1y ago
    The logic is once you are ready to commit you delete all of the debugging stuff. Otherwise you are committing an illusionary state of the repo that only existed by manipulating the stage. I am a black kettle here as I frequently commit individual lines amongst a sea of changes, but I do appreciate the theoretical stance of jj.
    - steveklabnik 1y ago
      Just to be clear, jj makes it really easy to carry this sort of thing as a separate patch, so while it may be "committed," that doesn't mean it has to go into what you send upstream. (though for debug printfs in particular, the Right Thing is proper logging with log levels, but I myself love printf debugging and so sometimes don't do that either. Which is why carrying local patches is nice.)
      - baq 1y ago
        There is no Right Thing here. Practicality beats purity. The product (a snapshot of the source tree) should do what it needs to do, but getting there is not the product. It can be if you want it to be, but there is no upside to that.
    - andrewaylett 1y ago
      A tool like pre-commit really helps here: it'll run against the staged files, before committing. Your CI tool really ought to be testing the commit too, at which point having a clean commit locally isn't necessary for correctness, only for avoiding needing to re-do your work. It's really important to catch bugs early, because it's a lot more expensive to fix them later -- even if only as late as in CI before merging.
stouset 1y ago
In jj you tend to use `jj split` to break changes apart. The selected bits become the first revision, the remaining bits become the second revision. I tend to do a bunch of work then split into small, bite-sized revisions. Often I split something out to a parallel revision (e.g., a separate branch) if it’s an independent thread of work like a bugfix elsewhere or a documentation fix. This is an obvious one-liner in jj but a bunch of annoying branch-switching and stashing in git. You can also use a `git add`-style workflow. Create a new revision with `jj new`. Do it again. Make your changes, then `jj squash -i/--interactive` to select the bits you want to include. Keep making changes and squashing into the previous commit you’re building up until you’re happy. Conceptually just think of @ (the current revision) and @- (the previous revision) as the working copy and the staged copy, respectively.
- palata 1y ago
  I feel like I already lost more time reading this than jj would make me win if I switched :-).
  - stouset 1y ago
    In the first year of switching I easily saved more time and frustration than the sum total of all of my jj evangelism on HN.
rtpg 1y ago
I usually work, then do `jj split` to review changes I want to make commits to. This generally makes the workflow look like `git add -p`. A decent mental model is that the top-most commit isn't generally going to get pushed up anywhere. It's like your working copy but also you get stashing "for free" (change back to main to make a new commit? All the WIP stuff stays on that branch instead of being carried over to main!)
ethan_smith 1y ago
[flagged]
- notmywalrus 1y ago
  ...no? On all counts. `jj ignore` is not a command. [1] There is no such thing as `.jjignore` files [2], [3]. `--no-snapshot` is not a flag, neither on `jj edit` nor in general. Additionally, it doesn't make sense conceptually --- `jj edit` changes the working copy, which will then propagate changes to the selected commit every time you edit a file. If you want to check out an old commit without amending it, you `jj new` on top of it. If you end up making changes that you don't care about, you can `jj abandon` them. [1]: https://jj-vcs.github.io/jj/latest/cli-reference/ https://jj-vcs.github.io/jj/latest/cli-reference/ [2]: https://github.com/jj-vcs/jj/issues/3525 https://github.com/jj-vcs/jj/issues/3525 [3]: https://jj-vcs.github.io/jj/latest/working-copy/#ignored-files https://jj-vcs.github.io/jj/latest/working-copy/#ignored-fil...
simonmic 1y ago
jj's auto staging isn't always desirable. I feel jj docs and evangelists should make clearer that it's easy to turn off by default, by adding this to ~/.jjconfig: [snapshot] auto-track = "none()"

do_not_redeem 1y ago

If you want this workflow, you can treat jj's `@` (nominally equivalent to git's HEAD) as the git index, then at commit time, manually squash changes to `@-` just like you would with `git add --patch`.

000ooo000 1y ago
FWIW, @ is a shortcut for HEAD in Git.
Nzen 1y ago
When I've asked about using a jj stage, that's the workflow people pointed me to, as described in this tutorial [0]. I've not tried it, nor jujutsu, but I felt it worth pointing at a concrete example to allay or stoke fears of people on the fence. [0] https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-squash-workflow.html https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...

0cf8612b2e1e 1y ago

No that is correct, and also a habit I am trying to break. The reasonable argument is that we should stop running code with untracked state. Either the changes are important and should be committed or not. Otherwise you are recording code versions that never truly existed during development. Where this gets extra sticky for me is tooling which refuses to distinguish repo wide config vs a local only version. VSCode being a huge offender where there is only a ‘launch.json’ and no ‘launch.local.json’ suitable for per host customization (eg maybe I am already running something on port 8888, so I need to map it to 9000, that does not mean a quirk of my environment should be committed).

oxidant 1y ago
Counterpoint: Why should my println debugging get committed? They're not "important" for the final product but important for development.
- 0cf8612b2e1e 1y ago
  The logic is once you are ready to commit you delete all of the debugging stuff. Otherwise you are committing an illusionary state of the repo that only existed by manipulating the stage. I am a black kettle here as I frequently commit individual lines amongst a sea of changes, but I do appreciate the theoretical stance of jj.
  - steveklabnik 1y ago
    Just to be clear, jj makes it really easy to carry this sort of thing as a separate patch, so while it may be "committed," that doesn't mean it has to go into what you send upstream. (though for debug printfs in particular, the Right Thing is proper logging with log levels, but I myself love printf debugging and so sometimes don't do that either. Which is why carrying local patches is nice.)
    - baq 1y ago
      There is no Right Thing here. Practicality beats purity. The product (a snapshot of the source tree) should do what it needs to do, but getting there is not the product. It can be if you want it to be, but there is no upside to that.
  - andrewaylett 1y ago
    A tool like pre-commit really helps here: it'll run against the staged files, before committing. Your CI tool really ought to be testing the commit too, at which point having a clean commit locally isn't necessary for correctness, only for avoiding needing to re-do your work. It's really important to catch bugs early, because it's a lot more expensive to fix them later -- even if only as late as in CI before merging.

stouset 1y ago

In jj you tend to use `jj split` to break changes apart. The selected bits become the first revision, the remaining bits become the second revision. I tend to do a bunch of work then split into small, bite-sized revisions. Often I split something out to a parallel revision (e.g., a separate branch) if it’s an independent thread of work like a bugfix elsewhere or a documentation fix. This is an obvious one-liner in jj but a bunch of annoying branch-switching and stashing in git. You can also use a `git add`-style workflow. Create a new revision with `jj new`. Do it again. Make your changes, then `jj squash -i/--interactive` to select the bits you want to include. Keep making changes and squashing into the previous commit you’re building up until you’re happy. Conceptually just think of @ (the current revision) and @- (the previous revision) as the working copy and the staged copy, respectively.

palata 1y ago
I feel like I already lost more time reading this than jj would make me win if I switched :-).
- stouset 1y ago
  In the first year of switching I easily saved more time and frustration than the sum total of all of my jj evangelism on HN.

rtpg 1y ago

I usually work, then do `jj split` to review changes I want to make commits to. This generally makes the workflow look like `git add -p`. A decent mental model is that the top-most commit isn't generally going to get pushed up anywhere. It's like your working copy but also you get stashing "for free" (change back to main to make a new commit? All the WIP stuff stays on that branch instead of being carried over to main!)

ethan_smith 1y ago

[flagged]

notmywalrus 1y ago
...no? On all counts. `jj ignore` is not a command. [1] There is no such thing as `.jjignore` files [2], [3]. `--no-snapshot` is not a flag, neither on `jj edit` nor in general. Additionally, it doesn't make sense conceptually --- `jj edit` changes the working copy, which will then propagate changes to the selected commit every time you edit a file. If you want to check out an old commit without amending it, you `jj new` on top of it. If you end up making changes that you don't care about, you can `jj abandon` them. [1]: https://jj-vcs.github.io/jj/latest/cli-reference/ https://jj-vcs.github.io/jj/latest/cli-reference/ [2]: https://github.com/jj-vcs/jj/issues/3525 https://github.com/jj-vcs/jj/issues/3525 [3]: https://jj-vcs.github.io/jj/latest/working-copy/#ignored-files https://jj-vcs.github.io/jj/latest/working-copy/#ignored-fil...

simonmic 1y ago

jj's auto staging isn't always desirable. I feel jj docs and evangelists should make clearer that it's easy to turn off by default, by adding this to ~/.jjconfig: [snapshot] auto-track = "none()"