171–180 of 389 posts
I think my favorite (in terms of humor) is a commit from mpv complaining about locales and encodings. You can practically feel the committer's sheer frustration. [1] https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
I wish Git wasn't like some generic term for source control. A little diversity is good!
Good point - but what is the use case where another source control system (like SVN?) works better ?
I love these commits. Then don't have to be this verbose, but they have to tell a story of why things were done. I can sort of deduce the what from the code itself, but the why is sometimes shrouded in mystery. I started with these explanatory git commits a few months ago and they are super useful, even if you're just reading your own commits from some time ago.
To me they are red flags because it means that very likely who writes this kind of commit messages doesn’t use a proper issue tracking system.
Putting this in the commit is not easily searchable, not universaly accepted and thus not expected, not practical and certainly can't involve discussion easily. This can be replaced with ticket number as most ticketing systems will actually read commit logs for those in order to associate ticket with code.
Now, there is that problem with decoupling code and story, but this is technical problem, nothing stops Gitlab and friends storring issues and friends in the repository itself.
Earlier quoted context omitted.
You'll have to give some specific examples...
Git is particularly poor in scenarios such as two people working on the same branch. SVN handles this with ease, but with Git it takes a lot of coordination amongst both contributors to keep things working.
Think fractally. The farther you get from master, the smaller and more atomic each commit should be.
If your merges are taking lots of coordination or failing to auto-merge, you probably have some poor engineering hygeine at play. Every time I've had merge fails, it's due to haste/sloppiness or a dev branch diverging too much from a mainline.
To avoid those kind of issues, non-ascii characters are forbidden in our code base. They are automatically verified in a pre-commit git hook.
I intentionally add non-ASCII characters to our code, so that an incorrectly configured IDE or bad tool fails. 75% of the development team has at least one non-ASCII character in their name , so it would be pretty rude otherwise. It's much better to knowingly reject a tool at the start, since it can't handle ordinary characters, than find out a year later with the first e.g. British customer that it can't handle "£".
Edit: already found one. Leet is supposed to end with Compart › unicode “” U+2608 Thunderstorm Unicode Character.
Doesn't show up on my comment.
Earlier quoted context omitted.
To me they are red flags because it means that very likely who writes this kind of commit messages doesn’t use a proper issue tracking system.
To me its beautiful, because it does what an issue tracking system does not do: it explains everything. Who, why, how, what, when. It is beautiful and simple documentation. Issue tracking typically revolves about the who, what, when - not why it happened, or how it was resolved. This is why I believe that code can never be fully self-documenting. I can't understand why the code exists from reading it. All the floofy…
Earlier quoted context omitted.
To me they are red flags because it means that very likely who writes this kind of commit messages doesn’t use a proper issue tracking system.
It's better to have these in with the source control system, When you change or switch to a different ticketing system, you will bring these with you.
This reminds of a Markdown issue I've had many many many times - sometimes (and only in some engines), headings would not render and I'd only get '# foobar' instead of ' ...' It took too long for me to track the issue. When I write '#' using alt-3, I then write a space and oftentimes I don't lift alt soon enough and alt-space creates a non-breaking space (on macOS). And some/most Markdown engines don't recognise '#nb…
This happened to me all the time, especially with python2 code without encoding declared (which caused a failure to parse the file because of the comment). I’ve since switched my editors to highlight such characters.