3 ms·

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

by baq 1y ago

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

1718627440 1y ago
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?
- baq 1y ago
  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.)
  - 1718627440 1y ago
    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.
    - baq 1y ago
      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'.
      - 1718627440 1y ago
        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.
        baq 1y ago
        to each their own. you can argue in theory, in practice it is just not a problem.
      - ants_everywhere 1y ago
        You know your evangelists have gone haywire when they're explaining that your requirements are wrong instead of listening.
        dubi_steinkek 1y ago
        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 vs # 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.
- ants_everywhere 1y ago
  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.

by baq 1y ago

1718627440 1y ago

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?

baq 1y ago
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.)
- 1718627440 1y ago
  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.
  - baq 1y ago
    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'.
    - 1718627440 1y ago
      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.
      - baq 1y ago
        to each their own. you can argue in theory, in practice it is just not a problem.
    - ants_everywhere 1y ago
      You know your evangelists have gone haywire when they're explaining that your requirements are wrong instead of listening.
      - dubi_steinkek 1y ago
        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 vs # 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.
ants_everywhere 1y ago
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.