All these things just remind me how depressing it is that we all use this deeply flawed tool, git, and no one can get enough critical mass for a substantially better version.
npm says hi, how do you like your eggs in the morning?
A better merge workflow with Jujutsu
71–80 of 93 posts
Re: A better merge workflow with Jujutsu
#72Are Jujutsu users all using it from the command line ? Is there anything magit-like yet ? Or do you use magit with it ? Have you run into extra complexity and messes because of having two VCSes interacting in one working copy ?
I am (slowly) working on a TUI: https://github.com/Cretezy/lazyjj
Also nice, thanks!
Re: A better merge workflow with Jujutsu
#73I really tried to like jj but I couldn’t make it work for my workflow: There are files that are committed to repository that I need to edit (e.g. .envrc files, which cannot be overridden). There is no way I can ignore those in Jujutsu. In plain git I can do sparse checkout using negative paths and it works. jj doesn’t support it, and using positive path doesn’t work as I never know if new files are there. Every push…
can't you just add them to gitignore? if you want it to be local only, there's also .git/info/exclude or for all your repos with ~/.config/git/ignore
I think OOP meant to say that the `.envrc` file _is_ committed, but they want to do local changes _without_ the possibility of them getting accidentally committed by mistake.
Re: A better merge workflow with Jujutsu
#74I really tried to like jj but I couldn’t make it work for my workflow: There are files that are committed to repository that I need to edit (e.g. .envrc files, which cannot be overridden). There is no way I can ignore those in Jujutsu. In plain git I can do sparse checkout using negative paths and it works. jj doesn’t support it, and using positive path doesn’t work as I never know if new files are there. Every push…
I would say that having files in the repo that you have to change but are not allowed to commit is more an issue with the project setup than with jj. The way this is usually done (at least where I work) is to have e.g. an `.env.example` file in the repo containing default values which the developer copies to `.env` after cloning the project (usually done by a setup script) - `.env` can then be changed, but is in `.gitignore`, so you don't accidentally commit it.
Re: A better merge workflow with Jujutsu
#75Earlier quoted context omitted.
can't you just add them to gitignore? if you want it to be local only, there's also .git/info/exclude or for all your repos with ~/.config/git/ignore
I think OOP meant to say that the `.envrc` file _is_ committed, but they want to do local changes _without_ the possibility of them getting accidentally committed by mistake.
the simple workaround would be to have .envrc optionally load another gitignored file if it exists, which sounds much safer than accidentally committing local changes, even with plain git.
Re: A better merge workflow with Jujutsu
#76Earlier quoted context omitted.
humans are creatures of habit. fixing these flaws is not enough to motivate us onto something new, it has to be groundbreaking.
It's not a matter of habit but of widespread usage If you're a developer, for almost every job or open source job you'll be required to use git, but I think most people long of moving away from it
Not my experience at all. Most devs I have met in real life love git. It is certainly not perfect but it is good and way better than what came before. I would be happy if someone wrote a replacement which improved substantially upon git but if that never happens that would be fine too.
Re: A better merge workflow with Jujutsu
#77All these things just remind me how depressing it is that we all use this deeply flawed tool, git, and no one can get enough critical mass for a substantially better version.
> how depressing it is that we all use this deeply flawed tool, git Maybe a change in perspective can help you be less depressed. I don't find git "deeply flawed"; on the contrary, it's an extremely useful tool with an easy to grasp data model. Some parts of it are quirky, sure, but I find it very easy to use productively in code bases small and large, private or shared. It's such a huge improvement over what was use…
>Anyway, instead of thinking of git as deeply flawed, try to see it as a battle tested tool without which your job would suck in ways you can't even imagine.
I would rather use mercurial.
Re: A better merge workflow with Jujutsu
#78Earlier quoted context omitted.
I think OOP meant to say that the `.envrc` file _is_ committed, but they want to do local changes _without_ the possibility of them getting accidentally committed by mistake.
the simple workaround would be to have .envrc optionally load another gitignored file if it exists, which sounds much safer than accidentally committing local changes, even with plain git.
If that's not possible, maybe OP can rename it to .envrc.example, and commit that. Then put in the instructions to rename .envrc.example to .envrc on checkout
Re: A better merge workflow with Jujutsu
#79A better way for suboptimal workflow to begin with („multitasking” on branches)?
Isn't that what git worktrees solved and noone knows about?
Re: A better merge workflow with Jujutsu
#80I really tried to like jj but I couldn’t make it work for my workflow: There are files that are committed to repository that I need to edit (e.g. .envrc files, which cannot be overridden). There is no way I can ignore those in Jujutsu. In plain git I can do sparse checkout using negative paths and it works. jj doesn’t support it, and using positive path doesn’t work as I never know if new files are there. Every push…
I would say that having files in the repo that you have to change but are not allowed to commit is more an issue with the project setup than with jj. The way this is usually done (at least where I work) is to have e.g. an `.env.example` file in the repo containing default values which the developer copies to `.env` after cloning the project (usually done by a setup script) - `.env` can then be changed, but is in `.gi…
There are always edge cases. VSCode still does not let you have a personal configuration file for a project[0] (open since 2016). There are workarounds, but many of them are less good than just manually ignoring the modified file.