41 ms·

Extremely Linear Git History

• hiergiltdiestfu 4y ago
  wtf, back to SVN :D I honestly expected this to be from another "really cool date" - April 1st :D
• enriquto 4y ago
  I love linear git! Branches are very confusing for a nonempty set of people. For us, it is always clearer to work with explicit files in the main branch. You are implementing a new feature? Nice: just create a new file on the main branch and keep updating it until you add it to the tests, and later you call it from the main program. This system may break down on large teams, but when you are just a handful of grug-brained developers, it's perfectly appropriate.
  • mjburgess 4y ago
    That requires your programming language to identify files with modules, and with your system architecture to be extended by modules alone. This is an ideal case, of course.
    • enriquto 4y ago
      I don't understand your comment. The method that I describe only requires that the programming language ignores unused files. As far as I know, all modern programming languages have this feature.
      • mjburgess 4y ago
        In the way most languages and applications work, a "new feature" requires modification to several existing file.s
        • DaiPlusPlus 4y ago
          .csproj-anxiety The worst is when you move a bunch of files around in Solution Explorer and commit, maybe do a merge and push, before you realise the MSBuild/csproj files were never saved (gotta press Save All for some reason) - now you have a change you need to apply to a pre-merge commit. Good luck with that.
  • bigDinosaur 4y ago
    This doesn't handle the reasonably common case very well where someone is working on changes which are constantly breaking the branch for everyone else. They should have their own branch and be frequently rebasing/merging so as to not disrupt others. Also exploratory branches where any nonsense may go on (that may end up being merged, at least partially!). Also test/development vs. production branches! One may be broken, the production branch should ideally never be in a state that cannot be deployed. That said, keep the branches limited and try to keep them 'linear' in the sense that you don't want to be merging between 100 different non-main branches in some byzantine nightmare. Perhaps encourage merges only to the development branch and then rebranching.
    • Filligree 4y ago
      > Also exploratory branches where any nonsense may go on (that may end up being merged, at least partially!). Also test/development vs. production branches! One may be broken, the production branch should ideally never be in a state that cannot be deployed. Well, why don't you simply copy the code into a new directory and commit that? Then you can do whatever you want in the scratch directory.
      • bigDinosaur 4y ago
        To me that seems messier than a new branch. For one, how are others to know my files are test/scratch/feature branch files? I'd have to use a naming scheme, and some kind of other signal to make sure nobody imports them before they're ready or mistakes them for deployable files - and at that point I'm just replicating a branch!
        • enriquto 4y ago
          > and at that point I'm just replicating a branch! Yes. My entire point is that you can always replicate branches with actual, explicit files, and that this is a good thing to do because files are (very often) better than branches. Files plus some editor discipline are essentially equivalent to branches. Files+discipline are better than branches, according to standard unix philosophy: (1) everything is a file, (2) protocol not policy.
  • aqme28 4y ago
    This feels like a lot of extra work to throw away the benefits you actually get out of version control. I would very much not like to work on this team.
• davide_v 4y ago
  I thought I was a very tidy person, then I saw this.
  • Thev00d00 4y ago
    Im not sure it is tidy to inject random junk into your commit message to get a hash prefix
    • mgsk 4y ago
      Or maybe it is _extremely_ tidy.
      • kreetx 4y ago
        I think the question boils down to "where is the junk?" ;) I.e, there is always junk, some put it in a commit hash, others into the files committed.
        • mikehotel 4y ago
          And now this uses invisible junk (white space). See update: https://news.ycombinator.com/item?id=33704810 https://news.ycombinator.com/item?id=33704810
• hoseja 4y ago
  This is very silly.
  • zegl 4y ago
    Do not try this at home.
  • chii 4y ago
    but fun. Also might as well just mine bitcoins tbh...
• maxbond 4y ago
  Has anyone tried using git alternatives like fossil in production? Did it work out? Did you build CI/CD around it?
