This post has a similar tune:
How to Write a Git Commit Message / The seven rules of a great Git commit message https://cbea.ms/git-commit/#seven-rules
My favourite Git commit (2019)
371–380 of 406 posts
Re: My favourite Git commit (2019)
#372Earlier quoted context omitted.
I would base direction on adjacent whitespace/punctuation instead of trying to do pairing.
Nice try, too. How would you handle Spanish quotation marks at the beginning of the sentence, then? And what about French quotes which are separated from their contents by a thin space? All of that is possible, of course, with large tables of special cases. Or, you know, you could just have separate characters for opening/closing quotation marks. ;-)
> All of that is possible, of course, with large tables of special cases.
Yes, that's how ligatures work. Pairing across characters is the one I'm not sure I've heard of before in fonts.
Edit: Besides, how do you think these are typed on keyboards without separate keys? The software already detects and replaces them based on context.
Re: My favourite Git commit (2019)
#373Earlier quoted context omitted.
> [..] where understanding what the author intended can save literal hours of examination, experimentation etc. The problem with that it that you are relying on an inherently unreliable source of information - a human to enter details which may or may not lead you to the correct path. The code doesn't "lie". Just read it and the current issue and work from there.
Code doesn't lie, but it isn't always obvious either. A diff that fixes a subtle corner case is very difficult to understand without explanation. A function to fix dirty external data cannot be understood without reference to what the author is fixing. It may not be clear why a certain performance trade-off is preferable. A mistake may be hard to detect if you don't know what was intended.
There should be a test along with that edge case then. In same commit that fixed the edge case. Possibly updates to documentation, change log etc.
Commits are a purely for developers, excluding the rest of team.
Re: My favourite Git commit (2019)
#374Earlier quoted context omitted.
As someone who has contributed to Git since before GitHub existed and who maintains legacy code, I simply cannot disagree more. I use `git blame`, `git log`, and `git show` in the terminal all the time. It's trivial to follow the history of a file. It takes me seconds to use `git log -G` to find when something was added or removed. Nothing pains me more than to track down the commit and then find a commit message tha…
> It's trivial to follow the history of a file. If the committer uses the "show history of a file" process model. These days, it's mostly "squash commits until I get a good/flattering 'story' of what I did", which removes typos, failed experiments, mid-thought commits, and any other blemishes of _what actually happened_. Commits CAN be used as great history, if history is allowed, but I've found that "modern" workflo…
I still wonder how much of rebase/squash-heavy workflows would disappear if UIs like GitHub and the CLI itself defaulted to `--first-parent` style views (with optional drilldown) and used the power of navigating a DAG for a little more good. All of this good commit metadata lost just because subway diagrams are pretty but also so many people find them confusing and messy. Or because GitHub shows commits as a flat confusing list with an order that only makes sense if you saw the subway diagram but GitHub's default view doesn't draw the subway diagram.
Re: My favourite Git commit (2019)
#375Earlier quoted context omitted.
> The main issue is that most of the tooling (in Git or GitHub or whatever) generally only shows the first line. This has been an issue with version control tooling for quite a long time. I'm fairly certain both CVS and SVN did the same thing. But I agree that you're still right. I'm also very amused by the number of replies to your comment along the lines of, "oh, it's actually very easy because I always use ". Whic…
No, because the point is about common tooling, and the common tooling does not, actually, make this difficult.
That's rather a matter of opinion. One that I and GP both clearly disagree with. Insisting it's easy doesn't mean everyone will agree with you.
Re: My favourite Git commit (2019)
#376Earlier quoted context omitted.
Well, `git` is still the primary way I interact with a git repository, and `git log` shows the entire commit message by default. So I don't run into this problem. If some "modern" git frontend is only capable of displaying the first line of a commit message, then this is a problem with that tool, not git itself. (I'm also not convinced this is a limitation of all modern tooling...)
periodic reminder that `gitk` exists, and has come with git since... pretty much forever? If you're reading `git log`, you really owe it to yourself to run `gitk` at least once to see what you've been missing for over a decade now.
gitk is great if you love subway diagrams and want a built-in tool for it. There's so much power in `git log --first-parent` and recursing into drilldowns that current UIs, including gitk, are bad at expressing as a workflow.
Re: My favourite Git commit (2019)
#377Earlier quoted context omitted.
Many engineers primarily or even exclusively use git via githubs interface and have never made a commit with a body.
Right, but then maybe the main issue is those engineers, and not the tooling? When I see someone using a hammer the wrong way, I don't usually blame the hammer.
The problem is the network effects. If enough people start hammering with the side to pull out nails, like 95%, there's a chance that could become known as "the right way".
I think a lot of the "get shit done" crowd for instance sees using Github and not "futzing around with git" as the right way to do things for getting shit done.
Re: My favourite Git commit (2019)
#378Earlier quoted context omitted.
As someone who has contributed to Git since before GitHub existed and who maintains legacy code, I simply cannot disagree more. I use `git blame`, `git log`, and `git show` in the terminal all the time. It's trivial to follow the history of a file. It takes me seconds to use `git log -G` to find when something was added or removed. Nothing pains me more than to track down the commit and then find a commit message tha…
How does this work in the face of unrelated refactoring? Say you first fix a bug somewhere, with a great commit comment. Then some refactoring happens, and the affected function is moved to a new class in a new file. Are you still able to track the original git comment?
Say you found the current commit through `git blame`. You run `git show` on that commit. The diff shows that the function you're interested in was actually moved so from the diff output you can see the previous filename and you have the function name. You could use:
git log -GsomeRandomFunction -- path/to/some/random/source.ext
Git log has a gazillion options and I've probably used them all at one time or another, but 99% of the time, the only ones I need are `-G` and following a particular file.
https://git-scm.com/docs/git-log#Documentation/git-log.txt--...
I also have `diff.renames` set to "copies" and `diff.algorithm` to "patience" in my `.gitconfig`:
https://git-scm.com/docs/git-config#Documentation/git-config...
https://git-scm.com/docs/git-config#Documentation/git-config...
Re: My favourite Git commit (2019)
#379It's not a great git commit. 1) For all that text, the first line "Convert template to US-ASCII to fix error" - could be better. Maybe a couple of extra words to state what whitespace character caused the error, and what the error was. That comment plus the diff is all the context you need. 2) Honestly, everything else is kind of pointless. It doesn't hurt, but there's not a lot of value here. The author documented t…
People who like to learn and improve as programmers do care. In fact, the article explains the value of all that additional stuff which implies there are those who DO care.
The article even provides a link to a search result showing multiple commits from people who learned from the fix.
That commit message is a treasure trove of knowledge.
Re: My favourite Git commit (2019)
#380Earlier quoted context omitted.
periodic reminder that `gitk` exists, and has come with git since... pretty much forever? If you're reading `git log`, you really owe it to yourself to run `gitk` at least once to see what you've been missing for over a decade now.
What gave you the impression that I haven't heard of gitk?
When someone mentions an approach, and someone else mentions a different approach, neither comment is "for one person only".