5 ms·

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/b

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...
- vxNsr 3y ago
  Isn’t this just .gitignore? I feel like I’m missing something.
  - montroser 3y ago
    That won't work for local changes to files that are legitimately committed in the repo. Like if you need to set your local database, or your own dev hostname in config, for example.
    - bmacho 3y ago
      Why wouldn't it work? You gitignore that file, and your modification is ignored, even if it is committed? Or will git delete that file from everyone?
      - Groxx 3y ago
        gitignores are usually committed (they're treated like a normal file), so yes, in this context that would delete it from everyone. There's .git/info/exclude, but that has some kinda large surprises if it excludes a tracked file and I don't recommend anyone use it unless they know what to look for and can always remember what they've excluded.
        sanderjd 3y ago
        I have a $HOME/.gitignore that I use for this. (You can configure git to use that globally.) It's not a panacea, and I think other commenters are right that you should instead endeavor to organize things so that the project's own gitignore results in a sane workflow. But I think having permanently unstaged changes is worse.
        happymellon 3y ago
        It's the perfect location to ignore *.log. Git will fight you if you ignore .config files which are actually used.
- dataflow 3y ago
  I think you want git's skip-worktree?
- Certhas 3y ago
  So in your workflow you never "git commit -a"? So you have to always manually mark what you stage. Which is probably more work than always manually removing the changes you don't want to commit. The ability to rewrite older commits easily in jj also looks like it would help with this usecase if you get it wrong once. Concretely I think you would do is: Instead of staging part of your changes and then committing as in git, you would call jj split and split the commit into the part you want to keep local and the part you want to push. This way the local changes always stay in your working copy commit. Even better, just commit the local changes once when you start. Work locally and before you push you call jj diffedit on your initial commit of the local changes and remove them. Now all the work you did since then will be automatically rebased on the edited initial commit and you can now push up. Instead of excluding your local edits every single time you just have to do it once before pushing.
  - guilherme-puida 3y ago
    > So in your workflow you never "git commit -a"? I like seeing what I'm about to commit, so I always do `git commit -p` or `git add -i`. Most people where I work do the same, so I don't think this workflow is uncommon.
    - dingnuts 3y ago
      if I don't do this (actually I use magit to select each hunk to stage, but that's just add -p with a fancy interface) then I'll accidentally commit testing log lines and that sort of experimental code I never, ever commit -a. That flag horrifies me. I want to choose, specifically, each line of code that I am going to publish.
    - happymellon 3y ago
      I never `git commit -a`, because I'm paranoid that I've done something like named a variable "foo" as I'm just working through the logic and not caring about naming. I'll then go back through, tidy and add all my changes.
  - rkangel 3y ago
    I almost always do "git add -p", "git commit". "add -p" is great for showing you all the chunks of code you've written one-by-one and then you do "y" or "n" for whether you're adding them. Doing it like this means that you are reviewing what you've changed as a final check that you haven't left a debug line in, or forgotten part of what you meant to do. It's also a natural way of splitting up what you've done into two separate commits.
- pjc50 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. I appreciate that there are times when this has to be in the middle of an otherwise committed file, but it's worth avoiding that if at all possible and putting the locally-changed bit in a different file because, as others have pointed out, this is error prone. It feels like the equivalent of keeping your important files in the recycle bin because it's easily accessible. For 90% of git users 90% of the time, the staging area is an inconvenience that adds an extra step.
  - deleted 3y ago
    [deleted]
- jayd16 3y ago
  Git should really steal the only thing I like about perforce, many uncommited change lists. It should be an easy workflow change to add 'named stages' along side the default stage. That way you can just leave changes in a different stage, tracked but uncommitted.
  - postmodest 3y ago
    Is that different to git stash?
    - jayd16 3y ago
      Yeah, they stay in the working set but files are marked for different commits. Ideally git could do it at the line level instead of by file.
  - dingnuts 3y ago
    Unless I have misunderstood your feature request, that feature exists, and it's called "worktrees" Worktrees allow you to have multiple branches open potentially with dirty state on any or all of them https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree
    - jayd16 3y ago
      No I don't think that is a similar feature. It looks like worktrees are put on different paths and by default do not operate on the same commit. My feature request is about having n stages instead of one so uncommitted work can be organized better while staying in the usual working copy. How would I accomplish this with worktrees?
- dryrun 3y ago
  In git, you have the .git/info/exclude file to track these down. Given that jj is compatible, maybe it works? Disclaimer : I'm not on my computer, I know a file like that exists, it may not be at this exact location
