131–140 of 366 posts
It has been my habit for a while to make the root commit 0000000 because it’s fun, but for some reason it had not occurred to me to generalise this to subsequent commits. Tempting, very tempting. I have a couple of solo-developed-and-publicly-shared projects in mind that I will probably do this for.
How do you make the first commit 0000000? (Without using this project, obviously).
Earlier quoted context omitted.
This work if you have only experienced professional developpers in the team. If you have juniors or non devs (mathematicians, geographers, qwants...) that just happen to also code, rebase is a minefield. This is espacially true in open source contributions.
If you can’t rebase, I don’t want you pushing to my main branches. I would rather teach everyone how to rebase before I cave and allow merge commits.
Earlier quoted context omitted.
Oh we use distributed day in and day out for everything. Once you start battling censorship you’ll get it.
...so you are among the 1% who use the functionality that causes 99% of what makes git's mental model so convoluted and hard to learn (for everyone , not just the one-percenters).
Where in the worst dystopian parts of software do we do this?
The SHA1 is kind of a security feature if anything, a side-show thing that should be nestled 1-layer deep into the UI and probably most people are unaware of.
Whereas commits and branches should be designed specifically for the user - not 'externalized artifacts' of some acyclic graph implementation.
Git triggers a product designers OCD so hard, it's hard for some of us to not disdain it for spite.
I want the 'merge' function completely deprecated. I simply don't trust it anymore. If there are no conflicts, you might as well rebase or cherry-pick. If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. Developer end up fixing additional issues in the merge commit instead of actual commits. If you use merge to sync two branches continously, you completely lose trac…
Unfortunately, git rebase has a very very annoying limitation that git merge doesn't. If you have a branch with, say, masterX + 10 commits, and commit 1 from your branch is in conflict with masterX+1, then when you rebase your branch onto masterX+1, you will have to resolve the conflict 10 times (assuming all 10 commits happen in the same area that had the original conflict). If instead you merge masterX+1 onto your…
Earlier quoted context omitted.
I think merge is great, having a “unit” for a feature branch being integrated is nice and not all things can be done in commits which are individually justifiable. The ability to bisect cleanly through the first ancestor is precious. I do agree that resolving conflicts in merges is risky though. It can make sense when merging just one way between permanent branch (e.g. a 1.x branch into a 2.x), but as soon as cross m…
> I do agree that resolving conflicts in merges is risky though. How do you do otherwise, though? Or is your workflow a combination of rebases and merges? Continual rebasing of the feature branch onto `main` and then a final merge commit when it's ready to go?
You get the equivalent of “mergeless” history (just restrict your git log to merge commits) but can dig into the individual feature histories easily.
Why does the version skip from 19 to 20? What about 1A, 1B, 1C, 1D, 1E, and 1F?
The article talks about eight -character prefixes later in the article, but Git short refs actually use seven -character prefixes when there is no collision on that (and that’s what’s shown earlier in the article). So you can divide time by 16. For me on a Ryzen 5800HS laptop, lucky_commit generally takes 11–12 seconds. I’m fine with spending that much per commit when publishing. The three minutes eight-character pre…
Git hasn't used "seven-character prefixes when there are no collisions" in a long time. It's a combination of the "repo size" (as in, estimated number of objects) and a hard floor of seven characters. You can see this by running "git log --oneline=7" on any non-trivially sized repository (e.g. linux.git). There's plenty of hashes that uniquely abbreviate to 7 characters, but they're currently all shown with 12 by def…
$ git init x
Initialized empty Git repository in /tmp/x/.git/
$ cd x
$ git commit --allow-empty -m one
[master (root-commit) 4144321] one
$ git log --oneline
4144321 (HEAD -> master) one
$ lucky_commit
$ git log --oneline
0000000 (HEAD -> master) one
$ git commit --amend --no-edit --reset-author --allow-empty
[master 3430e13] one
$ git log --oneline
3430e13 (HEAD -> master) one
$ lucky_commit
$ git log --oneline
0000000f (HEAD -> master) one
$ git reflog --oneline
0000000f (HEAD -> master) HEAD@{0}: amend with lucky_commit
3430e13 HEAD@{1}: commit (amend): one
00000005 HEAD@{2}: amend with lucky_commit
4144321 HEAD@{3}: commit (initial): one
$ git reflog expire --expire=now --all
$ git reflog --oneline
$ git log --oneline
0000000f (HEAD -> master) one
$ git gc --aggressive --prune=now
Enumerating objects: 2, done.
Counting objects: 100% (2/2), done.
Writing objects: 100% (2/2), done.
Total 2 (delta 0), reused 0 (delta 0), pack-reused 0
$ git log --oneline
0000000 (HEAD -> master) oneExamples:
"shit show 14" gets converted to "git show 00000140"
"shit log 10..14" translates to "git log 00000100..00000140"
[1]: https://github.com/zegl/extremely-linear/blob/main/shit