My favourite Git commit (2019)

Yes, I think we agree that abstraction is great (with or without "scair" quotes.) My point is that CLIs are valued as tools of explication, repeatable explication. I have actually used Window since 3.1. I cherry picked a particularly juicy example that I run into a lot.

> If you're going to make that into a complicated mess, then you absolutely do not get to assume...

As far as tooling goes the GP mentioned IntelliJ so I rewrote code with fleet, I could have easily have picked emacs or vim or bash or zsh or tcsh instead of fish and the complexity of interface would have remained static. I think HN formatting tools are partly to blame for the messiness but if you look at any quality set of docs describing a complicated computer interaction, to achieve the same level of repeatability as text-based, POSIXy interactions you are going to need a lot of screen shots and a few this or thats. WHICH is fine! Remember software engineering is about trade offs!

EDIT: CLI allows for abstractions like $EDITOR and $SHELL

Right. You've given an example of exactly what I said was the only reasonable use case for detailed info in the commit message: someone in the future will need to know the history of that particular piece of code. It seems like the point of your specific example is to say 'in some cases you might want to know the history of a gap'. Fine. That seems like a nitpick to me.

No one in the future will need to know the history of a particular ascii encoded blank space (among a whole file of ASCII encoded blank spaces). Anyone who needs the general info that the file needs to be ascii will be helped by it being somewhere else, as opposed to in a random commit message.

> The key is not to put what you did in that first line, but why.

Can't we just say that the key is to put something that makes sense for the first line, given that sometimes only the first line is printed?

I don't really care if it says "The files must be in us-ascii" or "Changed the files to us-ascii"... both of them clearly tell me that the files were changed to us-ascii.

I would prefer to channel that energy that went into writing this lengthy description into actually fixing the toolchain to at least fail with more actionable error message.

> I think it's optimized for discussions before integration, which is largely what PR descriptions and comments are largely used for now.

This isn't even a git concept though; it's something that was tacked on top of it. What you seem to be saying here is that a third-party tool building on top of git spawned a social movement that moved this layer up a level. Not every project uses github or a github workflow.

> I think it's optimized for discussions before integration

It's optimized for discussion of the purpose of the code unit in question. That discussion can be useful before integration; but pre-integration discussion can happen any way you like. PR discussions work, e-mails on mailing lists work. Face-to-face discussion works.

The real value (for me, I guess; apparently you just don't see it that way) is explaining the purpose (and possibly circumstances) of the commit, after the fact, when I'm looking at it for some reason or other. Not finding the commit, but explaining it once I'm there. A well-written commit message can be absolutely priceless.

Maybe this last point should go in a top-level response to your original comment, but I'm already here, so I'll just say it here. Saying that commit messages are terrible because only short-messages (the "subject line") are shown by default, seems to me about the same as saying e-mail bodies are useless for the same reason, or that file contents are terrible because `find` only lists file names by default. You 'have' to collapse by default, or you'd drown in a sea of commit messages anytime you tried to list anything.

> Like say you are trying to determine why a 10 line function is the way that it is. You blame it. Not even with the stupid-simple GitHub UI that _I_ originally wrote, but with the more expensive CLI interface that follows renames and ignores whitespace changes, etc. Now you get a list of SHAs of commits and the first 50 chars of commit messages for each line for the last modifications, etc. How do you even stitch those messages into a useful story (in order) to tell you how that function evolved to what it is now and why?

Okay, I hear you, this is not the most ergonomic procedure to one-off. But seriously, you have the SHA commits. If you need to do this often, write a tool that takes those SHA commits, orders them based on log order (or chronological order, w/e, pick an ordering mechanism), and prints out whatever information is interesting to you. A simple display that can expand/collapse full messages, diffs, etc. would probably do nicely. It can be a GUI tool, a CLI tool (menu-driven, maybe); whatever works for you. This should not be a big deal to write for the common case, and if you think it's that critical to the community, publish it.