5 ms·

Just don't ever use `edit`, use `new` instead; then your changes are tracked without making a mess. I think that's much nicer than juggling stashes in git.

• VMG 5mo ago
  ... unless you actually want to edit a change!
  • throawayonthe 5mo ago
    well, you can do jj new <revision>, make your edit, and then do jj squash which will add the changes to the prev revision i do this for example when i want to see a specific edit highlighted in my editor, it's a nice workflow i think
    • Aeolun 5mo ago
      This is exactly how someone explained Git to me 12 years ago or so, and I’ve finally wrapped my head around it. Not changing now.
      • hacker161 5mo ago
        [flagged]
      • mh- 5mo ago
        If I'm understanding the thread correctly, I have a git alias to `git commit --amend --no-edit`, for exactly this workflow. When I'm hacking on something locally and want to just keep amending a commit. I only ever do this if it's HEAD though.
        • steveklabnik 5mo ago
          Yes, one way to think about jj in a sort of low-level way is that every jj command does the equivalent of that, every time. (You can also set up watchman and have that happen on every file change...)
  • arccy 5mo ago
    still use new, and then squash your changes in. that way you can actually see what changes you made
  • incognito124 5mo ago
    then you `new` & `squash` :)
  • BeetleB 5mo ago
    I go back and forth between the two approaches, but because of the whole "accidentally made some temporary changes and now it's a pain to separate/undo them because not all changes were temporary", I also usually do a jj new and then jj squash.
• embedding-shape 5mo ago
  > Just don't ever use `edit`, use `new` instead As a git-ist (?), if I'd ever move away from git, it would be to avoid tooling that has idioms like this (like git too has), if `jj` just gonna surface a bunch of new "bad ideas" (together with what seems like really good ideas), kind of makes it feel like it isn't worth picking up unless you don't already know git.
  • surajrmal 5mo ago
    jj edit has good use cases, but it's not the default command you need. For instance, say you were working on some changes but had to change branches for a few minutes to do something. If you didn't manage to create a commit and want to go back to the previous staging area, you would use the jj edit command rather than jj new. It's very intuitive in my experience, something I can't say is true for managing git commits (unless you've spent years forcing it into muscle memory). I never need to run jj help. I run help commands with git all the time.
  • dzaima 5mo ago
    `edit` is still useful; just, for ..editing (!) something, instead of viewing it. If you have some unfinished changes at the tip and want to temporarily checkout something 2 weeks ago, you `jj new` to there (similar to `git stash; git switch whatever`), and then later `jj edit your-old-tip` to go back (equivalent to `git switch main; git stash pop`; I think `jj edit` being an extended replacement for stash-popping things is a reasonable way to think about it). (and if you don't have any uncommitted changes, you always `jj new`) jj also has a concept of immutable commits (defaulting to include tagged commits, and trunk at origin, which it'll disallow editing as a layer of defense)
  • saghm 5mo ago
    The idiom here is use `edit` if you want to edit a commit, and use `new` if you want to make a new commit. This works identically whether you specify the commit via branch name or commit id. I'm not sure why people are saying not to use `edit` ever. It's basically just a shorthand for staging and amending changes in an existing commit, and there's still a use case for that; it's just not "I want to see the changes on this old branch".
• busfahrer 5mo ago
  Once you get your head around it a bit, doing a new in this circumstance will be second nature, since you will have realized that a `new XYZ` in jj leads to the same underlying git state as a `git checkout XYZ` in git