411–420 of 517 posts
Earlier quoted context omitted.
I find this kind of advice to be a more scathing indictment of an interface than a critic could ever muster: asking users to forego available functionality so that some sense of order can be imposed.
Earlier quoted context omitted.
I stand corrected by this one scenario, but I’ve been using git for over a decade and never found that useful. Just don’t use checkout on a file path, there is no need.
Interesting - I use git checkout constantly, whenever I have a file in another branch or commit that I want to drag into this one wholesale.
One of my favorite jj features is "jj absorb". For each change you've made in the current revision, it finds the last commit where you made a change near there, and moves your changes to that commit. Really handy when you forgot to make a change to some config file or .gitignore. You just "jj new", make the changes, and "jj absorb". No need to make a new commit or figure out where to rebase to. Oh, and not having to…
And If `jj absorb` gets it wrong, you can run `jj undo`. This is such a killer feature to me. I'm not scared to start potentially gnarly rebases anymore because I can painlessly undo.
Earlier quoted context omitted.
In a pure `jj` model, commit might not even be necessary as it's own subcommand (since you could easily define an alias for `desc` followed by `new`). We're still living in a world where most people who would consider adopting `jj` are git users currently, so I wonder if starting with `commit` and then following it up with an explanation of "here's how you can change the commit message without needing to make a new c…
Yes, I do think that the latter is correct now. I tend to learn "bottom-up", so I like the new + describe as a way of learning, but people want to jump in and get going with tools, so commit fits that expectation better.
I love jj, but mostly I use jjui. I would like more uniformity in the way jjui handles commands when you are viewing changes vs when you are viewing files within a single change. Often I just make my changes and leave it there without `new`, as I am not sure which file should go in a single commit. I just leave it there and I interactively commit later. For me to use `new` more, I would like the ability to also simpl…
Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state. Since it's git compatib…
No, you run `jj new` when you’re done with your work just like you’d run `git commit`. You can even just run `jj commit` which is a shorthand for `jj describe && jj new`.
Does JJ really prefer for me to think backwards? It wants me to start with the new and describe command, but with git I first make the changes and name the changeset at the end of the workflow. I also often end up with in a dirty repo state with multiple changes belonging to separate features or abstractions. I usually just pick the changes I want to group into a commit and clean up the state. Since it's git compatib…
https://arialdomartini.github.io/pre-emptive-commit-comments
If you want to have a workflow similar to Git with index, check out the Squash Workflow: basically, you would edit your files in a disposable commit having the same purpose of Git’s index.
Earlier quoted context omitted.
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.
> 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.
If you work this way you're "always" in a WIP state. And if you switch to another spot you won't lose your work, cuz it's persisted.
The end result if you work like this is you don't need stashing, since you get "free" stashing in your commit tree, which is more likely what people want (and if it's not... rebasing is easy so just move the node/`jj duplicate` it!)
`jj edit` exists but I think it's just not what people want in the default case at all. In exchange: rebasing "just works", stashing is not a thing to think about, and you don't lose your work
One of the things that makes jj worth trying out is simply the fact that it is different than git, and having exposure to more than one way of doing things is a good thing. Even if you don't adopt it (and I didn't), it's easy to think that "this way is the only way", and seeing how systems other than your own preferred one manage workflows and issues is very useful for perspective. That doesn't mean you should try ev…
being a good engineer is also understanding when something is a waste of time because the gain is insignificant 99% of the time
On a clean repo:
$ jj
The working copy has no changes.
Working copy (@) : abcdef a53ff9ba (empty) (no description set)
Parent commit (@-): qrstuv 4bc1bf34 the last thing you did
$ jj # shows status (new, modified, deleted, moved, etc.)
$ jj commit -m "made changes"
You only `jj new -r lmnop` if you want to do some work based on the state of the codebase at revision lmnop, rather than the previous revision, which is a figurative branch. No need to manually create and name branches.
As for git history: just do `git log` to see what's actually going on. It's a clean history reflecting your `jj commit`s. You're not going to see all of the stuff the jj machinery does.