• unnouinceput 4y ago
  Extremely Linear Git History...also known as SVN. Guess reinventing the wheel does get you to top HN.
  • adql 4y ago
    You need to do it badly and wastefully.
    • zegl 4y ago
      Using SVN doesn't cause your computer to heat up. ;-)
      • adql 4y ago
        Just someone's else computer
  • mgsk 4y ago
    Are you allergic to fun? :(
  • oneeyedpigeon 4y ago
    This is Hacker News. You could add this as a canonical example in the FAQ as far as I'm concerned.
• Ayesh 4y ago
  I wonder if Git provides a pluggable hashing mechanism as part of SHA2 migration. I imagine stuff like this and SVN to Git mirroring to work nicely with identical hashes.
  • masklinn 4y ago
    Not currently, it’s a repo-level flag and you get one or the other. It’ll undoubtedly be easier to further expand, but it’s nowhere near pluggable.
• pcthrowaway 4y ago
  I mean.. this kind of breaks down if you have more than one person on the team
  • globular-toast 4y ago
    It just means you have to coordinate more. Or just have one person in charge of the master branch. I don't think the post is supposed to be taken so seriously, though.
    • Zoadian 4y ago
      which just means: lets waste many hours coordinating, for the benefit of having a 'nice looking' history.
      • eru 4y ago
        You realise that this is a joke project?
        • chrismorgan 4y ago
          I would not call this a joke project. It’s a fun and optional sort of a thing, but there’s no reason why you shouldn’t take it seriously, provided your approach to work makes it compatible.
          • eru 4y ago
            Why would you want to take it serious?
      • breck 4y ago
        Commit once read forever
• kinduff 4y ago
  See also Lucky Commit [0], which uses various types of whitespace characters instead of a hash inside the commit, which makes it look more magical. I wonder about performance, though. Why is the author's method slower than the package I linked? [0]: https://github.com/not-an-aardvark/lucky-commit https://github.com/not-an-aardvark/lucky-commit
  • zegl 4y ago
    Thanks for sharing, this is really cool! Using whitespace is a really clever trick, and running on the GPU makes it even more impressive. I've been using githashcrash [1], but it's only running on the CPU, which is why it's a bit slower. :-) [1]: https://github.com/Mattias-/githashcrash https://github.com/Mattias-/githashcrash
    • zegl 4y ago
      Update: git-linearize now uses lucky_commit as it's backend!
      • kretaceous 4y ago
        I haven't checked your codebase so I don't know how easy it was but damn, you replaced your backend within 16 minutes according to your comment timings. That's some nice modularization. Good job!
        • zegl 4y ago
          You're giving me too much credit. The script [1] is only 50 lines of bash. [1]: https://github.com/zegl/extremely-linear/blob/0011003da131322e632761a7b8e47b2e77692f94/git-linearize#L64-L111 https://github.com/zegl/extremely-linear/blob/0011003da13132...
    • oneeyedpigeon 4y ago
      Using whitespace is cool, but you know what would be really cool? Using a thesaurus to reword the commit message until it matches the hash :)
• cranium 4y ago
  Now, merge only the next-in-line hashes and the contributions to your repo can reach Cloud Scale™. Harness the ultimate power of distributed intelligent agents to create the future, backed by strong mathematical foundations and an ecosystem of innovative technologies. Just at your fingertips
• otikik 4y ago
  This is horrible and I like it.
• shawabawa3 4y ago
  Sadly if you use commit signing it's unfeasibly slow to do this :(
  • imiric 4y ago
    You think signing is what makes this unfeasibly slow? :)
  • mkj 4y ago
    It shouldn't be, won't the signature be made after the hash brute force is finished?
    • chipsa 4y ago
      The signature is part of the commit hash.
• Semaphor 4y ago
  > Full collision (entire hash is zeros, then 000...1, etc.) — `git linearize --format "%040d"` (takes ~10³³ years to run per commit) Hah :D
• ChrisMarshallNY 4y ago
  I find tags to be a fairly useful way of providing a linear progression, but I guess that's no fun. > 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-tofu-scale https://www.perforce.com/video-tutorials/vcs/mainline-model-...
  • actuallyalys 4y ago
    Yeah, I think tags are a more practical way of accomplishing this. If you’re really interested in having a linear history, it might also make sense to switch to an alternative. Mercurial has linear version numbers and can even push to Git repositories. At risk of coming across as a humorless Hacker News commenter, I will add that I enjoyed this post. It’s a neat hack!
    • ChrisMarshallNY 4y ago
      Yes, it is a cool hack. I enjoy these, even if I can't find a practical application.
• chrsig 4y ago
  Cool hacker project, learned stuff about git reading the article. I don't want to put this into practice, and don't see the utility of it.
  • guipsp 4y ago
    It's not supposed to be put into practice, and it's not supposed to be useful.
