Oh, that makes much more sense; thanks.

I think the point of the question is what a hypothetical ideal language for CI/CD pipelines would look like.

The post doesn’t say “imperative”, it just differentiates between defining pipeline steps and defining the logic within a step.

…also, TCL? I haven’t used it for ops, but my memory of tcl/tk is extremely negative.

…also also: a core part of a build, CI, or, CD pipeline is almost always invoking binaries to run a command. That’s why shell scripts are so ubiquitous in pipeline-logic: invoking binaries is what they’re for. And it’s very difficult to do that a declarative way: Make comes close, but it’s difficult to track any side-effects that aren’t “update these files”, and a huge amount of CI/CD is no longer just “update a file”.

Every single time I’ve tried to work on a file using tabs, I’ve had to configure my tabstop to be the same width the original author used in order to make the formatting reasonable. I understand that in theory customizable tabstops is preferable, but I’ve yet to see it work well.

(For what it’s worth, I think that elastic tabstops, had they been the way tabs worked in text files to begin with, would have been far preferable.)

Regular vim has that (as a compile option, like most of its features).

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 tried NeoVim pretty early on, I think, around 2014. My primary editor at the time was gVim (I prefer a proper graphical front-end to running in a terminal).

I used nvim on and off, primarily with nvim-qt as the front-end, though briefly with a custom setup that launched a new terminal emulator window and ran nvim there.

Once nvim incorporated nvim-qt into the base install, I started using it more regularly; eventually I switched entirely to Neovide and haven’t even installed gVim on my last few work computers.

I now primarily use VSCode with nvim integration. Unfortunately, I do have a weird issue where “undo” combines more operations than I’d expect, or, in some rare cases, it seems to corrupt the buffer and produce states that didn’t previously exist (!!). I don’t know if that’s an issue with the plugin, though.

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.