6 ms·

What happens if you accidentally save a file with some sort of secret that gets sucked in?

by TylerE 3y ago

Certhas 3y ago
Isn't the idea that you continue editing the working copy commit until you actually commit it? Also from the documentation: https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md https://github.com/martinvonz/jj/blob/main/docs/git-comparis... "As a Git power-user, you may think that you need the power of the index to commit only part of the working copy. However, Jujutsu provides commands for more directly achieving most use cases you're used to using Git's index for. For example, to create a commit from part of the changes in the working copy, you might be used to using git add -p; git commit. With Jujutsu, you'd instead use jj split to split the working-copy commit into two commits. To add more changes into the parent commit, which you might normally use git add -p; git commit --amend for, you can instead use jj squash -i to choose which changes to move into the parent commit."
- TylerE 3y ago
  Ugh, I was baited by myself here. I’m he scripts I use at the day git (which are the only way I tolerate hit, honestly. It does this, and also recursively merges from parent branches in commit. We’re on an old school feature branch/master is production topology though.
- KolmogorovComp 3y ago
  Sometimes you have changes that are permanent to your repo (ie local workflow), that you always want to keep locally, but never push to the remote. In git you would always leave the changes unstage, does that mean with jj you would always have to remove them before pushing? I haven’t found an answer on the linked page. Side note: I really wish git had a way to mark commit has ‘no-push’ so they never leave your local copy, as an upgrade of the unstaged workflow.
  - jstanley 3y ago
    > In git you would always leave the changes unstaged I do this too, but I quite frequently forget that I've done it and "git commit -am" and end up pushing my private changes anyway.
    - masukomi 3y ago
      tell git to treat it as if it's unchanged i have these 2 aliases assume = update-index --skip-worktree unassume = update-index --no-skip-worktree "assume" as in "assume it's unchanged / not wanted" which lets me say "git assume path/to/file" and then "unassume" it when/if i want to commit it.
      - mattmanser 3y ago
        Someone else's warning to not do this: https://news.ycombinator.com/item?id=36954723 https://news.ycombinator.com/item?id=36954723
        MrJohz 3y ago
        Ooh, that's me! As in the comment, please don't do this. It's been a while since I worked at a place doing this, and I'm on my phone, so some details may be fuzzy or wrong, but when I was figuring all this out, I remember this SO comment being really helpful: https://stackoverflow.com/a/23806990 https://stackoverflow.com/a/23806990 Basically, there's two different APIs, and neither of them are designed for ignoring config files (but both of them happen to do things that look like ignoring config files, therefore get misused). `assume-unchanged` is an optimisation tool that tells git that it shouldn't both checking files and folders that are expensive to check but never changed. If changes do ever happen, and git realises this, then git will remove the assume-unchanged flag - because clearly it wasn't true! `skip-worktree` is a more aggressive version of this that tells git never to touch certain files or folders at all. But now it changes do happen to those files, it's not clear what git should do. Overwriting the files would cause data loss, but ignoring the files completely means that you miss out on upstream changes. And because you're telling git that these files should never be checked, there's no good way to handle merging and conflicts. What typically happens with both of these flags is that they work well about 80% of the time, and then cause a lot of confusion that last 20% of the time. The alternative is almost always some sort of configuration file that is directly referenced in .gitignore, and that therefore never gets checked in. (In addition, it's often useful to have a (e.g.) config.json.default file for getting new developers up and running quickly.) Any system that needs to be configured (database connections, API URLs, IP addresses, etc) should use this configuration file. Alternatively, I find environment variables, along with .env files for local development, to be really effective, because most things can already be configured that way. This typically takes sightly longer to set up the first time, but will work very reliably from then on. See also these changes in git's official documentation, and the commit message that explains why it was necessary: https://github.com/git/git/commit/1b13e9032f039c8cdb1994dd092ff2ed32af5cf5 https://github.com/git/git/commit/1b13e9032f039c8cdb1994dd09...
kasdi 3y ago
Assuming in git you would keep it as untracked file in the working copy, I find jj’s automatic anonymous working copy commit better. For once, it avoids the downsides of carrying untracked files around. Ever accidentally committed an untracked file somewhere deep in history during a long rebase? Also I find it clearer what files are committed: every file - except if it is in .gitignore. Meanwhile in git you scourge through your untracked files before each commit to decide which ones you don’t want to add. Ever accidentally committed all files and forgot that there were untracked files you didn’t want?

What happens if you accidentally save a file with some sort of secret that gets sucked in?

by TylerE 3y ago

What happens if you accidentally save a file with some sort of secret that gets sucked in?

Isn't the idea that you continue editing the working copy commit until you actually commit it? Also from the documentation: https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md https://github.com/martinvonz/jj/blob/main/docs/git-comparis... "As a Git power-user, you may think that you need the power of the index to commit only part of the working copy. However, Jujutsu provides commands for more directly achieving most use cases you're used to using Git's index for. For example, to create a commit from part of the changes in the working copy, you might be used to using git add -p; git commit. With Jujutsu, you'd instead use jj split to split the working-copy commit into two commits. To add more changes into the parent commit, which you might normally use git add -p; git commit --amend for, you can instead use jj squash -i to choose which changes to move into the parent commit."

TylerE 3y ago
Ugh, I was baited by myself here. I’m he scripts I use at the day git (which are the only way I tolerate hit, honestly. It does this, and also recursively merges from parent branches in commit. We’re on an old school feature branch/master is production topology though.
KolmogorovComp 3y ago
Sometimes you have changes that are permanent to your repo (ie local workflow), that you always want to keep locally, but never push to the remote. In git you would always leave the changes unstage, does that mean with jj you would always have to remove them before pushing? I haven’t found an answer on the linked page. Side note: I really wish git had a way to mark commit has ‘no-push’ so they never leave your local copy, as an upgrade of the unstaged workflow.
- jstanley 3y ago
  > In git you would always leave the changes unstaged I do this too, but I quite frequently forget that I've done it and "git commit -am" and end up pushing my private changes anyway.
  - masukomi 3y ago
    tell git to treat it as if it's unchanged i have these 2 aliases assume = update-index --skip-worktree unassume = update-index --no-skip-worktree "assume" as in "assume it's unchanged / not wanted" which lets me say "git assume path/to/file" and then "unassume" it when/if i want to commit it.
    - mattmanser 3y ago
      Someone else's warning to not do this: https://news.ycombinator.com/item?id=36954723 https://news.ycombinator.com/item?id=36954723
      - MrJohz 3y ago
        Ooh, that's me! As in the comment, please don't do this. It's been a while since I worked at a place doing this, and I'm on my phone, so some details may be fuzzy or wrong, but when I was figuring all this out, I remember this SO comment being really helpful: https://stackoverflow.com/a/23806990 https://stackoverflow.com/a/23806990 Basically, there's two different APIs, and neither of them are designed for ignoring config files (but both of them happen to do things that look like ignoring config files, therefore get misused). `assume-unchanged` is an optimisation tool that tells git that it shouldn't both checking files and folders that are expensive to check but never changed. If changes do ever happen, and git realises this, then git will remove the assume-unchanged flag - because clearly it wasn't true! `skip-worktree` is a more aggressive version of this that tells git never to touch certain files or folders at all. But now it changes do happen to those files, it's not clear what git should do. Overwriting the files would cause data loss, but ignoring the files completely means that you miss out on upstream changes. And because you're telling git that these files should never be checked, there's no good way to handle merging and conflicts. What typically happens with both of these flags is that they work well about 80% of the time, and then cause a lot of confusion that last 20% of the time. The alternative is almost always some sort of configuration file that is directly referenced in .gitignore, and that therefore never gets checked in. (In addition, it's often useful to have a (e.g.) config.json.default file for getting new developers up and running quickly.) Any system that needs to be configured (database connections, API URLs, IP addresses, etc) should use this configuration file. Alternatively, I find environment variables, along with .env files for local development, to be really effective, because most things can already be configured that way. This typically takes sightly longer to set up the first time, but will work very reliably from then on. See also these changes in git's official documentation, and the commit message that explains why it was necessary: https://github.com/git/git/commit/1b13e9032f039c8cdb1994dd092ff2ed32af5cf5 https://github.com/git/git/commit/1b13e9032f039c8cdb1994dd09...

kasdi 3y ago

Assuming in git you would keep it as untracked file in the working copy, I find jj’s automatic anonymous working copy commit better. For once, it avoids the downsides of carrying untracked files around. Ever accidentally committed an untracked file somewhere deep in history during a long rebase? Also I find it clearer what files are committed: every file - except if it is in .gitignore. Meanwhile in git you scourge through your untracked files before each commit to decide which ones you don’t want to add. Ever accidentally committed all files and forgot that there were untracked files you didn’t want?