Hacker News Reader

Comment by baq | Hacker News Reader

> My concern isn't just about pushing upstream. What I'm saying is that the typical change to a file shouldn't be committed to my local repo until I indicate that it's ready.

jj doesn't have the concept of a non-committed file.

instead you don't track the HEAD as the tip of the branch (@ in jj), you track HEAD^ (jj: @-) or something earlier and since jj rebase isn't dumb as a rock you can relatively easily keep the working set of changes (as in, multiple commits/WIP branches; not necessarily the index or the working copy) on top of what you are pushing and squash or advance the branch (bookmark).

I'm reiterating because it's a very important and super confusing for advanced git users: there is no uncommitted state in jj and yes, it does make sense, but you need to stop thinking in git.

View on HN

Can't this be a security risk as there might be secrets that should never be recorded by jj (You can probably configure this, but I want my software to only do what I tell it to, not do everything until I tell it not to.)

How does that work in practice, is there a daemon running constantly and monitoring? How does that interact with other users and changes from other computers?

Every jj invocation stores a snapshot before doing anything else - thus anytime you run jj, you tell it to store a snapshot in the local repo.

I don't see a problem with secrets TBH. .gitignore is respected if that's what you have in mind. Otherwise store your secrets out of tree (you probably should with git too, anyway.)

Right now I can mess around like I want, because I am in charge what gets tracked, I need to specify it explicitly. This would loose that.

this is not as important as you're used to. I've been there, I've used git since early 2010s and yes autostaging was preposterous at first. in practice, it's barely relevant: the workflow changes from 'I pick what is tracked' to 'I pick what is pushed'.

I'm not sure if objects won't get pushed accidentally. I would place the boundary at object creation not upload. Also you might copy the repo, then you also might leak an accidentally created object.

to each their own. you can argue in theory, in practice it is just not a problem.

You know your evangelists have gone haywire when they're explaining that your requirements are wrong instead of listening.

I don't think that's a fair characterization.

It's more that there isn't really a big difference between the workflow of

    # you're on
      staging area
    @ commit A
    # make some untracked changes and console logs you don't wanna commit
    git add -p && git commit # select only what you want

    # you're on
    @ empty commit 
    | commit A
    # make some local changes (which are tracked in @)
    jj commit -i # select only what you want

You're still "in charge what gets tracked" if you treat the last @ commit as your local playground, exactly the same as the staging area. The only difference is that you can use exactly the same tools to manipulate your "staging area" as other commits. The only difference being that you can manipulate your staging area with the same tools as any other commit.

Wait, what happens when there is a multi-GB file laying around and a jj command is being invoked? Does it start to scan it or is there some threshold. What does it do with cyclic hard-/sym-links?

There's a (configurable, easily bypassed) limit for newly created file size to catch that common mistake.

I'm far from being an evangelist. I'm trying out jj in one repo out of several and it's far from perfect - but it is useful though, and it does make sense. The requirement of being able to not commit everything by default is simply not necessary from a logical standpoint; if anything, it is itself evangelism that the git way is the right way. The truth is both work just fine, which has been my point all along.

Secrets and client data. Regulated environments are very serious about client data. They can't go into source control either.

You can't change example.com/foo to point to example.com/baz and have it exist in source control. So to make the change you have to ignore every file that contains that string, test, then unignore. Or you have to make sure to absolutely remove every reference you've added to the merkle tree. Or you have to completely nuke your source control database after testing.

If you buy a used laptop hard drive from a remote worker at $BIG_REGULATED_CO because you want to find exploits, you're probably happier if they run jujutso than git because there will be a higher probability of finding secrets, client info, and other things that are forbidden from going into source control.

Reply on news.ycombinator.com