Given that it is high level, I assume you did not want to include this. I’ll mention it here in a comment either way. Text form in the commit message.

I really like using conventional commit messages and introduced it in my projects. We defined a few types, and more leniently choose optional scopes. It’s very useful for categorizing and skimming through commit lists, and for generating changelogs/release notes. `fix(account): Use correct hasing xy"

Consistent imperative form is important to me too. The commit message examples talks about “Summary of changes”, which has no verb, and so, may mislead to a different undesirable form of summarizing changes. (“Change xy” instead of “changed xy” or “[now] does xy [at runtime]” or “did z”.)

I didn’t fully read it, only skimmed, so excuse me if I missed mentions of the commit message text form. It seems very elaborate otherwise.

My browser has a default font size of 18 set. The site overrides that with a default base font size of 12px, then increases it to 13px for content text. That’s way too small for me on my screen. At least to read it comfortably. Or for people who need more accessible text/font.

each function has its own independent metal toggle switch

one steering wheel to steer left, and one to steer to the right

they want to push a lot of buttons on those controls

LOL

Even with a lot of buttons available, good videogame controls are simple and narrow. Natural combinations add depth without overcomplicating things.

They wrote they’re using . as placeholder commit messages.

I use f for such [f]ollowup/[f]ixup commits, and a for [a]dditional code/components/changesets. Both keys are trivial to enter. When cleaning it up after, f commits are typically squashed into previous ones, and a commits get a description and/or serve as a base for squashing.

I can see . working well as well, but having a more obvious character (with vertical height/substance) seems preferable.

You don’t see the point of making use of shortcuts?

It’s just them with shortcuts, they didn’t see the point of m

😏

How did it change how I think about version control? Not much? The goals are still the same. It only does many things better than previous centralized tools.

When DVCS came up and became popular, I used Git and Bzr.

At work, we used subversion. In one project, we had one SVN repository in our office and the customer had one in their office. A colleage had created a sync util. We regularly synced all history into an external hard drive, drove to the customer, and merged it there. Required a thorough and checklist process, potentially conflict resolution, and changelog generating for the big merge commit. Then drive back to the office, and merge back there.

Of course sometimes you used remote desktop to hotfix changes in their code base. Meaning you’d now have the change in two places as different commits.

Anyway, I’ve never found Git difficult. I used it, learned and understood it, and it’s consistent. I know enough “internals”/technical details to understand and use it well and without confusion.

Quite elaborate but also very interesting read on git and version control history.

I don’t get the title. Why is it “A Git story: Not so fun this time”? What is not so fun time referring to?

If working around it is an option, you could switch from https to ssh protocol.

I think the fundamental difference is that Git is a CLI tool. But that’s not how or where people use and want to use it. So obviously various interfaces are being created. It’s not alternative CLI that are created. It’s UIs and GUI interfaces. For a lack of a [more-than-barebone] official one.

Shells remain CLI. Distros are also technically/technologically driven.

Maybe the better analogy is that with vim and nano, we see many text editors and IDEs with GUIs.

There is no other CLI tool like Git. But

Shell or Bash has various alternative shells.

Vim has numerous plugins and alternatives/extensions.

Linux distributions are wide and varied, forking out.

I’m glad I was able to establish a very mindful and structured approach to Git history in my team and project.

deleted by creator

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?

What are you referring to?

The article is about abbreviated forms, not full hashes. The Linus quote is specifically about abbreviation.

[Linus] He recommends kernel developers use 12 characters

For a large code base you can expect to further grow continuously for a long time, it makes sense to already use more than a minimum abbreviation so that you references remain unique, even if a decades time.

Configuring a wider and explicit abbreviation width that will remain constant is preferable because the displayed references are what you will copy and reference. It doesn’t make sense to work with shorter abbreviations locally, but wider abbreviations when communicating with others. It’d be a hassle to translate and risky to miss doing.

It’s a fundamentally visual problem

In what way do you mean git versioning is fundamentally visual?

Or do you mean understanding it or visualising it? The data and its relationships?

I’ve been using TortoiseGit since the beginning. Nothing ever came close for me.

I in the log view I have overview, filters, and all actions at hand.

No, there is not.

Mirroring git repos themselves can work with automation. Anything beyond that has serious drawbacks or complexity or won’t work.

As for your key auth (git client auth), one key for authentication is sufficient to use across all platforms.

The weblink at the bottom to an Atlassian article is a dead link. Sounds about right for Atlassian I guess. Can’t keep something running for 9 years.