2 ms·
I just force push the same commits, so you won't know if it was me or the ai that wrote various parts /s I actually lead my commit messages with (human) or (ag
by verdverm 1y ago
I just force push the same commits, so you won't know if it was me or the ai that wrote various parts /s
I actually lead my commit messages with (human) or (agent) now
You could try using a git worktree that never gets pushed
- alganet 1y agoI prefer working with the one commit per PR philosophy, linear history and every commit buildable, so I always force push (to the PR branch, but never to master). Been doing it for ages. Bisecting this kind of history is a powerful tool.
- verdverm 1y agoyup, this is my preferred method as well, but I will wait to squash the commits at PR merging time, depending on project / code host I have one client where force push and rebase are not allowed, knots of history are preferred for regulatory compliance, so I'm told. Bisecting is not something I've heard done there before
- alganet 1y agoSquashing works great for bisecting. I like rebasing! It works great for bisecting, reverting (squash messes that up), almost everything. It just doesn't play well with micro commits (which unfortunatelly have become the norm). The force pushing to the PR branch is mostly a consequence of that rebase choice, in order to not pollute the main branch. Each change in main/master must be meaningful and atomic. Feature branches are other way to achieve this, but lots of steps involved.
- hatthew 1y agowhy not make many local commits and then squash before rebase/push/merge?
- alganet 1y agoYou mean generally? Yes, sure. As long as sloppy concatenated micro-messages don't end up in the main branch, I'm game.