3 ms·

What workflow do people adopt for tools which still do not have a concept of local-only config files? For example, VSCode only has a launch.json, which should b

What workflow do people adopt for tools which still do not have a concept of local-only config files? For example, VSCode only has a launch.json, which should be committed, but I might need to customize it to my environment/current problem without distributing those edits. How can I not constantly fight jj with this?

cube2222 2y ago
I think you could achieve this with a variation of the "Working on Two Things at the Same Time" pattern[0], also explored more widely here[1] (with e.g. using private commits). Basically, just have a local-only merge-change that combines whatever you're working on, with all your local modifications. You can then even just create new changes on top of the `<dev>` change, and then rebase each into your branch when you're done with it, for even better ease-of-use (using `jj rebase -A name-of-branch`). You can also mark those local-only changes (both the merge-change and the local customizations) as private changes, to make sure you never actually push them. [0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs/#pattern-working-on-two-things-at-the-same-time https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs... [1]: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj...
- 0cf8612b2e1e 2y ago
  I am not proficient enough in jj to fully follow that, but it sounds promising. Especially if I can at least poison the local changes so there is no risk of sharing them.
  - stouset 2y ago
    Honestly that does sound like a really frustrating corner case.
sunshowers 2y ago
The usual way this is done is by having a sample file checked into the repo (launch.sample.json?) that developers can copy locally and customize.
SatvikBeri 2y ago
I use the squash workflow for this. I do my work on change N+1, which includes all the local changes I don't want to merge. When I'm ready to make a PR, I squash my edits into earlier changes, then `jj git push -c @-`, which will send everything up to change N. Once merged, I rebase change N+1 onto the new master.

cube2222 2y ago

I think you could achieve this with a variation of the "Working on Two Things at the Same Time" pattern[0], also explored more widely here[1] (with e.g. using private commits). Basically, just have a local-only merge-change that combines whatever you're working on, with all your local modifications. You can then even just create new changes on top of the `<dev>` change, and then rebase each into your branch when you're done with it, for even better ease-of-use (using `jj rebase -A name-of-branch`). You can also mark those local-only changes (both the merge-change and the local customizations) as private changes, to make sure you never actually push them. [0]: https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs/#pattern-working-on-two-things-at-the-same-time https://kubamartin.com/posts/introduction-to-the-jujutsu-vcs... [1]: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj...

0cf8612b2e1e 2y ago
I am not proficient enough in jj to fully follow that, but it sounds promising. Especially if I can at least poison the local changes so there is no risk of sharing them.
- stouset 2y ago
  Honestly that does sound like a really frustrating corner case.

sunshowers 2y ago

The usual way this is done is by having a sample file checked into the repo (launch.sample.json?) that developers can copy locally and customize.

SatvikBeri 2y ago

I use the squash workflow for this. I do my work on change N+1, which includes all the local changes I don't want to merge. When I'm ready to make a PR, I squash my edits into earlier changes, then `jj git push -c @-`, which will send everything up to change N. Once merged, I rebase change N+1 onto the new master.