Programmer in NYC
I totally agree.
Right now I’m on a new project with a teammate who likes to rebase PR branches, and merge with merge commits to “record a clean history of development”. It’s not quite compatible with the atomic-change philosophy of conventional commits. I’m thinking about making a case to change style, but I’ve already failed to argue the problem of disruption when rebasing PR branches.
Lol this is what I was thinking too. The junior dev is also a black box. AI automation seems more like delegating than programming to me.
I get fatigued too! At the end of an especially busy day of coding I have trouble forming sentences for a bit until I take some time to rest. Programming is complicated, and all that mental work literally uses up calories, and fatigues brain cells. Have you heard of the waterfall illusion? The short version is if you watch stuff moving down for a while your downward-motion-detecting cells get tired, and become less active which which messes with your ability to perceive not-moving-upward things for a minute. Your other brain cells get tired too - but it doesn’t take long to recover if you take a break.
Yes, if you don’t plan to pull updates then you’re covered
You’ll get conflicts if you pull changes from the original repo any time the deleted files have upstream changes. After you record a merge resolution (presumably by deleting them again) you won’t get conflicts until the next time those files change upstream.
If you submit a pull request part of its changes will be deleting the files from the original repo.
OTOH if you delete the files you can always undo that later with git restore --source upstream/main <deleted file paths>. You can restore them in a branch only if you do want to submit a pull request, but leave the files deleted in your own main branch.
I did not realize nano implemented syntax highlighting!