I think you missed the last sentence of the post:

Finally, when you reference a Git hash for posterity, e.g. in another commit message, I’d recommend always using the full value.

The git config is just for display purposes in terminal output. That only needs to be unique as of the time it’s displayed; and as I noted, the current default behavior is to adjust the size dynamically, so the displayed hash segment is always unique no matter how big the repo is.

I’m not sure I understand what issue Linus et al. are trying to solve. If the full hash is used whenever a commit reference is saved somewhere, then why does it matter how core.abbrev is configured? In particular, why use a static value, when git’s default behavior is to compute a value based on the current number of objects in the repository? (Edit: just noticed this post is over 10 years old. Maybe git didn’t have this automatic default behavior back then.)

For what it’s worth, jj has an even better solution, which is to highlight the shortest unique prefix in each specific hash it displays.

Not squashing before review, squashing on merge (i.e. after review). Squashed merges make these easy, regardless of whether the original commits in the pull request were messy:

• determining what changed between versions
• finding and reverting regressions

Doesn’t squashing on merge achieve exactly the same thing? (As long as pull requests are kept small, of course.)

The CLI is still pretty bad, and I say this as someone who’s gotten so used to it that I find git GUIs more annoying than helpful.

log gets a random flag from diff, -p, that’s incredibly useful but buried in the documentation. Printing a readable graph log requires magic incantations that aren’t worth memorizing. git branch with no subcommand prints the list of branches, but to get similar behavior for git remote, you need to add -v. Etc.

Mac OS is also a big tech OS and arguably doesn’t respect the user.

Linux is nice but often not an option for devs for circumstantial reasons, such as needing to use a corporate-provided machine for work.

I don’t think they’re interpreting that question as a gauge of how widely used nushell is in general. The comment below the result seems to be about how they should interpret the rest of the survey based on the ratio of users to non-users who responded.

Gotcha. Yeah, I feel similarly.

Wouldn’t the multiplexer run inside the terminal emulator? I don’t use a multiplexer myself, but I thought it was independent of what emulator you use.