231–240 of 517 posts
Now that Steve is part of a GitHub competitor to push jj, I see all these posts as just sales pitches.
It is right to be skeptical of me, but I hope to keep that integrity by continuing to talk about things that I believe are legitimately good, regardless of anything else.
I think the mental model is like C vs python. Git gives you a forensic trace back in time. jj gives you a story with chapters. Look under the hood you'll still see forensic map of state transitions, but this not what we want to navigate most of the time. Sometimes we need to rewrite an early chapter to make the latest chapter make more sense.
...and it turns out when you answer these questions differently ('working tree is a commit', 'conflicts can committed) but still want git compatibility, jj kinda falls out of the design space by necessity.
I'm still struggling most with the fact that my day-to-day work involves a git first platform like GitHub. Although jj as a vcs system, it does feel better, working with git through it still feels like a chore, but to be fair I only gave it a day before going back to git. Does anyone have any good resources on how to augment a git flow through the lens of a git hosting platform to work smoothly and still reap the ben…
The jujutsu docs have a page for this - it has everything I needed.
Earlier quoted context omitted.
1. Pagination with a pager is a reasonable default. See `git log`. 2. The native format would be `jj init`. For precedent, see how uv dealt with its pip compatibility: `uv pip install` was obsoleted by `uv add`.
1. No one with good vision would give a single feature two names. It’s dumb. Here is our pager feature. Cool, how do I access it? Oh you set the ui.paginate options of course!! 2. It’s almost like we have some established ways to denote arguments that are pretty popular… ‘jj init —-git’ for example? By using ‘jj git init’ I would expect all of the git compatible commands to be be ‘jj git xxx’ because that is a reason…
The bigger picture here though: `jj git` is the subcommand that prefixes all commands that are git specific, rather than being backend agnostic. There is also `jj git clone`, `jj git fetch`, `jj git push`, etc.
For a different backend, say Google's piper backend, there's `jj piper `.
This means that backend specific features aren't polluting the interface of more general features.
Earlier quoted context omitted.
The only intuitive interface is the nipple. All other things are learned. I feel very comfortable using git. Maybe jj is better, but not seeing is not believing.
> but not seeing is not believing. Classic denying the antecedent :-) https://en.wikipedia.org/wiki/Denying_the_antecedent
Just an expression of what the Missouri state's nickname says.
Anything new or special in jj that allows me to work with large binary files simply? To me, this is still unsolved in terms of providing an elegant solution (e.g. things like Git Large File Storage (Git LFS) are awkward).
(LFS support is in progress though)
Earlier quoted context omitted.
Specific commands don't really showcase the appeal of jj. If anything they might scare someone at first glance. It's the fact that the workflows are intuitive and you never find yourself reaching for help to get something done. You really need to try it to understand it.
The only intuitive interface is the nipple. All other things are learned. I feel very comfortable using git. Maybe jj is better, but not seeing is not believing.
if you don't care about them after accepting this realization... it's fine. git is good enough.
Earlier quoted context omitted.
This isn't true?
It is when I tried it.
Obviously I can’t argue against your lived experience, but it is neither typical nor common. This is quite literally an explicitly-supported use, and one that many people do daily.
For those, who want to/need to keep some files uncommitted, the workaround I found is to put gitignore into some nested directory: mkdir junk echo '*' > junk/.gitignore jj won't track those files under ./junk/ Also might be relevant for claude, since it wants to put its settings into the repo itself as `.claude/`: mkdir junk/.claude bwrap ... --bind "$(pwd)/junk/.claude" "$(pwd)/.claude" ... For some more common file…
Another option is to make a branch with the files that you want to keep around but not push (e.g. stuff specific to your own tooling/editor/IDE), and mark that branch as private. Private commits (and their descendants) can't be pushed.
You then make a merge commit with this branch and main, make your changes, etc. You will have to rebase before pushing so that your branch isn't a descendant of the private commit.
This will involve more work, but it has the benefit that you're actually version controlling your other files.