Live data from Hacker News

jj – the CLI for Jujutsu

steveklabnik.github.io

251–260 of 517 posts

Re: jj – the CLI for Jujutsu

#251
The problems with jj that led me to abandon are:

- All of everything good about it breaks down the instant you want to share work with the outside world. It's git on the backend! Except there isn't any concept of a remote jj so you have to go through the painful steps of manually naming commits, pushing, pulling, then manually advancing the current working point to match. And in doing so, you lose almost everything that gives it value in the first place - the elegant multi branch handling, anonymous commits, the evolog. Even if you want to work on the same project on two machines your only choice for this is without breaking everything via git is to rsync the folder. Yes, you can write alias to do all this like git. I might as well use git if I can't use the nice features.

- All files automatically committed is great until you accidentally put a secret in an unignored file in the repository folder. And then there is no way to ensure that it's purged (unlike in git) - the community response as far as I can tell is "Don't do this, never put a file that isn't in gitignore".

- And adding to .gitignore fails if you ever want to wind back in history - if you go back before a file was added to .gitignore, then whoops now it isn't ignored, is all part of your immutable history, and disappears if you ever switch off of that new commit state.

Re: jj – the CLI for Jujutsu

#252
I was already pretty happy with svn to be honest, I dont see myself switching away from the industry standard today for no substantial reason. in my opinion git was only able to change the standard thanks to github and a popular author (i love git and its branching, but I dont think it would have been enough if it was just for that). I personally believe its going to be very difficult for jj to replicate that.

Re: jj – the CLI for Jujutsu

#253

Earlier quoted context omitted.

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…

You're right that, looking solely at `init`, a flag could make sense to choose the backend. 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 a…

>There is also `jj git clone`, `jj git fetch`, `jj git push`, etc.

If the compatibility isn’t automatic… why would I bother with jj commands here at all? “Git with extra steps”

Re: jj – the CLI for Jujutsu

#254
I followed steve's excellent tutorial about two months ago, and haven't looked back. I have never felt so competent at git (vcs rather) as I do now. jj is so much simpler and easier for me to reason about.

Re: jj – the CLI for Jujutsu

#255
Seems interesting, but tbf, I only really use a small subset of git commands as it is... I've tended to practice a few workflows that just reduce the overhead and risk for conflicts.

Re: jj – the CLI for Jujutsu

#256
post #205

Earlier quoted context omitted.

It's not "wildly" different behavior based on the thing it's pointing to. In all 3 cases, the command is pointed at a commit and the behavior is the same. Once you know that branches/HEAD are just named pointers to commits, then it becomes obvious you are always just working on commits and branches/ids/HEAD etc are just ways of referencing them.

> In all 3 cases, the command is pointed at a commit and the behavior is the same echo "something" >> foo.txt git checkout foo.txt What's the name of the branch this is pointed at? If I have to run another git command to find out, then it's not "pointed" at it.

If you don't provide it a it reads from the index (staged files). So you're right its not really pointed anywhere, since the index isn't a ref.

Re: jj – the CLI for Jujutsu

#257

Earlier 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…

All of these features sound like the recipe for a confusing nightmare! "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." "Similar to stashes, but each "stash" is just a normal branch that can have multiple commits. If I wa…

Yeah I legit do not understand the appeal. I’m willing to be wrong but it’s not clicking with me at all

Re: jj – the CLI for Jujutsu

#258

Nobody is asking for a git replacement? I keep seeing these posts and I don't know who wants them.

The feeling I get with jj is it is almost like people are trying to convince others why jj is superior instead of just sharing that jj exists and let others decide themselves. It seems like every few months there is a jj post on HN which devolves into the narratives of “git works for me” and “but jj is better at X”.

Re: jj – the CLI for Jujutsu

#259
Reading threads like this and the GitHub stacked PRs just makes me feel like an alien. Am I the only one that thinks that commits are a pointless unit of change?

To me - the PR is the product of output I care about. The discussion in the review is infinitely more important than a description of a single change in a whole series of changes. At no point are we going to ship a partial piece of my work - we’re going to ship the result of the PR once accepted.

I just squash merge everything now. When I do git archeology - I get a nice link to the PR and I can see the entire set of changes it introduced with the full context. A commit - at best - lets me undo some change while I’m actively developing. But even then it’s often easier to just change the code back and commit that.

Post reply on HN