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

361–370 of 517 posts

Re: jj – the CLI for Jujutsu

#361

Post by steveklabnik »

fragmede wrote: post #356
MrJohz wrote: post #352

Earlier quoted context omitted.

But branches are not just named pointers to a commit. If they were, then checking out the pointer would be the same as checking out the commit itself. But I can check out a commit and I can check out a branch and depending on which I've done, I'm in two different states. Either I'm in branch state, where making a commit bumps the branch pointer and means the commit will be visible in the default log output, or I'm in…

> these two states look completely identical No they don't. As you noted, one state is "detached head" and any competently set up shell PS1 will tell you that, or that you're on a branch by displaying the name of the branch vs the commit. > Creating new commits on anonymous branches is perfectly normal Sorry, that that's an example of more intuitive behavior on jj's partc, you've lost me. I've done that intentionally…

> For someone new to version control, committing to an unnamed branch doesn't seem like a desired operation no matter which system you're using.

We have data on this! I can't cite anything public, but companies like Meta have to train people who are used to git to use tools like sapling, which does not require named branches. In my understanding, at first, people tend to name their branches, but because they don't have to, they quickly end up moving towards not naming.

> What's wrong with requiring branches to be named?

Because it's not necessary. It's an extra step that doesn't bring any real benefits, so why bother?

Now, in some cases, a name is useful. For example, knowing which branch is trunk. But for normal development and submitting changes? It's just extra work to name the branch, and it's going to go away anyway.

Re: jj – the CLI for Jujutsu

#362

Post by steveklabnik »

wolttam wrote: post #360
steveklabnik wrote: post #207

Earlier quoted context omitted.

Nothing will break. You just keep using the git backend if you want to keep being compatible with git. > it’s tough to imagine why it’s worth pursuing a native and presumably incompatible backend. Well, there's no active work on a "native" backend. There are basically three backends right now: 1. the git backend 2. A simple backend used for tests, you can think of it almost like a mock backend, you wouldn't use it fo…

That makes sense, thanks for the reply. For some reason I was under the impression that there was an active drive towards a backend that was not git.

You're welcome. I think it's natural to assume that.

Re: jj – the CLI for Jujutsu

#363

Post by tom_alexander »

nightski wrote: post #323
saghm wrote: post #294

Earlier quoted context omitted.

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

I stand corrected by this one scenario, but I’ve been using git for over a decade and never found that useful. Just don’t use checkout on a file path, there is no need.

If you don't run checkout on file paths, how do you undo changes to specific files that you haven't committed yet? Like you've edited but not committed , , and . You realize your edits to are a mistake. I'd just run `git checkout ` to revert those changes, what do you do?

It is also really useful when you realize you want to be the version from a commit two weeks ago. I guess you could always switch to the branch 2 weeks ago, copy the file to /tmp/, switch back, and copy the file into place, but `git checkout c23a99b -- ` is so quick and easy. Or does this example not fall under the "dont run checkout on a path" since it is taking a treeish first before the path?

Re: jj – the CLI for Jujutsu

#364

Post by kps »

tom_alexander wrote: post #346
arianvanp wrote: post #37

Earlier quoted context omitted.

You can disable the auto staging of new files since recently which removed the main grype for me

ooo that will be a nice improvement. So many times I've run `jj status`, then saw a file I wanted gitignored, so I'll edit my gitignore, but the file has already been added to the repo so I have to `mv /tmp/ && jj status && mv /tmp/ .` to get the file out of the repo.

    [snapshot]
    auto-track = '~glob:**/*'

Re: jj – the CLI for Jujutsu

#367

Post by tom_alexander »

steveklabnik wrote: post #350
tom_alexander wrote: post #346

Earlier quoted context omitted.

ooo that will be a nice improvement. So many times I've run `jj status`, then saw a file I wanted gitignored, so I'll edit my gitignore, but the file has already been added to the repo so I have to `mv /tmp/ && jj status && mv /tmp/ .` to get the file out of the repo.

You can `jj file untrack` instead of that mv bit.

Oh neat, thanks! I (clearly) did not know that command.

Re: jj – the CLI for Jujutsu

#368

Post by MrJohz »

tom_alexander wrote: post #141
saghm wrote: post #84

Earlier quoted context omitted.

How are you "checking out" the old commit? It sounds like you're using `jj edit`, which I'd argue does what it says on the tin. Switch to using `jj new ` and your problem goes away.

That avoids the problem for the specific workflow of checking out an old revision (and it was what I was describing with checking out a new branch off the old commit and adding a blank commit to that branch), but another way this design bites me: At work I am constantly jumping around numerous repos because I might be working on repo but then someone on my team will ask for help with repo . So I'll turn on screen sha…

I think the right intuition to have with jj is that `jj st` should show an empty change unless you are actively working on something. `jj commit`, as mentioned below, is a good example of this - it automatically creates a new change and checks it out. The "squash flow" also does this well - you use the branch tip as a staging area and squash work into other changes on the branch as you go along. Either way, once the work is finished, there's an empty change at the tip of the branch.

This is also supported by jj implicitly - whenever you check out a different commit, if the change you were on is empty, has no description, and is the tip of a branch, it's automatically deleted to clean things up for you.

Re: jj – the CLI for Jujutsu

#369

Post by naasking »

andrewdea wrote: post #348
naasking wrote: post #340

Earlier quoted context omitted.

> then it's irrelevant to those of us who have been lucky to find and learn sensible UXs Only if you're a solo dev that doesn't work on a team or have to mentor new devs that haven't developed good intuitions for this. This strikes me a lot like the C vs. safer programming language debate all over again.

When I mentor new devs, I explain to them how I use git. Sometimes I show them the workflow in magit, which makes it easier to visualize things. But mostly I just show them how their intended actions map onto the relevant CLI commands and I tell them to figure out how those map onto their porcelain of choice. I've developed this intuition thanks to magit, but I don't think magit is necessary. This approach seems pref…

> When I mentor new devs, I explain to them how I use git.

Now imagine not needing to do that.

> I don't see how. Safer programming language address a clear problem in C

Being productive in C means training and experience in avoiding the footguns of C. See above.

Re: jj – the CLI for Jujutsu

#370

Post by steveklabnik »

dmitshur wrote: post #366

What 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.
Post reply on HN