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.

They’re mixing and messing definitions and concepts and separation together and then get confused because of it. It describes a behavior analysis discovery but lacks the useful, valid discovery. I don’t think this is useful for others to read, and detrimental for git newbies, because it’s more difficult and confusing than helpful.

• git says HEAD defines the current branch
• rebase is a process operating on commits and branches - it breaks out of the simple “current repository state” because there’s a process and process state around that. They notice things being different, but fail to elevate their view or discover that they have to interpret it differently.
• bare repository has no workspace - as such, workspace commands won’t work, and there is no workspace current branch. HEAD defines the default/main branch.

Detached HEAD meaning that the HEAD ref doesn’t point to the same commit as the branch ref that always follows the last commit in a development branch

IMO this is misleading, or incomplete.

HEAD is different from branches in that it can point to a commit or a branch. A branch always points to a commit.

When HEAD is in [branch] detached state, there is no branch to refer to/we can refer to. We are outside of branches.

From a use case perspective that may illustrate the difference:

When HEAD points to a branch, and I commit, I commit to that branch.

When HEAD points to a commit ([branch] detached HEAD), and I commit, I create a commit, and HEAD points to the new commit, but there is no branch pointing to it. (A followup is needed, e.g. creating a branch, or updating an existing branch, to keep the new commit discoverable even after we change what HEAD points to - e.g. by switching to a branch.)

I thought HEAD was just a ref

“refs” are stored in .git/refs/heads - but HEAD is not. In that sense, HEAD is not a ref like the others (branches and tags and whatever else you put there, like pull request references).

HEAD is either a reference or a reference to a reference. Branches are references.

I think this post makes an unnecessary distinction and unnecessarily leaves their connection open, making it more complex.

The baseline and reasoning should always be the HEAD, represented by .git/HEAD. Describing what they call a “revision parameter” or output should always refer to and be defined by that baseline. Because that’s what it uses and refers to.

Instead of “closely related” we can say one refers to the other. The context on “ways git uses HEAD in its output” implies/seems to nudge to me that it’s something different; but again, a HEAD label references HEAD. There’s no variance in what HEAD refers to.

HEAD -> sha1 (commit)                          => detached head (not on any branch)
HEAD -> refs/heads/branchname -> sha1 (commit) => on branch branchname

All of these things (HEAD, HEAD^^^, HEAD@[2}) are called “revision parameters”. They’re documented in man gitrevisions, and Git will try to resolve them to a commit ID.

While they listed a commit range in the example, they fail to mention it here. A revision range does not resolve to only one commit. (“Specifying ranges” is documented on the same git man page.)

For example, git talks about “detached HEAD state”, but never about “attached HEAD state” – git’s documentation never uses the term “attached” at all to refer to HEAD. And git talks about being “on” a branch, but never “not on” a branch.

I think it’s a good choice to not unnecessarily complicate default mode and usage. Detached HEAD is the exceptional state, and not commonly used.

So it’s very hard to guess that on branch main is actually the opposite of HEAD detached. How is the user supposed to guess that HEAD detached has anything to do with branches at all, or that “on branch main” has anything to do with HEAD?

I can agree it’s not obvious though. It requires understanding of what HEAD actually is - which is useful for the other things you list too (specifying revisions and understanding output).

I’m not sure if there’s a good or better way for introducing the user to it though. It’s inherent tool complexity. And I don’t think calling every HEAD attached when it points to a branch is verbose to the point of being detrimental.

I don’t find the HEAD in diffs between merge and rebase confusing. When I rebase commits I am always aware of the replay activity. (I mainly use TortoiseGit where it is always obvious through updating rebase progress.)

Displaying the original HEAD before the rebase started would be wrong and even more confusing. Because that HEAD and commit is no longer part of any of the changes. You are on a different base, and you are cherry picking onto it.

I don’t think I had a moment like that.

I discovered it, along with other DVCS when it came up, and looked into it and learned it. It was reasonable and intuitive enough for me. As far as I can remember anyway. (I don’t have particular memories of that.)