by zegl on 11/22/22, 10:43 AM with 358 comments
by infogulch on 11/22/22, 8:20 PM
All PRs are rebased and merged in a linear history of merge commits that reference the PR#. If you intentionally crafted a logical series of commits, merge them as a series (ideally you've tested each commit independently), otherwise squash.
If you want more detail about the development of the PR than the merge commit, aka the 'real history', then open up the PR and browse through Updates, which include commits that were force-pushed to the branch and also fast-forward commits that were appended to the branch. You also get discussion context and intermediate build statuses etc. To represent this convention within native git, maybe tag each Update with pr/123/update-N.
The funny thing about this design is that it's actually more similar to the kernel development workflow (emailing crafted patches around until they are accepted) than BOTH of the typical hard-line stances taken by most people with a strong opinion about how to maintain git history (only merge/only rebase).
by larschdk on 11/22/22, 12:29 PM
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 track of what changes were done on the branch and which where done on the mainline.
by zegl on 11/22/22, 2:47 PM
Examples:
"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
by jordigh on 11/22/22, 2:47 PM
They aren't perfect, of course. All they indicate is in which order the current clone of the repo saw the commits. So two clones could pull the commits in different order and each clone could have different revision numbers for the same commits.
But they're still so fantastically useful. Even with their imperfections, you know that commit 500 cannot be a parent of commit 499. When looking at blame logs (annotate logs), you can be pretty sure that commit 200 happened some years before commit 40520. Plus, if you repo isn't big (and most repos on Github are not that big by numbers of commits), your revision numbers are smaller than even short git hashes, so they're easier to type in the CLI.
by kinduff on 11/22/22, 11:37 AM
I wonder about performance, though. Why is the author's method slower than the package I linked?
by blux on 11/22/22, 2:54 PM
How are you going to deal with non-trivial feature branches that need to be integrated into master? Squash them and commit? Good luck when you need to git bisect an issue. Or rebase and potentially screwing up the integrity of the unit test results in the rebased branch? Both sound unappealing to me.
The problem is not a history with a lot of branches in it, it is in not knowing how to use your tools to present a view on that history you are interested in and is easy for you to understand.
by bloppe on 11/22/22, 10:23 PM
https://git-scm.com/docs/git-gc#_configuration
Git does something called "packing" when it detects "approximately more than <X (configurable)> loose objects" in your .git/objects/ folder. The key word here is "approximately". It will guess how many total objects you have by looking in a few folders and assuming that the objects are uniformly distributed among them (these folders consist of the first 2 characters of the SHA-1 digest). If you have a bunch of commits in the .git/objects/00/ folder, as would happen here, git will drastically over- or under-approximate the total number of objects depending on whether that 00/ folder is included in the heuristic.
This isn't the end of the world, but something to consider.
by wirrbel on 11/22/22, 1:08 PM
We performed code review with a projector in our office jointly looking at diffs, or emacs.
Of course it’s neat to have GitHub actions now and pull-requests for asynchronous code review. But I learned so much from my colleagues directly in that nowadays obscure working mode which I am still grateful for.
by chrismorgan on 11/22/22, 12:34 PM
by oneeyedpigeon on 11/22/22, 12:15 PM
by Ayesh on 11/22/22, 11:24 AM
I imagine stuff like this and SVN to Git mirroring to work nicely with identical hashes.
by Semaphor on 11/22/22, 11:43 AM
Hah :D
by otikik on 11/22/22, 11:38 AM
by ChrisMarshallNY on 11/22/22, 11:45 AM
> but it can also mean to only allow merges in one direction, from feature branches into main, never the other way around. It kind of depends on the project.
That sounds like the Mainline Model, championed by Perforce[0]. It's actually fairly sensible.
[0] https://www.perforce.com/video-tutorials/vcs/mainline-model-...
by davide_v on 11/22/22, 11:16 AM
by gyulai on 11/22/22, 11:48 AM
by maxbond on 11/22/22, 11:19 AM
by sagebird on 11/22/22, 3:21 PM
I have a somewhat related interest of trying to find sentences that have low Sha256 sums.
I made a go client that searches for low hash sentences and uploads winners to a scoreboard I put up at https://lowhash.com
I am not knowledgeable about gpu methods or crypto mining in general, I just tried to optimize a cpu based method. Someone who knows what they are doing could quickly beat out all the sentences there.
by HextenAndy on 11/22/22, 12:42 PM
by chrismorgan on 11/22/22, 12:48 PM
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 prefixes would require, not quite so much.
by jzer0cool on 11/22/22, 11:25 PM
by kzrdude on 11/22/22, 2:06 PM
Wraparound doesn't really matter, as long as it's spaced long apart.
by malkia on 11/22/22, 4:39 PM
by nsajko on 11/22/22, 3:30 PM
> No merge commits are created.
> Fast-forward merges only.
> When there is a merge conflict, the user is given the option to rebase.
The maintainer can enable this for a project.
by enriquto on 11/22/22, 11:13 AM
by JoachimS on 11/22/22, 3:15 PM
Kudos to @zegl for this cool project.
by titzer on 11/22/22, 1:59 PM
Brute-forcing hash collisions seems like an April Fool's joke. You can't really be serious that people are going to do this regularly?
by shadytrees on 11/22/22, 12:41 PM
by bcoughlan on 11/22/22, 12:00 PM
I emulate this by counting the number of merges on main:
git rev-list --count --first-parent HEAD
But it's not that traceable (hard to go from a rev back to a commit).
by conaclos on 11/22/22, 12:38 PM
0<suffix>
10<suffix>
20<suffix>
...
Combined with auto-completion, you preserve the main advantage (ordering) and you are able to quickly compute the hash.by alvis on 11/22/22, 2:50 PM
But! How can I collaborate with my team when PR merges are inevitable? O:
by cranium on 11/22/22, 11:37 AM
by forgotmypw17 on 11/22/22, 1:58 PM
by tambourine_man on 11/22/22, 2:02 PM
by hiergiltdiestfu on 11/22/22, 1:15 PM
I honestly expected this to be from another "really cool date" - April 1st :D
by joosters on 11/22/22, 2:08 PM
by shawabawa3 on 11/22/22, 11:38 AM
by jbergstroem on 11/22/22, 12:14 PM
by low_tech_punk on 11/22/22, 4:25 PM
by chrsig on 11/22/22, 11:49 AM
by jasmer on 11/22/22, 2:41 PM
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.
by lloydatkinson on 11/22/22, 12:42 PM
by hoseja on 11/22/22, 11:16 AM
by zomglings on 11/22/22, 3:14 PM
I find all this hash inverting quite inelegant.
by Pirate-of-SV on 11/22/22, 3:15 PM
by rock_artist on 11/22/22, 1:55 PM
In order to get this 'beautiful' hashes, they're crunching numbers leveraging cpu power?
by breck on 11/22/22, 1:18 PM
by mihaaly on 11/22/22, 3:14 PM
by u801e on 11/22/22, 1:57 PM
by pcthrowaway on 11/22/22, 11:35 AM
by codeulike on 11/22/22, 12:49 PM
by _alex_ on 11/23/22, 1:11 AM
by ccbccccbbcccbb on 11/22/22, 5:41 PM
by pelasaco on 11/22/22, 2:45 PM
by johmue on 11/22/22, 3:18 PM
by unnouinceput on 11/22/22, 11:23 AM