- kasdi 3y ago
  A safer way to keep temporary changes is to create a new local-only branch with a commit of those temporary changes. Then, whenever you need them, you rebase the branch on top of your working branch. Usually these temporary changes are to config files, so rebasing shouldn’t create conflicts if you don’t otherwise modify the config file. An alternative is to stash only those temporary changes but I find branches to be easier to work with.

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...
vxNsr 3y ago
Isn’t this just .gitignore? I feel like I’m missing something.
- montroser 3y ago
  That won't work for local changes to files that are legitimately committed in the repo. Like if you need to set your local database, or your own dev hostname in config, for example.
  - bmacho 3y ago
    Why wouldn't it work? You gitignore that file, and your modification is ignored, even if it is committed? Or will git delete that file from everyone?
    - Groxx 3y ago
      gitignores are usually committed (they're treated like a normal file), so yes, in this context that would delete it from everyone. There's .git/info/exclude, but that has some kinda large surprises if it excludes a tracked file and I don't recommend anyone use it unless they know what to look for and can always remember what they've excluded.
      - sanderjd 3y ago
        I have a $HOME/.gitignore that I use for this. (You can configure git to use that globally.) It's not a panacea, and I think other commenters are right that you should instead endeavor to organize things so that the project's own gitignore results in a sane workflow. But I think having permanently unstaged changes is worse.
        happymellon 3y ago
        It's the perfect location to ignore *.log. Git will fight you if you ignore .config files which are actually used.
dataflow 3y ago
I think you want git's skip-worktree?
Certhas 3y ago
So in your workflow you never "git commit -a"? So you have to always manually mark what you stage. Which is probably more work than always manually removing the changes you don't want to commit. The ability to rewrite older commits easily in jj also looks like it would help with this usecase if you get it wrong once. Concretely I think you would do is: Instead of staging part of your changes and then committing as in git, you would call jj split and split the commit into the part you want to keep local and the part you want to push. This way the local changes always stay in your working copy commit. Even better, just commit the local changes once when you start. Work locally and before you push you call jj diffedit on your initial commit of the local changes and remove them. Now all the work you did since then will be automatically rebased on the edited initial commit and you can now push up. Instead of excluding your local edits every single time you just have to do it once before pushing.
- guilherme-puida 3y ago
  > So in your workflow you never "git commit -a"? I like seeing what I'm about to commit, so I always do `git commit -p` or `git add -i`. Most people where I work do the same, so I don't think this workflow is uncommon.
  - dingnuts 3y ago
    if I don't do this (actually I use magit to select each hunk to stage, but that's just add -p with a fancy interface) then I'll accidentally commit testing log lines and that sort of experimental code I never, ever commit -a. That flag horrifies me. I want to choose, specifically, each line of code that I am going to publish.
  - happymellon 3y ago
    I never `git commit -a`, because I'm paranoid that I've done something like named a variable "foo" as I'm just working through the logic and not caring about naming. I'll then go back through, tidy and add all my changes.
- rkangel 3y ago
  I almost always do "git add -p", "git commit". "add -p" is great for showing you all the chunks of code you've written one-by-one and then you do "y" or "n" for whether you're adding them. Doing it like this means that you are reviewing what you've changed as a final check that you haven't left a debug line in, or forgotten part of what you meant to do. It's also a natural way of splitting up what you've done into two separate commits.
pjc50 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. I appreciate that there are times when this has to be in the middle of an otherwise committed file, but it's worth avoiding that if at all possible and putting the locally-changed bit in a different file because, as others have pointed out, this is error prone. It feels like the equivalent of keeping your important files in the recycle bin because it's easily accessible. For 90% of git users 90% of the time, the staging area is an inconvenience that adds an extra step.
- deleted 3y ago
  [deleted]
jayd16 3y ago
Git should really steal the only thing I like about perforce, many uncommited change lists. It should be an easy workflow change to add 'named stages' along side the default stage. That way you can just leave changes in a different stage, tracked but uncommitted.
- postmodest 3y ago
  Is that different to git stash?
  - jayd16 3y ago
    Yeah, they stay in the working set but files are marked for different commits. Ideally git could do it at the line level instead of by file.
- dingnuts 3y ago
  Unless I have misunderstood your feature request, that feature exists, and it's called "worktrees" Worktrees allow you to have multiple branches open potentially with dirty state on any or all of them https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree
  - jayd16 3y ago
    No I don't think that is a similar feature. It looks like worktrees are put on different paths and by default do not operate on the same commit. My feature request is about having n stages instead of one so uncommitted work can be organized better while staying in the usual working copy. How would I accomplish this with worktrees?
dryrun 3y ago
In git, you have the .git/info/exclude file to track these down. Given that jj is compatible, maybe it works? Disclaimer : I'm not on my computer, I know a file like that exists, it may not be at this exact location
kasdi 3y ago
A safer way to keep temporary changes is to create a new local-only branch with a commit of those temporary changes. Then, whenever you need them, you rebase the branch on top of your working branch. Usually these temporary changes are to config files, so rebasing shouldn’t create conflicts if you don’t otherwise modify the config file. An alternative is to stash only those temporary changes but I find branches to be easier to work with.