Earlier quoted context omitted.
You would have had to run `jj edit` in order for this to happen, so I think it's a stretch to say you didn't ask for the edit? This is the main difference though: in git files can be `staged`, `unstaged` or `committed`, so at any one time there are 3 entire snapshots of the repo "active". In `jj` there is only one kind of snapshot (a change) and only one is "active" (the current working directory). When you make chan…
Thanks for the explanation! I wish I could edit my comment to reflect the truth.
jj – the CLI for Jujutsu
501–510 of 517 posts
Re: jj – the CLI for Jujutsu
#502Re: jj – the CLI for Jujutsu
#503Earlier quoted context omitted.
A couple things off the top of my head: - You aren't forced to resolve rebase/merge conflicts immediately. You can switch branches halfway through resolving conflicts and then come back later and pick up where you left off. You can also just ignore the conflicts and continue editing files on the conflicted branch and then resolve the conflicts later. - Manipulating commits is super easy (especially with jjui). I reor…
> So anything that would be destructive in git (e.g. rebase, pull, squash, etc) can be undone. It’s possible to recover from these with git reflog, though.
E.g. if I rebase some stacked branches then I want to undo it, with git I would reset each branch separately.
With jj you can timetravel the state of the repo in ine command
Re: jj – the CLI for Jujutsu
#504What is the current story for serving jj repositories over HTTPS? Git has https://git-scm.com/book/ms/v2/Git-on-the-Server-The-Protoco... . Does jj have something better, equivalent, or nothing (at this time) at all?
Unless you're at Google (or writing your own backend), jj talks to a git server, and so you'd just do exactly that: host a git repo over https.
[1] https://pkg.go.dev/github.com/shurcooL/home/internal/code#Ne...
[2] https://pkg.go.dev/github.com/shurcooL/home/cmd/githook/pre-...
Re: jj – the CLI for Jujutsu
#505Re: jj – the CLI for Jujutsu
#506Earlier quoted context omitted.
i apologize if my comment came across as accusing you of claiming superiority and failing your intention. it was not meant to do that. if there is any accusation then it is the general assumption that jj is better that can be felt in the overall tone of this discussion thread. your examples show a particular aspect of jj, and to me they demonstrate that jj isn't better across the board for a certain group of users at…
Heh, sorry, I guess you triggered my defensive "book-length response" reaction. Here's the next book: As you say, jj uses git primives so the core data model is the same. I say "core" because jj subtracts out the staging area and stash and adds in "changes" and the operations log. But otherwise, your understanding of the git data model translates seamlessly, with one exception: git-style branches aren't really a thin…
removing the staging area and the stash and "emulating" them with real commits for one simplifies the model, but it also upgrades them to first class citizens because you can treat them like every other commit. i think this adds a lot of power to manipulate the history. on the other hand changes and operations log don't add new primitives but are just additional pointers to track the history.
so in summary: less complexity, more tracking, cleaner commands (like restore instead of checkout to fix files)
somewhere a comment stated that git history is more static because it is not so easy to move commits around. i never felt that. i made copious use of rebase and interactive rebase to shove commits around as i liked. in the end i know that a rebase is successful when the diff between the old state and the new state is empty. but you have to understand how git works in order to feel comfortable doing this. it looks like jj makes this easier because it looks like it adds more safeguards. in git for example i would often tag a state before starting a complex operation, despite the reflog so that i could keep track of the changes and easily see what to throw away if the operation failed, so that i could start over. sometimes i redid a rebase two or three times because the outcome was not what i wanted or i messed up somewhere. it was never a big deal because i know how it works. but it was always something that i felt not everyone had the courage to try.
i installed jj last night and i look forward to an opportunity to try it.
Re: jj – the CLI for Jujutsu
#507Earlier quoted context omitted.
Unless you're at Google (or writing your own backend), jj talks to a git server, and so you'd just do exactly that: host a git repo over https.
I am at Google, but that's probably not relevant since the reason I was curious about this is that my personal website currently implements a git server over HTTPS[1], and git's CLI/API for that is not the friendliest[2]. It sounds like jj hasn't reached the point of tackling this problem space yet, which is okay. Thanks for confirming I wasn't missing out on something. [1] https://pkg.go.dev/github.com/shurcooL/home…
You should be able to use jj with your server just fine.
Re: jj – the CLI for Jujutsu
#508Earlier quoted context omitted.
The only thing that changed in the two things you wrote was `ranch` -> `cdef`. Every other part of that PS1 output was the same. Now put yourself in the shoes of a git novice and ask yourself if you'd always notice the difference. At least from my experience, they often don't, especially if they're concentrating on something else, it if they're using an IDE and the visual information about which branch/commit is chec…
> Now put yourself in the shoes of a git novice Sometimes it seems to me that's only in SWE we allow people to proceed in the workplace without any training. There's enough learning material that people should take a week or something to practice git and not be git novice anymore.
Re: jj – the CLI for Jujutsu
#509Earlier quoted context omitted.
Did you mean inherent complexity instead of incidental complexity? I think the inherently complex things in git are (1) the content-accessible object store, snapshots, plus the merkel tree approach to keeping track of commits and parenthood, (2) merges, rebases, and resolving conflicts between two different changes with a common ancestor, (3) possibly syncing commits between different remotes, although I think Git's…
I think you need to setup something like magit, tig, and maybe lazy git, to truly see the power of git. Most people don't do version control other than snapshotting things every once in a while. They might as well use git inside cron. A patch is an idea to take the code from a state to another state. It contains both the mechanical work, the intent, and extra metadata. It's essential when doing distributed developmen…
Re: jj – the CLI for Jujutsu
#510Nope, git is good enough, and is the global standard. We don't need more new VCS.
Might be true, but Subversion was also good enough and a de-facto standard.
I'd be happy to be proven wrong. You won't get there by designing a solution that is more ergonomic (if jj even is), but rather by designing one that solves problems that git doesn't solve. Also, you probably need to get some big and important software (like Linux, for git) to switch to using it instead of git.
Even then, I'm usually _not_ an early adopter of something as pivotal as a VCS. This isn't something that's easy to rip out or rewrite later. It shapes my workflow at a deep level and holds the history of my changes in its database. Only once it's being used by 25-50% of projects I encounter daily will I consider moving stuff I control to it.
I have deep scars from mercurial lol.