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

441–450 of 517 posts

Re: jj – the CLI for Jujutsu

#441

Post by rstuart4133 »

klauserc wrote: post #247
steveklabnik wrote: post #170

Hey folks! So, I haven't updated the tutorial in a long time. My intent is to upstream it, but I've been very very busy at the startup I'm at, ersc.io, and haven't had the chance. I'm still using jj every day, and loving it. Happy to answer any questions!

jj automatically hides "uninteresting" changes. Most of the time, this is good. Occasionally, I need to see more changes. It is not obvious to me how I get jj to show me elided changes. I mean, sure, I can explicitly ask jj to show me the one ancestor of the last visible change, and then show me the ancestor of that one, etc. Is some flag to say: "just show me 15 more changes that you would otherwise elide"?

I'm not sure what you are asking, but you want to look at how a particular jj change-id evolved over time, use `jj evolog`. By default that evolution is hidden. The `change-id/N` syntax has uses beyond conflicts.

Re: jj – the CLI for Jujutsu

#442

Post by skydhash »

ibejoeb wrote: post #435
skydhash wrote: post #434

Earlier quoted context omitted.

If I really wanted that, I could create an alias like alias.save="!git add -A; git commit -m" And then use $ git save "made changes"

You could. That's not the point. I suggesting that if you want to try jj, try it based on its affordances, not by comparing it to how you'd do it differently with git. Most of the tutorials start with git and try to teach you how to change your thinking. I think the project would find many more fans if it didn't make such a big deal about being kinda like git.

I did try it, but it was not my cup of tee. Git fits my mental modal better. Branches are experiments, commits are notes in my lab notebook, stashes are notes in scrap of papers, the staging area is for things that I plan to note down and the working tree is the workbench. Then every once in a while I take the notebook and rewrite stuff in it or update it to fit recent changes in the canonical branches. I use magit so the actual operations are just a few quick key presses.

I could probably do the same thing with jj, but why use a new tool when the old thing works well, has myriad of integrations, and it's fairly standard.

Re: jj – the CLI for Jujutsu

#443

Post by steveklabnik »

rstuart4133 wrote: post #433
steveklabnik wrote: post #342

Earlier quoted context omitted.

What "not supported" means with submodules specifically is that jj doesn't have commands to manage them. You can use git commands to manage them, and it does, in my understanding, work. There's just no native support yet. This is sort of similar to how you can create lightweight tags with jj tag, but you need to push them with git push --tags.

> and it does, in my understanding, work. I use submodules with jj, and jj saves and restores submodule hashes perfectly. What it doesn't do is manipulate the sub-repository from its parent. You can do that yourself using jj or git of course, which is what I ended up doing using a few scripts. The result ended up being more reliable than using git's submodule commands directly. They can take all the time in the world…

Gotcha, thank you for the context.

Re: jj – the CLI for Jujutsu

#444

Post by rstuart4133 »

zingar wrote: post #117

"It's more powerful and easier" is a great claim, but I need examples in this opening page to convince me of the pain I could save myself or the awesome things I'm living without.

What makes jj better requires a mindset change. When you start with jj, you use it as an alternate porcelain for git, meaning you just use the jj commands that map to the way you used git. You have to let go of that mindset. Until you do, you are still using those old git commands; they are just have prettier clothing. The prettier clothing is not worth the effort.

I don't know how to explain a mindset to you, so I'll give one example of something that sounds so grand, it seems impossible. (There are so many unusual aspects to jj, but hopefully this is one you can immediately relate to.) Git famously makes it hard to lose work, but nonetheless there are commands like `git reset --hard` that make you break out in a sweat. There is no jj command that destroys information another jj command can't bring back. And before you ask - yes of course jj has the equivalent of `git reset --hard`.

Re: jj – the CLI for Jujutsu

#445

Post by jhhh »

BeetleB wrote: post #125

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…

After hearing about a workflow that used absorb I wrote a simple git version I called 'squash-index' in about 15 lines of bash in a few minutes. Since git allows subcommand extension I just made an executable 'git-squash-index' and everything worked as if it was a builtin subcommand. I get that initial ergonomics are important for new tools but if the only novel feature is reified merge conflicts it doesn't really seem worth making the switch. No one needed to evangelize git to people like myself who had worked with a variety of old version control systems (cvs, svn, etc). It was just obviously much, much better. jj seems like it streamlines certain things, and might be worth learning for new users who have no git experience, but doesn't really differentiate itself enough for people who've been using git for a long time.

Re: jj – the CLI for Jujutsu

#446

Post by rstuart4133 »

misnome wrote: post #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 t…

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

All true. I ended up writing my own `jj push` and `jj pull` aliases that automated all this. They aren't simple aliases, but it worked. `jj push` for example "feels" very like `git push --force-with-lease`, except if you've stacked PR's it pushed all branches your on. It hasn't been a problem since.

I ended up wondering if they deliberately left the `jj pull` and `jj push` commands unimplemented just so you could write something custom.

> All files automatically committed is great until you accidentally put a secret in an unignored file in the repository folder.

    jj abandon COMMIT && jj git garbage-collect
> 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

True, but how is this different to any other VCS?

Re: jj – the CLI for Jujutsu

#447

Post by MrJohz »

skydhash wrote: post #438
MrJohz wrote: post #421

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

Or you make tools that are easier to use, so that you can spend that week learning something more useful than the finicky details of branch vs detached head checkouts.

Re: jj – the CLI for Jujutsu

#448

Post by 8n4vidtmkvmk »

ibejoeb wrote: post #420

A lot of the discussion focuses on differences from git and how it uses the git storage strategy under the hood. Honestly, I think you should just ignore all of that. Don't think about git. Here's a workflow that'll get you through your daily usage: On a clean repo: $ jj The working copy has no changes. Working copy (@) : abcdef a53ff9ba (empty) (no description set) Parent commit (@-): qrstuv 4bc1bf34 the last thing…

Sometimes i like to jj describe before writing any code. It helps with mental clarity what i intend on writing or helps if i have to run away mid coding session (description will show in log so i can find it again)

In this scenario I'd instead jj new at the end, after im finished and ready to move on to the next thing.

Re: jj – the CLI for Jujutsu

#449

Post by rstuart4133 »

QuiDortDine wrote: post #133

> $ cargo install jj-cli@0.23.0 --locked I won't install Rust just to test your software. Make a debian package like everyone else.

They do publish binaries they work perfectly well on Linux. No need for cargo:

https://github.com/jj-vcs/jj/releases/tag/v0.40.0

Re: jj – the CLI for Jujutsu

#450

Post by cynicalsecurity »

tomhow wrote: post #296
cynicalsecurity wrote: post #19

[flagged]

Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something. https://news.ycombinator.com/newsguidelines.html

I'm sorry, it's hard to say anything good about a project that brings nothing new to the table while desperately trying to replace a well-established industry standard. Such attempts look annoying at best and irritating at most. At the very least the person behind the project could have been more humble in pushing it, and instead of presenting it as a "git killer" causing everyone only headache he could have had 1) polished it 2) pointed out precisely what "problems" with git his project solves. None of those were clearly stated; instead, the shared page is simply a shameless plug for wasting everyone's time.

Okay, next time I'm simply going to ignore it, but allowing this kind of posting only works against the HN. I'm not sure if you've noticed, but even the original post title was annoying enough that someone from the moderators had to replace it.

Post reply on HN