• gyulai 4y ago
  Sane revision numbers are among the many reasons I prefer SVN to GIT.
  • jstimpfle 4y ago
    You could automatically tag each uploaded commit with a number drawn from a sequence - using a git post-update hook. The only problem is that this centralizes the process. It's not possible to have fully "blessed" commits without pushing them first. And that's how SVN works, too.
    • loeg 4y ago
      For local repositories, you can do it as a post-commit hook. In the hook: prefix=whatever old=$(git rev-parse HEAD) new=$(brute force $prefix) git update-ref -m "chose prefix $prefix" --create-reflog HEAD "$new" Of course, it's pretty silly and slow.
  • MAGZine 4y ago
    ... What are the other reasons?
    • gyulai 4y ago
      Basically, not to put too fine a point on it, I believe that distributed version control is a problem no one ever truly had, and no one intends to ever have in the future. I mean: Imagine going back in time 20 years to when git, hg, and bzr were created and telling the creators of those tools: "Hey, while designing your technology, you should be aware that it'll end up being used as a worldwide centralized monorepo run by Microsoft, and no one will ever use any of that distributed stuff." They'll either laugh you out of the room or you'll be in trouble with the Department of Temporal Investigations for polluting the time line, because what we currently understand as git sure as hell won't be the design they'll come up with. So for me: I prefer centralized. And SVN is just a reasonable one to use.
      • breck 4y ago
• bcoughlan 4y ago
  I wish Git had more support for "linear" revisions in the main branches. It's great for continuous delivery where you can get a unique identifier that's also human-friendly. 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).
  • tazjin 4y ago
    We do this at TVL, and push the corresponding revision as a ref (refs/r/$n) back to git. See for example our cgit log view: https://code.tvl.fyi/log/ https://code.tvl.fyi/log/ This way, a correctly configured git client (which pulls those refs) can use `git checkout r/1234` to get to that revision. It's also noteworthy that this is effectively stateless, so you can reproduce the exact revisions locally with a single shell command without fetching them from the remote. The revisions themselves are populated in CI: https://cs.tvl.fyi/depot@c537cc6fcee5f5cde4b0e6f8c5d6dcd5d8e3690f/-/blob/ops/pipelines/static-pipeline.yaml?L20-32 https://cs.tvl.fyi/depot@c537cc6fcee5f5cde4b0e6f8c5d6dcd5d8e...
• jbergstroem 4y ago
  The Webkit project would love this. Can't help but feel that half the reason they spent all the extra effort with subversion was user-friendly commit revisions.
• oneeyedpigeon 4y ago
  I bet I wasn't the first person who thought this would have to be done by modifying actual file content — e.g. a dummy comment or something. That would clearly have been horrible, but the fact that git bases the checksum off the commit message is... surprising and fortunate, in this case!
  • entropy_ 4y ago
    It's a hash of everything that goes into a commit, including the commit message. The idea is that nothing that makes up a commit can change without changing the hash.
    • mjochim 4y ago
      > It's a hash of everything that goes into a commit, including the commit message ... and, very notably, the hash of the parent commit. That is also part of the commit, which means that changing a parent commit would also imply changing the hashes of all later commits. This is sort of the whole point of git/version control.
      • ludwigvan 4y ago
        Poor man’s blockchain it is, then :)
      • Biganon 4y ago
        This might be a stupid question, but does anyone call git history a blockchain, then? A centralized blockchain, without proof of work or proof of anything really of course, but still, it sounds like the basic blockchain idea is there
        • erik_seaberg 4y ago
          Git branches form a https://en.wikipedia.org/wiki/Merkle_tree https://en.wikipedia.org/wiki/Merkle_tree. Blockchain forks do also, but the goal is usually to ignore all but the longest.
  • 4y ago
• larschdk 4y ago
  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 track of what changes were done on the branch and which where done on the mainline.
  • eurasiantiger 4y ago
    It is also a security risk. Someone could add whatever unreviewed code and it would get glanced over as a merge commit. Put your payload in an innocuous file not likely to be touched and call a boilerplate-looking function as a side effect from somewhere.
  • masklinn 4y ago
    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 merges become a possibility it’s probably a mistake.
    • losvedir 4y ago
      > 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?
      • neweroldguy 4y ago
        This is what I do unless I’m working with a large number of people on the feature branch (which is rare, usually that would be multiple branches). You get the equivalent of “mergeless” history (just restrict your git log to merge commits) but can dig into the individual feature histories easily.
