Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

jj – the CLI for Jujutsu

steveklabnik.github.io

Post reply on HN
Print view View original

291–300 of 517 posts

Re: jj – the CLI for Jujutsu

#291

Post by sam_goody »

I use the CLI often enough, but still most of my time is in a GUI. It just makes the diffs easier, the flow simpler, etc.

As such, I wanted to break into jj via the GUI, and only adopt the command line after I could visualize the concepts and differences in my head.

Alas, the GUI I tried - a VSCode plugin - did more to confuse me than to help, and it made it very easy to catastrophically rewrite the history by accident. I tried another UI and it kept failing and leaving me with cleanup work. I couldn't find a third UI that looked promising.

So, I gave up. One less jj user on the planet - no biggie. But I really wonder if it would be worth the effort for some of the jj pushers to try to get a proper UI in place - I bet I am not the only one that likes to learn visually.

Re: jj – the CLI for Jujutsu

#292

Post by newsoftheday »

porksoda wrote: post #131
aftbit wrote: post #106

Nope, git is good enough, and is the global standard. We don't need more new VCS.

Great opinion. Have you tried it? It takes just 30 minutes to wash all the Stockholm syndrome off of you.

Their opinion is great, why do you feel like you need to counter it with [but, but jj is for the clean masses, not the unclean users].

Re: jj – the CLI for Jujutsu

#293

Post by newsoftheday »

surajrmal wrote: post #102
PUSH_AX wrote: post #29

If it ain't broke...

I think there are a lot of things that work well but still get improved versions. For example, grep works well but there are plenty of better versions these days.

Really? I use grep multiple times per day, works great, I've seen no need to change. Same with git.

Re: jj – the CLI for Jujutsu

#294

Post by saghm »

webstrand wrote: post #256
saghm wrote: post #205

Earlier quoted context omitted.

> 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.

That's my overall point: the argument itself (with respect to the current state of the repo) is what determines the behavior. I don't think this is anywhere close to as intuitive as commands that only ever accept one "type" of argument (and erroring if it's different).

Re: jj – the CLI for Jujutsu

#297

Post by saghm »

steveklabnik wrote: post #200
tom_alexander wrote: post #188

Earlier quoted context omitted.

Ah, thanks! That's a command I haven't learned yet, so I'll have to check it out. I learned jj from the tutorial that was posted and I don't think it covered `jj commit` at all.

I didn't cover it for various reasons, but I think it's good to teach now that I've had more time to consider this sort of thing, so the next iteration will likely start by beginning with jj commit.

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 commit" and "here's how you can make a new commit without changing the name of the current one" would end up fitting people's expectations better.

Re: jj – the CLI for Jujutsu

#298

Post by Aperocky »

rattray wrote: post #268
Aperocky wrote: post #264

With agents, my go to is now have multiple of the same repository and each agents must work on a separate one. Preventing dirty workspace by solving the co-work problem to start with. merges are much more trivial than trying to make agents remember which branch or which folder it is supposed to work on. Disk space is cheaper than mental anguish and token usage.

What's your naming scheme?

REPO_NAME_0

REPO_NAME_1

REPO_NAME_2

REPO_NAME_3

Re: jj – the CLI for Jujutsu

#299

Post by newsoftheday »

BeetleB wrote: post #109
palata wrote: post #65

I tried jj for a few months. It was fun to learn a new thing, but I haven't had a single case of "wow, this would have been a pain with git". Then I went back to git (it's been 6 months now) and I haven't had a single case of "this is so painful, I wish something better existed". So it felt like the XKCD on "standards": I now have one versioning system, if I learn jj I will have two. What for? Don't get me wrong: it'…

For me, it was kind of the same. I used jj. Really liked it, but did not find it all that much better than git. Then, for various reasons, I switched back to git. By day 2, I was missing jj. Stuff like "jj undo" really is nice.

[dead]

Re: jj – the CLI for Jujutsu

#300

Post by chriswarbo »

IshKebab wrote: post #97
dgb23 wrote: post #2

The last paragraph might be the most important one: > There's one other reason you should be interested in giving jj a try: it has a git compatible backend, and so you can use jj on your own, without requiring anyone else you're working with to convert too. This means that there's no real downside to giving it a shot; if it's not for you, you're not giving up all of the history you wrote with it, and can go right bac…

Big caveat: do not try to use Git and JJ in the same directory. It's probably fine if you only use JJ, but if you mix them you will horribly break things.

I suppose it depends what you mean by "horribly break things".

The only thing I've noticed is that `jj` will leave the git repo with either a detached HEAD, or with a funny `@` ref checked out.

I don't think that would trouble someone who's experienced with git and knows its "DAG of commits" model.

For someone who's less experienced, or only uses git for a set of branches with mostly linear history (like a sort of "fancy undo"), I could imagine getting a shock when trying to `git commit` and not seeing them on any of the branches!

Post reply on HN