Look at this amateur, using a mouse to commit. I have a macro defined just to commit and push as a background job so that I can start editing the README again ASAP.
don’t post pictures of my face online, that’s rude >:(
In all seriousness I wonder why I always realize I could have explained myself better/left something out/omg formatting error better fix it/holy shit typo after the initial commit, and have like 4 different ones (or a bunch of rebases in an effort to keep the repo clean of this crap) fixing it, instead of pushing just a correct and complete readme from the beginning.
This is also why most of my Lemmy comments have edits. Not some weird sketchy crap editing things in to make others look bad or totally change my point after getting refuted, but just… oops typo or I could reword that to be more understandable or I meant to say this and totally forgot about it.
Sometimes when it’s not a minor edit like when I add some documentation, I usually branch so that I commit freely then just merge it squashing all the commits
I commit far too little, and I don’t use branches so all my FEAT and FIX and DOC are mixed up, and I… Oh yeah I could just do add, and commit each of them separately… Damn.
Or you could refrain from the dogmatic commit style that serves literally zero purpose because in any healthy software project nobody is ever reading the commit history like that.
History and good explanations of what was changed and why is incredibly useful for being able to determine if something is a bug, a feature, and why something was written a particular way.
I’m not super stringent on commit style, but it absolutely helps to structure commit messages, especially in larger projects where they’re being worked on piecemeal.
Look at this amateur, using a mouse to commit. I have a macro defined just to commit and push as a background job so that I can start editing the README again ASAP.
don’t post pictures of my face online, that’s rude >:(
In all seriousness I wonder why I always realize I could have explained myself better/left something out/omg formatting error better fix it/holy shit typo after the initial commit, and have like 4 different ones (or a bunch of rebases in an effort to keep the repo clean of this crap) fixing it, instead of pushing just a correct and complete readme from the beginning.
This is also why most of my Lemmy comments have edits. Not some weird sketchy crap editing things in to make others look bad or totally change my point after getting refuted, but just… oops typo or I could reword that to be more understandable or I meant to say this and totally forgot about it.
Sometimes when it’s not a minor edit like when I add some documentation, I usually branch so that I commit freely then just merge it squashing all the commits
Big same
The worst part? “readme updates” instead of “update readme”.
I commit far too little, and I don’t use branches so all my FEAT and FIX and DOC are mixed up, and I… Oh yeah I could just do add, and commit each of them separately… Damn.
Or you could refrain from the dogmatic commit style that serves literally zero purpose because in any healthy software project nobody is ever reading the commit history like that.
History and good explanations of what was changed and why is incredibly useful for being able to determine if something is a bug, a feature, and why something was written a particular way.
I’m not super stringent on commit style, but it absolutely helps to structure commit messages, especially in larger projects where they’re being worked on piecemeal.
it looks cool and I can get back to developing software I abandoned when I have a better commit history