• chrismorgan 4y ago
  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.
  • jrmg 4y ago
    How do you make the first commit 0000000? (Without using this project, obviously).
    • robertlagrant 4y ago
      Might be by using that hashcrash tool.
    • chrismorgan 4y ago
      lucky_commit
    • boxed 4y ago
      You only need to do it once if it's the first commit and you make it empty...
• conaclos 4y ago
  Another approach could be to use prefixes. A 0 could separate the prefix (fixed hash part) from the suffix (random part). 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.
• shadytrees 4y ago
  There's a memorable Stripe CTF from 2014 that had something similar (Gitcoins). This brought back fond memories of that.
• lloydatkinson 4y ago
  I am confused. Why not use git tags for versioning?
• HextenAndy 4y ago
  Wait until you see subversion :)
  • breck 4y ago
    Two steps forward one step back. So it goes.
• chrismorgan 4y ago
  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 prefixes would require, not quite so much.
  • zegl 4y ago
    I left some details out of the post to make it shorter. What I’m actually is doing is generating a 7-digit incremental number followed by a fixed 0. Some UIs show 7 characters and some show 8, this felt like a nice compromise. Plus it’s easier to distinguish between the prefix and the suffix when looking at the full SHA when they are always separated by a 0.
  • avar 4y ago
    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 default.
    • chrismorgan 4y ago
      There may be some extra trigger that causes it to go beyond seven for everything, I don’t know (never worked on a repository anywhere near that large), but there’s certainly still at least some form of collision logic in there (and this is why I said what I said, because I’ve used lucky_commit enough to experience it): $ 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) one
• codeulike 4y ago
  So this is for if you want to use Git as if its Subversion?
• wirrbel 4y ago
  I think the sweet spot in Developer productivity was when we had SVN repos and used git-svn on the client. Commits were all rebased on git level prior to pushing. If you committed something that broke unit tests your colleagues would pass you a really ugly plush animal of shame that would sit on your desk until the next coworker broke the build. 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.
  • tomtom1337 4y ago
    This (plush toy and projector) has “feel good” all over it :)
  • sshine 4y ago
    > If you committed something that broke unit tests your colleagues would pass you a really ugly plush animal of shame that would sit on your desk until the next coworker broke the build. We did have an ugly plush animal, but it served more obscure purposes. For blame of broken builds, we had an info screen that counted the number of times a build had passed, and displayed below the name of the person who last broke it. Explaining to outsiders and non-developers that "Yes, when you make a mistake in this department, we put the person's name on the wall and don't take it down until someone else makes a mistake" sounds so toxic. But it strangely enough wasn't so harsh. Of course there was some stigma that you'd want to avoid, but not to a degree of feeling prolonged shame.
    • cfuendev 4y ago
      No joke, a few weeks ago a colleague from university shared a few anecdotes about his mentor-coworker-boss at work with me, and it's similar. Every time they broke the production branch and the boss had to change the code or pull out some AWS magic to restore a database, he would give the fixed commits names like "Cgada de [Employee Name]" which roughly translates to "[Employee Name] F*ed Up", since he knew they wouldn't forget it that way. It's specially cool given that he would always see his employees' f*k-ups as learning opportunities. He would always teach them what went wrong and how to fix it before shaming them in the git history. He always told them he did it to assure they wouldn't forget both the shameful f*k-up + the bit of learning that came along with it. They always laugh it off and understand the boss' intentions. It isn't harsh or anything.
• breck 4y ago
  This is absolutely genius. Would be nice to upstream it and make it fast. I would start using it.
• rock_artist 4y ago
  To make sure I've got it right. In order to get this 'beautiful' hashes, they're crunching numbers leveraging cpu power?
  • contradictioned 4y ago
    yep
  • kzrdude 4y ago
    Yep. If you squint it's similar to bitcoin mining in that particular aspect
    • Bellyache5 4y ago
      And vanity Tor .onion addresses
• u801e 4y ago
  Why does the version skip from 19 to 20? What about 1A, 1B, 1C, 1D, 1E, and 1F?
  • cjbprime 4y ago
    It's using a neat numbering system called "decimal", you should check it out.
• forgotmypw17 4y ago
  I am writing a solo project. I only use main (aka master) and never use branching. Otherwise, I inevitably screw something up. It is good enough to keep me from losing stuff most of the time, and I almost never have to struggle with understanding what the heck Git is doing.
• titzer 4y ago
  I prefer a linear version number on the main branch and I have a really tiny version file that gets incremented on every change to the src/ directory. That's not entirely automated, but a commit queue could do that. 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?
  • javier123454321 4y ago
    I don't think people actually take this project seriously
• tambourine_man 4y ago
  The fact that we use a hash as the main way to interact with commits shows how bad git interface is. Sure, you should be able to easily check the sha anytime, but expose the plumbing to end users on almost any interaction is mad. We just got used to it.
• kzrdude 4y ago
  Clever and tempting. I would maybe like to use a smaller prefix but ensure a 0 suffix to the number too, to make it easy to read anyway. Like 00010bad, 00020fed, 00030be1, etc.. Wraparound doesn't really matter, as long as it's spaced long apart.
• joosters 4y ago
  Just like perforce and its "p4 changes" command. I like the simplicity.
• jasmer 4y ago
  Wouldn't it have been better if we could use something other than SHA1 as the actual name of something? 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.
  • jonstewart 4y ago
    I don’t want to make up a good name for every commit. Good comments are hard enough. A SHA-1 might not look friendly to a dev who doesn’t understand it, but as someone who works with hash values all the time, having my repo be a Merkle tree gives me a warm fuzzy.
    • jasmer 4y ago
      You wouldn't 'make one up' there would be an automatic variation of Semantic Versioning, or something actually useful. Your 'warm and fuzzy' comes at the cost of confusion (even to yourself), not having any clue what the information really means. It's not even clear that it's a commit, it could be anything. This posture is exactly what I'm complaining about: it's objectively bad design engineering, embraced as though somehow it's 'smart'. Git has a few problems like this.
      • jonstewart 4y ago
        Git has problems: stipulated. Improvements in design are possible: also stipulated. But, your reply is annoying in opining about my mental state and preferences. How am I confused by the SHA-1 commits, exactly? And how am I unclear that I’m looking at commits when I issue a “git log”?
• zegl 4y ago
  I don't know how stupid this is on a scale from 1 to 10. I've created a wrapper [1] for git (called "shit", for "short git") that converts non-padded revisions to their padded counterpart. 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 https://github.com/zegl/extremely-linear/blob/main/shit
  • informalo 4y ago
    Other customers also brew-installed: fuck [1] [1]: https://github.com/nvbn/thefuck https://github.com/nvbn/thefuck
  • thih9 4y ago
    Why the trailing zero? The article quotes hashes starting with "0000001", or "0000014". Shouldn't "shit show 14" get converted to "git show 0000014"?
  • couchand 4y ago
    Thank you for addressing my one and only concern with this scheme! No notes.
  • anderskaseorg 4y ago
    You may want to take a look at the monotonic commit numbering scheme that Git already has, before trying to hack one into the hashes: https://git-scm.com/docs/git-describe https://git-scm.com/docs/git-describe
• pelasaco 4y ago
  if it was SHA256 we could find an usage for all bitcoin miners that we have...
• jordigh 4y ago
  Mercurial always has had sequential revision numbers in addition to hashes for every commit. 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.
  • silvestrov 4y ago
    Seems like a design fault in git that commits only have a single id (sha1 hash) and that hashes are written without any prefix indicating which type of id it is. If all hashes were prefixed with "h", it would have been so simple to add another (secure) hash and a serial number. E.g. h123456 for the sha1, k6543 for sha256 and n100 for the commit number.
• alvis 4y ago
  It look appealing from a perfectionist point of view. But! How can I collaborate with my team when PR merges are inevitable? O:
• blux 4y ago
  I fail to see the point of this, in fact, I think this is a fundamentally flawed approach to dealing with your revision history. The problem is that rebasing commits has the potential of screwing up the integrity of your commit history. 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.
  • michaelmior 4y ago
    This somewhat depends on how big your features are. Arguably, large long-lived feature branches are the problem themselves. If larger features are broken down and developed/merged piecemeal, then you still have smaller commits you can fall back on. IIRC, GitHub uses a development model where partially implemented features are actually deployed to production, but hidden behind feature flags.
  • thewebcount 4y ago
    > 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. To me this is like saying to a construction worker: “The problem is not that your hammer has sharp spikes coming out of the handle at every angle. The problem is that you don’t put on a chain mail glove when using it.” That’s certainly one way to look at it.
    • ranguna 4y ago
      Pretty analogy, but I don't see how a specific functionality of git (commit history) that has no use case other that looking tidy compares to a handle of a hammer.
  • tcoff91 4y ago
    If people knew about --first-parent everyone could stop complaining about merge commits in the history.
• deleted 4y ago
  [deleted]
• zomglings 4y ago
  Is it possible to change the checksum implementation that git uses, through configuration or a plugin? I find all this hash inverting quite inelegant.
  • yjftsjthsd-h 4y ago
    There's an effort to add support for sha256, but it's... not recommended https://lwn.net/Articles/898522/ https://lwn.net/Articles/898522/
• mihaaly 4y ago
  Sounds great for a single person project but perhaps a simpler VCS was better then?
• Pirate-of-SV 4y ago
  Very good! I use this hack every day in winter to heat my apartment (charging laptop at work, run git brute force at home).
• JoachimS 4y ago
  A neat trick with this tool is to generate a commit message that corresponds to a given issue number. It could almost be useful. Kudos to @zegl for this cool project.
  • mjochim 4y ago
    > It could almost be useful. I'm still pondering the “almost” ;-).
• johmue 4y ago
  this is a joke right?
• deleted 4y ago
  [deleted]
• sagebird 4y ago
  “ So we only have one option: testing many combinations of junk data until we can find one that passes our criteria. “ 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 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.
• nsajko 4y ago
  Gitlab supports an option called "Fast-forward merge": > 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.
  • spyremeown 4y ago
    So does almost every PR-based workflow tool for (bitbucket, GitHub etc). It's very common.
• low_tech_punk 4y ago
  Extremely effective way to waste electricity and emit CO2.
• malkia 4y ago
  Hail p4, g4, svn and blessed be their monotonically increasing revision number!
  • cerved 4y ago
    All hail centralized version control, make life slow again!
    • charcircuit 4y ago
      Decentralized version control is slower than centralized version control since it requires downloading and working with the entire repository.
      • cerved 4y ago
        True, but at least you don't have to download on every checkout
• ccbccccbbcccbb 4y ago
  <sarcasm> But what's the carbon footprint and contributed sea level rise of this frivolity? </sarcasm>
  • housel 4y ago
    This is a serious criticism... even if it's not likely to catch on enough to have a real effect on the sea level, it is a complete waste of energy to accomplish something that could be done much more efficiently some other way, if it is indeed worth doing at all.
• infogulch 4y ago
  Github-style rebase-only PRs have revealed the best compromise between 'preserve history' and 'linear history' strategies: 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).
  • pnt12 4y ago
    I wholeheartedly agree! With this, you can also push people towards smaller PRs which are easier to review and integrate. The downside is that if you és o work on feature 2 based on feature 1,either you wait for the PR to be merged in main (easiest approach) or you fork from your feature branch directly and will need to rebase later (this can get messier, especially if you need to fix errors in feature 1).
    • przemo_li 4y ago
      Git branchless have restack command that restacks whole trees/branches of commits.
    • alvarlagerlof 4y ago
      Second part explains exactly what I'm juggling with right now.
    • bpugh 4y ago
      Git recently added a --update-refs option to rebase that makes dealing with this scenario a lot easier. This post does a good job explaining how to use it: https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/ https://andrewlock.net/working-with-stacked-branches-in-git-...
• bloppe 4y ago
  This is a fun idea, but it will mess with your GC heuristics. https://git-scm.com/docs/git-gc#_configuration 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.
  • chrismorgan 4y ago
    Could use little-endian numbers to avoid this: 0000, 1000, 2000, 3000, …, e000, f000, 0100, …
• jzer0cool 4y ago
  I had in past some teammates merging master into a very old branch. This get's pushed back into master with every past history already committed. Could someone suggest series of command so that only their latest updates are separately moved to latest version of master on current or new branch?
• _alex_ 4y ago
  Proof of work git hashes. This is nuts and I love it.