Production-ready implementation of InvisPose - a revolutionary WiFi-based dense human pose estimation system that enables real-time full-body tracking through walls using commodity mesh routers - ...
I have a project with a bunch of compose files that define the services I self host. I “deploy” the project by sshing into my server and doing “git pull” which means I’m often making changes that don’t get tested before committing to source control. As a result I have long chains of commits like:
refactor the sproingy widget
refactor the sproingy widget v2
refactor the sproingy widget working
maybe the sproingy widget works this time?
ok finally found the issue with refactor sproingy widget
fix formatting of sproingy widget
And now I’m wondering if I’ve been an llm this whole time
This also means modifying your git pull command to pull the correct branch. A small change perhaps, but may be harder than just committing to main lol.
I had a similar problem with GitHub actions, it was hard to test without messing up the main repo history.
I have a project with a bunch of compose files that define the services I self host. I “deploy” the project by sshing into my server and doing “git pull” which means I’m often making changes that don’t get tested before committing to source control. As a result I have long chains of commits like:
And now I’m wondering if I’ve been an llm this whole time
Why not just edit the YAML directly on the server via a command-line text editor or SSHFS and then push from there when it works?
No the AI would have called it fixed, “production-ready,” committed, and pushed after the first refactor.
Make your changes in a new branch and rebase/squash when you push it to main.
This also means modifying your
git pullcommand to pull the correct branch. A small change perhaps, but may be harder than just committing to main lol.I had a similar problem with GitHub actions, it was hard to test without messing up the main repo history.