4 ms·
I like to be like an accountant. No editing history. Create a new "journal entry" (i.e. commit) to fix.
by hahahaa 3mo ago
I like to be like an accountant. No editing history. Create a new "journal entry" (i.e. commit) to fix.
- what 3mo agoYou probably shouldn’t be committing things that are broken…
- hahahaa 3mo agoCommit yes you absolutely can. Merge to trunk? Probably not, depends on your strategy.
- moezd 3mo agoWith tools like GitHub Actions and some added constraints, it's not always possible. You literally need a commit to trigger the CI workflow and it starts to trash your branch. Besides, aren't we all familiar with git commit -m "typo"?
- ninkendo 3mo ago> With tools like GitHub Actions and some added constraints, it's not always possible. You literally need a commit to trigger the CI workflow and it starts to trash your branch I'm with you on your overall point, but as a side note: this state of affairs is so tragic. It's been normalized for there to be test suites that nobody can run except the CI runner, and the only real way to run all the tests is to have GitHub do it. It's pure lock-in, and it's very sad that everything's moved this way. CI actions should be a simple file of "action: command" lines, with at most a separate file that describes when given actions should run. All actions should be runnable locally just as easily as they are in CI. Or if the actions are so complicated they need a complex-ish environment, that environment should be the kind of thing you could run locally too with your hypervisor of choice, without having to think about it. But every VCS host that has an actions/pipelines product is financially incentivized to encourage you not to set things up this way, to preserve their lock-in.
- normie3000 3mo agoThis is likely saying you shouldn't save a word document that contains spelling mistakes.
- plorkyeran 3mo agoYou should be committing things that are broken all the time. Git works great as a persistent navigatible undo buffer, and you should commit every time you're in a state that you might want to return to.
- smcameron 3mo agoThat breaks git bisect.
- inigyou 3mo agoSquash all your temporary commits before you push.
- smcameron 3mo agoNo, you don't commit trash to a public branch, EVER, if you can help it. Your commits are as perfect as you can make them, and that does not mean squashed in a trash compactor. That means one logical idea per commit, compiles and works as perfectly as you can make it. Use stgit, and this is easy. You do not break git bisect. No need to squash your trash in a trash compactor. Your standards are lower than mine, not higher.
- seba_dos1 3mo agoCommit graph is just a data structure. Sometimes it represents a "history", sometimes other things. Personally, I like it when project's repository represents the history of the project rather than the history of random things developers do on their machines, but you do you.
- hahahaa 3mo agoI am thinking of remote. Edits before pushing OK with me (they ate equivalent of recloning and redoing anyway)
- seba_dos1 3mo agoRemotes aren't equal either. Sometimes the remote is my other machine, sometimes it's a fork on a forge used for producing CI artifacts. It's a good rule of thumb to consider shared branches to be append-only, but not every remote branch is "shared" and, as with any proper rule of thumb, you can always find exceptions.
- hahahaa 3mo agoOk I amend to what I think I really mean: don't edit history for anything deployed to prod (or released to public or customers) already.
- deleted 3mo ago[deleted]
- account42 3mo agoThere is history that has already happened (e.g. what has been merged to master) and history that will happen (e.g. unmerged pull requests).