Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?



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

[1]: https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj...


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.


Honestly that does sound like a really frustrating corner case.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: