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.
Edit: just noticed this post is over 10 years old.
It would be helpful if the title was edited to feature the release date. Context is king. So many things are absurd with regards to the current state, but are sorely lacking a few years ago.
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.
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.
Reference syntax. Like what the fuck is the difference between .. (2 dots) and ... (3 dots)? And is there .... (4 dots)?
And I can never keep apart how to compare references. If I want to compare my feature branch with master, is it git diff HEAD..master or git diff master..HEAD? It seems like in git the syntax is reversed to mine, but I'm never sure. Maybe something like git diff HEAD->master would be more intuitive?
And git rebase --onto. Fuck me did it take me a long time to understand that (if I understood it).
Honestly, that's just git CLI interface stuff. Every time I've tried to read about the internal workings of git, the naming has thrown me off and stopped me from continuing. Like what the fuck is "git porcelain"? IIRC there's also git plumbing? But that doesn't even seem to be the internals which have another bizarre name?
git is a large series of Chesterton's fences that should be each examined. I'm hopeful that somebody or some org will come around to design a version control system from the ground up with documented architecture from the start (and not written in gosh-darn C).
I agree that the UX of existing git commands is not great. They evolved in a particular insular environment -- Linux kernel development with heavy mailing-list usage and large multi-headed merges, with occasional pull requests and manual integration testing.
Check out my top-level comment for a link to git's data model. A data-first approach with blob, tree, commit, and tag can be enlightening. The on-disk format tries to balance integrity, easy manipulation, disk space, and incremental updates; it's also weakly monoidal, enabling distributed development. Look up the history of Bitkeeper and git; this is "a version control system [designed] from the ground up with documented architecture from the start"! And there are many non-C implementations as a result, like pure-Python dulwich.
Twenty years is nothing, but twenty years in computer history, considering computer science as an academic discipline is barely 80 years old, is a quarter of it. Much, much less if you’re only talking about personal computing, and even worse if only focusing on software engineering as a field.
When I learned about the reflog. I became less afraid of my changes when I knew I could easily recover from my errors. This allowed me to experiment more with git and become more proficient in it.
Another aha moment was learning that an easy way to squash commits is just to do a git reset followed by git commit -am “whatever”
I've put ASTs directly into git repositories by encoding each leaf as a blob and each tree as a tree. Since git objects are content-addressed, this gives deduplication of ASTs for free, including CSE for sufficiently-pure ASTs.
ifc is an iso standard for 3d construction projects, which includes all aspects of a building data. because ifc is in human-readable form, versions of the same project can be diffed, hence ifc git.
We're currently training some devs from another team, which were doing some development before, but it wasn't their bread-and-butter.
And yeah, commit messages are one of the bigger differences, where they just don't quite take things as seriously.
But that's due to a chicken-egg problem. They're not really well-versed in creating atomic commits, and apparently so far, they've been merging basically at random, creating a rather complex history.
And of course, they've been embedded in a team where everyone else didn't take these things as serious. So, even if they put lots of efforts into their commits, they're be much less useful when they're placed between badly separated commits.
Really makes me feel like we need to put special focus on Git for a while, to give them the tools to appreciate working in our useful commit history.
Meh. I'd argue that info should be in a merge request, than in a commit comment.
Not certain how this organization does it, but a branch contain all the backstory and context. Commits are labels inside a branch, of which there can be many.
The proper way to organize a branch is as a logical sequence of sub-features - each represented by a commit. Ideally, the commits should not break the build while introducing its feature. In many such cases, each commit may have a back story - the tests you did, your decision process, online references (that apply only to that commit - something like stackoverflow answers), etc.
Branch messages don't have the fidelity to capture such information. You may question the need for such detailed info. However, along with git blame and bisect, those commit messages are invaluable. I have lost count of how many times my own detailed commit messages helped me. And while I don't usually look at others' commits in such detail, I do read the details of commits that I'm interested in.
Git (and other VCSs) isn't just a snapshot tool. It's a history tool with the ability to capture history documentation. Honestly, Git is extremely underutilized in that capacity.
Well, there's different workflows. Big organizations tend to meticulously craft these branches and then do a big bang merge at the end.
But for smaller organizations/teams, it's usually more useful to merge as early as possible, i.e. work directly on a single branch together. This avoids complex merge conflicts and allows others to benefit from your work as early as possible.
In particular, smaller teams tend to also go together with smaller projects, where many features may be completed in a single commit, so there's not much of a backstory to tell...
Just use merge with informative PR titles, descriptions and linked work items. Reviewing history is then trivial and it has none of the pitfalls for less experienced devs.
Gave up after clicking on the next links starting at get started page. I was looking for any example which shows commands with corresponding results. Has anyone here had better luck and could please share a few?
Git
Top