3 ms·
Looks really cool! One thing I'm not clear on from the docs: does it support ignoring changes to some files for "real" commits? For example, a repo at work has
by mcluck 3y ago
Looks really cool! One thing I'm not clear on from the docs: does it support ignoring changes to some files for "real" commits? For example, a repo at work has a file used for mocking up feature flags. The file is tracked but it's encouraged to edit it when testing things, just don't commit your changes. If I'm not mistaken, I'd have to remember to undo changes to that file before "describing" the commit. Is that right?
- ilyagr 3y agoThe commit will indeed be created immediately, there's no way to prevent that except for .gitignore I'm aware of. Until you run `jj describe`, it won't have a description. However, if you don't manually put a branch on it, it'll never get pushed and will stay on your machine only. You can sit on this personal commit and rebase it on top of any other commit to move around the repo, again and again if you like.
- psd1 3y agoI know the nuisance of having to tiptoe around files you don't want to add to history. In case it helps your use case: git update-index --assume-unchanged <file> git update-index --no-assume-unchanged <file> This would ignore changes while you're testing - but you have to remember to turn it off or, iiuc, you won't pull intentional changes either. You might find hooks useful too. Not to assume your knowledge, these are shell scripts placed in .git/hooks that are invoked, e.g., before commit or before push. You could have it parse git status, detect changes to <file>, prompt for confirmation if changed and remove from working set if the change is unintentional.
- mcluck 3y agoI never knew about the `update-index` command. That's going to save me a lot of time. Thanks!