I like to be like an accountant. No editing history. Create a new "journal entry" (i.e. commit) to fix.

seba_dos1 3 hours ago | parent | next [-]

Commit 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 3 hours ago | parent | next [-]

I am thinking of remote. Edits before pushing OK with me (they ate equivalent of recloning and redoing anyway)

	▲	seba_dos1 3 hours ago \| parent [-]
		Remotes 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.

▲

3 hours ago | parent | prev [-]

[deleted]

▲

what 3 hours ago | parent | prev [-]

You probably shouldn’t be committing things that are broken…

	▲	plorkyeran 4 minutes ago \| parent \| next [-]
		You 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.
	▲	moezd 3 hours ago \| parent \| prev \| next [-]
		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. Besides, aren't we all familiar with git commit -m "typo"?
	▲	normie3000 2 hours ago \| parent \| prev \| next [-]
		This is likely saying you shouldn't save a word document that contains spelling mistakes.
	▲	hahahaa 3 hours ago \| parent \| prev [-]
		Commit yes you absolutely can. Merge to trunk? Probably not, depends on your strategy.