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

121–130 of 517 posts

Re: jj – the CLI for Jujutsu

#121

Post by saghm »

nomel wrote: post #104
smweber wrote: post #42

Earlier quoted context omitted.

jj edit is the biggest jj footgun I can think of, as other comments said just use jj new. But also if you do accidentally edit or change something jj undo works surprisingly well. I found when using jj it worked best for me when I stopped thinking in commits (which jj treats as very cheap “snapshots” of your code) and instead focus on the “changes”. Felt weird for me at first, but I realized when I was rebasing with…

> preventing you from accidentally rebasing changes that have been shared. I think this ruins it for me then. I push my in-progress work, to my in-progress branches (then git-squash or whatever later, if needed). It makes switching between (lab) computers, dead or not, trivial. Is there some "live remote" feature that could work for me, that just constantly force pushes to enabled branches?

Nothing stops you from doing the equivalent of `git push --force` in `jj`. The flag is just named differently: `--ignore-immutable`. This is a global flag though, so it's available to all commands, and `jj` requires it whenever you're making changes to immutable commits, even locally. I'd argue that this is one of the killer features of `jj`, since by comparison `git rebase` treats everything the same whether you're squashing your own local commits on a feature branch or messing with the history of `main` in a way that would break things for everyone.

Re: jj – the CLI for Jujutsu

#123

Post by verdverm »

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…

Unless you use LFS, submodules, or hooks at your org.

Re: jj – the CLI for Jujutsu

#125

Post by BeetleB »

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 deal with merge conflicts now is awesome. My repository still has merge conflicts from months ago. I'll probably go and delete those branches as I have no intention to resolve them.

Re: jj – the CLI for Jujutsu

#126

Post by SV_BubbleTime »

>You can request to not use the pager by using jj st --no-pager, or if you hate the pager and want to turn it off, you can configure that with

    $ jj config set --user ui.paginate never
In one feature they can’t help themselves from calling it two different things already.

Why do this? Why can’t the very clearly smart people making things step 1/2 step outside themselves and think about it like they are the users they want?

Earlier they talk about the native format and how it isn’t ready… so that to start you need

    jj git init
… but… if they’re planning a native format that makes no sense as a command. It would be ‘jj native init’ later?

Early planning keys/plans imo but those rarely change so as to not accept your early adopters.

These seem like small things but to me it’s a warning.

Re: jj – the CLI for Jujutsu

#127

Post by saghm »

jeremyjh wrote: post #67
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…

But this is not true. They are interoperable but far from seamless. Those features mainly support migration use cases or things like git deployment from an repo managed in jj. Operations git does are not in jj’s log. You have to constantly import them. The project recommends a single primary interface.

It's been over a year since I last used git manually in the CLI, and I've exclusively worked with git remotes. The only time I had any friction was on a team where stale code-gen output was checked into the repo and for whatever reason no one was willing to either add it to the `.gitignore` or commit (pun intended) to keeping it up to date, meaning that I had to manually remove the changes from when I compiled before pushing. I would have argued in favor of adding to .gitignore or keeping it up to date even if I didn't use `jj` though because I think having stale output checked in is just silly.

Re: jj – the CLI for Jujutsu

#130

Post by saghm »

jeremyjh wrote: post #96
maleldil wrote: post #83

Earlier quoted context omitted.

If you constantly switch between the two, you're going to have a hard time, but you can take a git repo, try jj for a while, and if you decide to go back, you don't lose anything.

Right, but that’s different from working in a team environment where everyone else continues using git.

How so? I've used `jj` locally on teams where most (if not all) of the other team members were using git, and they only found out I was using `jj` when I told them.
Post reply on HN