12 ms·

20 years of Git

306 points by videlov 1y ago

deleted 1y ago
[deleted]
alkh 1y ago
Thanks for the useful article! In addition to a lot of interesting info, it lead me to this repo containing an intro to git internals[1]. Would highly recommend everyone to take a look [1] https://github.com/pluralsight/git-internals-pdf https://github.com/pluralsight/git-internals-pdf
- schacon 1y ago
  Ah yes. It was pretty cool that when Peepcode was acquired, Pluralsight asked me what I wanted to do with my royalties there and was fine with me waiving them and just open-sourcing the content. It also is a testament to the backwards compatibility of Git that even after 17 years, most of the contents of that book are still relevant.
jmclnx 1y ago
Yes, still odd, but I can deal with it. FWIW, I just found out you can sign commits using ssh keys. Due to how pinentry + gnupg + git has issues on OpenBSD with commit signing, I just moved to signing via ssh. I had a workaround, but it was a real hack, now no issues! 20 years, wow seems like yesterday I moved my work items from cvs to git. I miss one item in cvs ($Id$), but I learned to do without it.
- fragmede 1y ago
  I don't know if it's lucky or unlucky for you that you managed to skip Subversion
  - jmclnx 1y ago
    :) Professionally, I went from nothing to RCS then to CVS then to git. In all cases I was the one who insisted on using some kind of source code control in the group I worked with. Not being an admin, I set up RCS on the server, then later found some other group that allowed us to use their CVS instance. Then when M/S bought github the company got religion and purchased a contract for git. Getting people to use any kind of SC was a nightmare, this was at a fortune 500 company. When I left, a new hire saw the benefit of SC and took over for me :) In the old days, loosing source happened a lot, I did not what that to happen when I was working at that company.
- wiktor-k 1y ago
  Oh yeah, SSH signing is incredible. I've also migrated to it and didn't look back. A couple of differences: - it's possible to specify signing keys in a file inside the repository, and configure git to verify on merge (https://github.com/wiktor-k/ssh-signing/ https://github.com/wiktor-k/ssh-signing/). I'm using that for my dot config repo to make sure I'm pulling only stuff I committed on my machines. - SSH has TPM key support via PKCS11 or external agents, this makes it possible to easily roll out hardware backed keys - SSH signatures have context separation, that is it's not possible to take your SSH commit signature and repurpose it (unlike OpenPGP) - due to SSH keys being small the policy file is also small and readable, compare https://github.com/openssh/openssh-portable/blob/master/.git_allowed_signers https://github.com/openssh/openssh-portable/blob/master/.git... with equivalent OpenPGP https://gitlab.com/sequoia-pgp/sequoia/-/blob/main/openpgp-policy.toml?ref_type=heads https://gitlab.com/sequoia-pgp/sequoia/-/blob/main/openpgp-p...
  - tarasglek 1y ago
    Wow that allowed signers feature is cool. should pair nicely with ssh key support in sops
- rwoerz 1y ago
  AFAIR keyword substitution of $Id$ included the revision number. That would be the commit hash in Git. For obvious reasons you cannot insert a hash value in content from which that hash value is being computed.
  - schacon 1y ago
    You can use smudge and clean filters to expand this into something on disk and then remove it again before the hash computation runs. However, I don't think you would want to use the SHA, since that's somewhat meaningless to read. You would probably want to expand ID to `git describe SHA` so it's more like `v1.0.1-4-ga691733dc`, so you can see something more similar to a version number.
- schacon 1y ago
  You can probably setup smudge and clean filters in Git to do keyword expansion in a CVS-like way.
WalterBright 1y ago
Around 2002 or so, I had an idea to tag every part of a project with a unique hash code. With a hash code, one could download the corresponding file. A hash code for the whole project would be a file containing a list of hash codes for the files that make up the project. Hash codes could represent the compiler that builds it, along with the library(s) it links with. I showed it to a couple software entrepreneuers (Wild Tangent and Chromium), but they had no interest in it. I never did anything else with it, and so it goes.
- DiggyJohnson 1y ago
  Hey Walter, what would you improve with Git?
  - WalterBright 1y ago
    Git hasn't quite taken the step of making the hash the URL you use to download a file, any file, and be assured it is exactly what you thought it was, as the hash of the file must match its URL. This is currently done in a haphazard way, not particularly organized.
    - exe34 1y ago
      git over ipfs then?
      - mdaniel 1y ago
        I believe that's approximately what this is trying to do https://radicle.xyz/#:~:text=radicle%20is%20an%20open%20source%2C%20peer-to-peer%20code%20collaboration%20stack%20built%20on%20git https://radicle.xyz/#:~:text=radicle%20is%20an%20open%20sour... although evidently using a custom protocol not ipfs itself
- swsieber 1y ago
  While I get how that's like git, it sounds even closer to unison: https://softwaremill.com/trying-out-unison-part-1-code-as-hashes/ https://softwaremill.com/trying-out-unison-part-1-code-as-ha...
Zambyte 1y ago
Speaking of git front ends, I want to give a shout-out to Jujutsu. I suspect most people here have probably at least heard of it by now, but it has fully replaced my git cli usage for over a year in my day to day work. It feels like the interface that jj provides has made the underlying git data structures feel incredibly clear to me, and easy to manipulate. Once you transition your mental model from working branch with a staging area to working revision that is continuously tracking changes, it's very hard to want to go back.
- steveklabnik 1y ago
  GitButler and jj are very friendly with each other, as projects, and are even teaming up with Gerrit to collaborate on the change-id concept, and maybe even have it upstreamed someday: https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf1Aa5gPr0FXzdcywqUUw@mail.gmail.com/ https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf...
  - AceJohnny2 1y ago
    This is exciting, convergence is always good, but I'm confused about the value of putting the tracking information in a git commit header as opposed to a git trailer [1] where it currently lives. In both cases, it's just metadata that tooling can extract. Edit: then again, I've dealt with user error with the fragile semantics of trailers, so perhaps a header is just more robust? [1] https://git-scm.com/docs/git-interpret-trailers https://git-scm.com/docs/git-interpret-trailers
    - steveklabnik 1y ago
      I'm not an expert on this corner of git, but a guess: trailer keys are not unique, that is Signed-off-by: Alice <alice@example.com> Signed-off-by: Bob <bob@example.com> is totally fine, but Change-id: wwyzlyyp Change-id: sopnqzkx is not. I've also heard of issues with people copy/pasting commit messages and including bits of trailers they shouldn't have, I believe.
      - 1y ago
esafak 1y ago
> He meant to build an efficient tarball history database toolset, not really a version control system. He assumed that someone else would write that layer. Famous last words: "We'll do it the right way later!"
- zahlman 1y ago
  On the flip side: when you do intend to make a larger project like that, consciously focusing on the internal utility piece first is often a good move. For example, Pip doesn't offer a real API; anyone who wants their project to install "extra" dependencies dynamically is expected to (https://stackoverflow.com/questions/12332975 https://stackoverflow.com/questions/12332975) run it as a subprocess with its own command line. I suspect that maintaining Pip nowadays would be much easier if it had been designed from that perspective first, which is why I'm taking that approach with Paper.
palata 1y ago
> I would love to do a whole blog post about how mailing list collaboration works and how cool various aspects of it are, but that’s for another time. This is actually the part I would be interested in, coming from a GitHub cofounder.
- schacon 1y ago
  You'll be the first to know when I write it. However, if anything, GitHub sort of killed the mailing list as a generally viable collaboration format outside of very specific use cases, so I'm not sure if I'm the right person to do it justice. However, it is a very cool and unique format that has several benefits that GitHub PR based workflows really lose out on.
  - jen20 1y ago
    By far my biggest complaint about the GitHub pull request model right now is that it doesn't treat the eventual commit message of a squashed commit (or even independent commits that will be rebased on the target) as part of the review process, like Gerrit does. I can't believe I'm the only person that is upset by this!
    - schacon 1y ago
      If this is something you're interested in, you may want to try the patch-based review system that we recently launched for GitButler: https://blog.gitbutler.com/gitbutlers-new-patch-based-code-review/ https://blog.gitbutler.com/gitbutlers-new-patch-based-code-r...
      - jen20 1y ago
        This does look interesting! I’ll take a closer look.
    - bhasi 1y ago
      You are not alone. Coming from Gerrit myself, I hate that GitHub does not allow for commenting on the commit message itself. Neither does Gitlab. Also, in a PR, I find that people just switch to Files Changed, disregarding the sequence of the commits involved. This intentional de-emphasis of the importance of commit messages and the individual commits leads to lower quality of the git history of the codebase.
zwieback 1y ago
Of all the many source control systems I've used git has the worst usability yet it's my favorite
- esafak 1y ago
  Why?
  - steveklabnik 1y ago
    Not your parent. I never understood the "git cli sucks" thing until I used jj. The thing is, git's great, but it was also grown, over time, and that means that there's some amount of incoherence. Furthermore, it's a leaky abstraction, that is, some commands only make sense if you grok the underlying model. See the perennial complaints about how 'git checkout' does more than one thing. It doesn't. But only if you understand the underlying model. If you think about it from a workflow perspective, it feels inconsistent. Hence why newer commands (like git switch) speak to the workflow, not to the model. Furthermore, some features just feel tacked on. Take stashing, for example. These are pseudo-commits, that exist outside of your real commit graph. As a feature, it doesn't feel well integrated into the rest of git. Rebasing is continually re-applying `git am`. This is elegant in a UNIXy way, but is annoying in a usability way. It's slow, because it goes through the filesystem to do its job. It forces you to deal with conflicts right away, because git has no way of modelling conflicts in its data model. Basically, git's underlying model is great, but not perfect, and its CLI was grown, not designed. As such, it has weird rough edges. But that doesn't mean it's a bad tool. It's a pretty darn good one. But you can say that it is while acknowledging that it does have shortcomings.
    - kccqzy 1y ago
      It's more than that; it's also git's incredibly unfriendly way of naming things. Take for example the "index" which is actually a useful thing with a bad name. Most tutorials start by explaining that the index is a staging area on which you craft your commit. Then why is it called index and not staging area? Incredibly bad name right there from the get go. If you ask what the word "index" means in computer science, people usually think of indices into an array, or something like a search index that enables faster searching. Git's index doesn't do any of that. And git's model leaks so much implementation detail that many people mistake these for essential concepts; there are people who would tell you any version control system that doesn't have the "index" is not worth using because they don't allow one to craft beautiful commits. That's patently false as shown by jj and hg. This useful concept with a bad name becomes one amorphous thing that people cannot see past.
jakub_g 1y ago
Very interesting to get some historical context! Thanks for sharing Scott. Small remark: > As far as I can tell, this is the first time the phrase “rebase” was used in version control ClearCase (which I had a displeasure to use) has been using the term "rebase" as well. Googling "clearcase rebase before:2005" finds [0] from 1999. (by the way, a ClearCase rebase was literally taking up to half an hour on the codebase I was working on - in 2012; instant git rebases blew my mind). [0] https://public.dhe.ibm.com/software/rational/docs/documentation/manuals/cc42win/cc_intro.pdf https://public.dhe.ibm.com/software/rational/docs/documentat...
- schacon 1y ago
  Good pull. I was wondering if that was a true statement or not. I am curious if Linus knew about that or made it up independently, or if both came from somewhere else. I really don't know.
piokoch 1y ago
We should say thank you to greedy BitKeeper VCS owners, who wanted Linus Torvalds to pay them money for keeping Linux source in their system. They managed to piss of Linus sufficiently, so he sat down and created Git.
szvsw 1y ago
As someone who wrote my first line of code in approx 2010 and used git & GH for the first time in… 2013? it kind of amazes me to remember that Git is only 20 years old. GitHub for instance doesn’t seem surprising to me that is <20 years old, but `git` not existing before 2005 somehow always feels shocking to me. Obviously there were other alternatives (to some extent) for version control, but git just has the feeling of a tool that is timeless and so ingrained in the culture that it is hard to imagine (for me) the idea of people being software developers in the post-mainframe age without it. It feels like something that would have been born in the same era as Vim, SSH, etc (ie early 90s). This is obviously just because from the perspective of my programming consciousness beginning, it was so mature and entrenched already, but still. I’ve never used other source control options besides git, and I sometimes wonder if I ever will!
- eterm 1y ago
  What surprises me more is how young Subversion is in comparison to git, it's barely older. I guess I started software dev at a magic moment pre-git but after SVN was basically everywhere, but it felt even more like it had been around forever vs the upstart git.
  - mrlonglong 1y ago
    I'm old enough to have used RCS. Very primitive and CVS was soon in use. Git is a breath of fresh air compared to these ones.
    - eterm 1y ago
      Any version control where you had to manually (and globally) "check out" (lock) files for editing was terrible and near unusable above about 3 people. Version control systems where you didn't have shallow branches ( and thus each "branch" took a full copy / disk space of files) were awful. version control systems which would have corruption data-bases (Here's to you Visual source safe) were awful. Subversion managed to do better on all those issues, but it still didn't adequately solve distributed working issues. It also didn't help that people often configured SVN to run with the option to add global locks back in, because they didn't understand the benefit of letting two people edit the same file at the same time. I have a soft-spot for SVN. It was a lot better than it got credit for, but git very much stole the wind from under its sails by solving distributed (and critically, disconnected/offline) workflows just a bit better that developers could overlook the much worse UX, which remains bad to this day.
bananapub 1y ago
since it seems it has been forgotten, remember the reason Git was created is that Larry McVoy, who ran BitMover, which had been donating proprietary software licenses for BitKeeper to core kernel devs, got increasingly shirty at people working on tools to make BK interoperate with Free tools, culminating in Tridge showing in an LCA talk that you could telnet to the BK server and it would just spew out the whole history as SCCS files. Larry shortly told everyone he wasn't going to keep giving BK away for free, so Linus went off for a weekend and wrote a crappy "content manager" called git, on top of which perhaps he thought someone might write a proper VC system. and here we are. a side note was someone hacking the BitKeeper-CVS "mirror" (linear-ish approximation of the BK DAG) with probably the cleverest backdoor I'll ever see: https://blog.citp.princeton.edu/2013/10/09/the-linux-backdoor-attempt-of-2003/ https://blog.citp.princeton.edu/2013/10/09/the-linux-backdoo... see if you can spot the small edit that made this a backdoor: if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) retval = -EINVAL;
- mjcarden 1y ago
  I think that was the first time I ever saw Tridge deliver a conference presentation and it was to a packed lecture theatre at the ANU. He described how he 'hacked' BitKeeper by connecting to the server via telnet and using the sophisticated hacker tools at his disposal to convince Bitkeeper to divulge its secrets, he typed: help The room erupted with applause and laughter.
  - harry8 1y ago
    Every single action, including Telnet, including typing help, the nc command, was suggested by the audience with Tridgell prompting with a minimal “how are we going to find out…” A bk client was hacked by the audience in 2 minutes. It was the most devastating take down I’ve ever seen of the attacks. Linus later said the “git” wasn’t Tridgell at all, but in fact Linus himself. I think that was the only lca Linus missed for a few years either side.
qntmfred 1y ago
I think the git usage patterns we've developed and grown accustomed to are proving inadequate for AI-first development. Maybe under the hood it will still be git, but the DX needs a huge revamp.
- overboard2 1y ago
  What do you mean?
  - qntmfred 1y ago
    if I'm working in Cursor for example, ideally the entire chat history and the proposed changes after each prompt need to be stored. that doesn't fit cleanly into current git development patterns. I don't want to have to type commit messages any more. If I ever need to look at the change history, let AI generate a summary of the changes at that point. let me ask an LLM questions about a given set (or range) of changes if I need to. we need a more natural branching model. i don't want to have to create branches and switch between them and merge them. less typing, more speaking.
    - vhantz 1y ago
      You should ask a LLM to create a VCS that will let you not do all these things you don't want to do.
mrlonglong 1y ago
When are we moving to SHA256? Some code bases must be getting massive by now sfter 20 years,
- waynecochran 1y ago
  Are you worried about hash collisions from different objects? The probability of a collision of N distinct objects with SHA-1 is (N choose 2) * 1 / 2^161. For a trillion objects the probability is about 1.7 x 10^-25. I think we can safely write code without collisions until the sun goes super novae.
  - deleted 1y ago
    [deleted]
  - mrlonglong 1y ago
    It's not that I'm worried about, it's the fact malicious files can be crafted for a particular hash that could replace the original.
jordigh 1y ago
There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be the UI, how there wasn’t even a git commit command in the beginning, but it still paints the whole thing in somewhat romantic tones, as if the blob-tree-commit-ref data structure were the perfect representation of data. One particular aspect that often gets left out of this creation myth, especially by the author of Github is that Mercurial had a prominent role. It was created by Olivia Mackall, another kernel hacker, at the same time as git, for the same purpose as git. Olivia offered Mercurial to Linus, but Linus didn’t look upon favour with it, and stuck to his guns. Unlike git, Mercurial had a UI at the very start. Its UI was very similar to Subversion, which at the time was the dominant VCS, so Mercurial always aimed for familiarity without sacrificing user flexibility. In the beginning, both VCSes had mind share, and even today, the mindshare of Mercurial lives on in hg itself as well as in worthy git successors such as jujutsu. And the git data structure isn’t the only thing that could have ever possibly worked. It falls apart for large files. There are workaround and things you can patch on top, but there are also completely different data structures that would be appropriate for larger bits of data. Git isn’t just plain wonderful, and in my view, it’s not inevitable either. I still look forward to a world beyond git, whether jujutsu or whatever else may come.
- brandonmenc 1y ago
  I was always under the impression Monotone - which was released two years before Mercurial - was the inspiration for git, and that this was pretty well known.
  - jordigh 1y ago
    Yes, Monotone partly inspired both. You can see that both hash contents. But both git and hg were intended to replace Bitkeeper. Mercurial is even named after Larry McVoy, who changed his mind. He was, you know, mercurial in his moods.
  - 1y ago
js2 1y ago
> I started using Git for something you might not imagine it was intended for, only a few months after it’s first commit I started using git around 2007 or so because that company I worked for at the time used ClearCase, without a doubt the most painful version manager I have ever used (especially running it from a Linux workstation). So I wrote a few scripts that would let me mirror a directory into a git repo, do all my committing in git, then replay those commits back to ClearCase. I can't recall how Git came to me attention in the first place, but by late 2008 I was contributing patches to Git itself. Junio was a kind but exacting maintainer, and I learned a lot about contributing to open source from his stewardship. I even attended one of the early GitTogethers. As far as I can recall, I've never really struggled with git. I think that's because I like to dissect how things work, and under the covers git is quite simple. So I never had too much trouble with its terribly baroque CLI. At my next job, I was at a startup that was building upon a fork of Chromium. At the time, Chromium was using subversion. But at this startup, we were using git, and I was responsible for keeping our git mirror up-to-date. I also had the terrible tedious job of rebasing our fork with Chromium's upstream changes. But boy did I get good at resolving merge conflicts. Git may be the CLI I've used most consistently for nearly two decades. I'm disappointed that GitHub became the main code-review tool for Git, but I'll never be disappointed that Git beat out Mercurial, which I always found overly ridged and was never able to adapt it to my workflow.
- nocman 1y ago
  > I started using git around 2007 or so because that company I worked for at the time used ClearCase, without a doubt the most painful version manager I have ever used Ah, ClearCase! The biggest pain was in your wallet! I saw the prices my company paid per-seat for that privilege -- yikes!
  - TorKlingberg 1y ago
    I meant to write a blog post titled "What's good about ClearCase" in 2014, and I wish I did because now I've forgotten most of it. ClearCase is a terrible version control system I wouldn't wish on my worst enemy, but it did have some good points that git still doesn't have. Large binary file support, configuration records, winkin, views. With various big companies going towards giant monorepos and the local git repo just being a view into the super-centralized repo, I think they will re-invent parts of ClearCase.
talles 1y ago
Why did git 'won' over mercurial? Because Github was better than Bitbucket? Or maybe because of the influence of kernel devs?
- TiredOfLife 1y ago
  For me it won (10+ years ago) because for some reason git (a deeply linux oriented software) had better Windows support than Mercurial (that boasted about Windows support). You could even add files with names in various writing systems to git. I am not sure that Mercurial can do that even now.
  - cjbillington 1y ago
    Huh, that's not my recollection. Mercurial on windows was "download tortoisehg, use it", whereas git didn't have a good GUI and was full of footguns about line endings and case-insensitivity of branch names and the like. Nowadays I use sublime merge on Windows and Linux alike and it's fine. Which solves the GUI issue, though the line ending issue is the same as it's always been (it's fine if you remember to just set it to "don't change line endings" globally but you have to remember to do that), and I'm not sure about case insensitivity of branch names. Pretty sure Mercurial handles arbitrary filenames as UTF-8 encoded bytestrings, whether there was a problem with this in the past I can't recall, but would be very surprised if there was now. Edit: does seem there at least used to be issues around this: https://stackoverflow.com/questions/7256708/mercurial-problem-with-non-ascii-letters-in-filenames-between-windows-and-linux https://stackoverflow.com/questions/7256708/mercurial-proble... though google does show at least some results for similar issues with git
    - cpeterso 1y ago
      When evaluating successors to CVS back in 2007, Mozilla chose Mercurial because it had better Windows support than git. 18 years later, Mozilla is now migrating from Mercurial to git.
      - binarno_sp 1y ago
yapyap 1y ago
> 20 years ago > 2005 wow.
7e 1y ago
Git, still a ripoff of BitKeeper. All innovation begins as closed source.
- masfoobar 1y ago
  > All innovation begins as closed source I think you need to check your history. In the early days, before closed/proprietary software, source code was often shared between programmers. Lets look at text editors. They did not begin "closed source" - but companies have a team of people to help SELL their products, even if they are inferior to whats already out there. Baically, once computers matured was an opportunity to make a buck. Companies started selling their products for a fee. I would not be surprised if the source code was included before someone realised people can just pay for the executable. More money can be made by excluding the source code so new updates can also be for a fee. (Lets not talk about "End user Licence Agreements" in this post, OK) The "dominance" of closed source is really about companies with money controlling the status quo, with lawyers and sales teams knowing how to push it in favour. Companies like Micro$oft today have soo much money they dictate the direction our computers systems are going. They push it in a direction that favours them. They have a hand controlling the flow, like other big companies having a hand trying to change to stream for their intent and purposes. This is why -- whether you love him or hate him, I have much respects for people like Richard Stallman or others like Linus Torvalds.. to name a few! You want to talk about "innovation" ?? What do you think these "Closed source innovations" are build with? Software is created using a Programming language such as Python, C++, C, Javascript, etc... the VAST MAJORITY being free to use, under some sort of Open Source community! Lets also look at large companies in general.. many of which are not innovating... they are just purchasing smaller companies that are trying to do new things... closed source software or not. Lastly, lets also be honest that innovation is not created out of thin air -- everything is inspired by something previously.. whether a failed experiment or something already successful. New ideas come about with more failures.. but comes further ideas until, eventually, we have something successful! Linux may be inspired by other Operating Systems, and those were inspired by other things, etc. Innovation is progressive. Point I am making, if any company found ANY opportunity to build a closed-source version to shut down a popular Open Source equiverlant... THEY WOULD DO IT!
forgetmunch 1y ago
[flagged]
forgetmunch 1y ago
[flagged]
neves 1y ago
20 years! Which recent Git features do you find useful? I think I've never used any feature less than 10 years old. I'm probably missing something
- ralgozino 1y ago
  I don't know if this is a recent addition, but I started recently to use it: `git worktree` is awesome. It let's you have more than one copy of the repository at different points without doing the stash dance.
  - kruador 1y ago
    This is, in some ways, reintroducing something that other source control systems forced on you (and you can see it in one of the videos that Scott linked, about using BitKeeper - Ep.4 Bits and Booze, https://www.youtube.com/watch?v=MPFgOnACULU https://www.youtube.com/watch?v=MPFgOnACULU). The previous tools I used (SourceGear Vault, MS Team Foundation Services) required you to have a separate working tree for each branch - the two were directly tied together. That's sometimes useful if you need to have the two versions running concurrently, but for short-lived topic branches or, as you say, working on multiple topics at the same time, it can be very inconvenient. Initially it was jarring to not get a different working directory for each branch, but I soon got used to it. Working in the same directory for multiple branches means that untracked files stay around - can be helpful for things like IDE workspace configuration, which is specific to me and the project, but not the branch. You can of course have multiple clones of the repository - even clones of clones - but pushing/pulling branches from one to another is a lot more work than just checking out a branch in a different worktree. My general working practice now is to keep release versions in their own worktree, and using the default worktree (where the .git directory lives) for development on the main branch. That means I don't need to keep resyncing up my external dependencies (node_modules, for example) when switching between working on different releases. But I can see a good overview of my branches, and everything on the remote, from any worktree.
jwrallie 1y ago
Sometimes I ask myself if Torvald's greater contribution to society wouldn't be Git, instead of Linux.
globular-toast 1y ago
> patches and tarballs workflow is sort of the first distributed version control system - everyone has a local copy, the changes can be made locally, access to "merge" is whomever can push a new tarball to the server. Nitpick, but that's not a distributed workflow. It's distributed because anyone can run patch locally and serve the results themselves. There were well known alternative git branches back then, like the "mm" tree run by Andrew Morton. The distributed nature of git is one of the most confusing for people who have been raised on centralised systems. The fact that your "master" is different to my "master" is something people have difficulty with. I don't think it's a huge mental leap, but too many people just start using Gitlab etc. without anyone telling them.
zoobab 1y ago
Decentralized, but centralized.
pjmlp 1y ago
And me 10 years cloning git repos from scratch instead of bothering to learn a plethora of archaic commands only to fix a broken commit. https://xkcd.com/1597/ https://xkcd.com/1597/ And it isn't as if I haven't used RCS, SCCS, CVS, Clearcase, TFS, Subversion, Mercurial before having to deal with Git.

306 points by videlov 1y ago

deleted 1y ago

[deleted]

alkh 1y ago

Thanks for the useful article! In addition to a lot of interesting info, it lead me to this repo containing an intro to git internals[1]. Would highly recommend everyone to take a look [1] https://github.com/pluralsight/git-internals-pdf https://github.com/pluralsight/git-internals-pdf

schacon 1y ago
Ah yes. It was pretty cool that when Peepcode was acquired, Pluralsight asked me what I wanted to do with my royalties there and was fine with me waiving them and just open-sourcing the content. It also is a testament to the backwards compatibility of Git that even after 17 years, most of the contents of that book are still relevant.

jmclnx 1y ago

Yes, still odd, but I can deal with it. FWIW, I just found out you can sign commits using ssh keys. Due to how pinentry + gnupg + git has issues on OpenBSD with commit signing, I just moved to signing via ssh. I had a workaround, but it was a real hack, now no issues! 20 years, wow seems like yesterday I moved my work items from cvs to git. I miss one item in cvs ($Id$), but I learned to do without it.

fragmede 1y ago
I don't know if it's lucky or unlucky for you that you managed to skip Subversion
- jmclnx 1y ago
  :) Professionally, I went from nothing to RCS then to CVS then to git. In all cases I was the one who insisted on using some kind of source code control in the group I worked with. Not being an admin, I set up RCS on the server, then later found some other group that allowed us to use their CVS instance. Then when M/S bought github the company got religion and purchased a contract for git. Getting people to use any kind of SC was a nightmare, this was at a fortune 500 company. When I left, a new hire saw the benefit of SC and took over for me :) In the old days, loosing source happened a lot, I did not what that to happen when I was working at that company.
wiktor-k 1y ago
Oh yeah, SSH signing is incredible. I've also migrated to it and didn't look back. A couple of differences: - it's possible to specify signing keys in a file inside the repository, and configure git to verify on merge (https://github.com/wiktor-k/ssh-signing/ https://github.com/wiktor-k/ssh-signing/). I'm using that for my dot config repo to make sure I'm pulling only stuff I committed on my machines. - SSH has TPM key support via PKCS11 or external agents, this makes it possible to easily roll out hardware backed keys - SSH signatures have context separation, that is it's not possible to take your SSH commit signature and repurpose it (unlike OpenPGP) - due to SSH keys being small the policy file is also small and readable, compare https://github.com/openssh/openssh-portable/blob/master/.git_allowed_signers https://github.com/openssh/openssh-portable/blob/master/.git... with equivalent OpenPGP https://gitlab.com/sequoia-pgp/sequoia/-/blob/main/openpgp-policy.toml?ref_type=heads https://gitlab.com/sequoia-pgp/sequoia/-/blob/main/openpgp-p...
- tarasglek 1y ago
  Wow that allowed signers feature is cool. should pair nicely with ssh key support in sops
rwoerz 1y ago
AFAIR keyword substitution of $Id$ included the revision number. That would be the commit hash in Git. For obvious reasons you cannot insert a hash value in content from which that hash value is being computed.
- schacon 1y ago
  You can use smudge and clean filters to expand this into something on disk and then remove it again before the hash computation runs. However, I don't think you would want to use the SHA, since that's somewhat meaningless to read. You would probably want to expand ID to `git describe SHA` so it's more like `v1.0.1-4-ga691733dc`, so you can see something more similar to a version number.
schacon 1y ago
You can probably setup smudge and clean filters in Git to do keyword expansion in a CVS-like way.

WalterBright 1y ago

Around 2002 or so, I had an idea to tag every part of a project with a unique hash code. With a hash code, one could download the corresponding file. A hash code for the whole project would be a file containing a list of hash codes for the files that make up the project. Hash codes could represent the compiler that builds it, along with the library(s) it links with. I showed it to a couple software entrepreneuers (Wild Tangent and Chromium), but they had no interest in it. I never did anything else with it, and so it goes.

DiggyJohnson 1y ago
Hey Walter, what would you improve with Git?
- WalterBright 1y ago
  Git hasn't quite taken the step of making the hash the URL you use to download a file, any file, and be assured it is exactly what you thought it was, as the hash of the file must match its URL. This is currently done in a haphazard way, not particularly organized.
  - exe34 1y ago
    git over ipfs then?
    - mdaniel 1y ago
      I believe that's approximately what this is trying to do https://radicle.xyz/#:~:text=radicle%20is%20an%20open%20source%2C%20peer-to-peer%20code%20collaboration%20stack%20built%20on%20git https://radicle.xyz/#:~:text=radicle%20is%20an%20open%20sour... although evidently using a custom protocol not ipfs itself
swsieber 1y ago
While I get how that's like git, it sounds even closer to unison: https://softwaremill.com/trying-out-unison-part-1-code-as-hashes/ https://softwaremill.com/trying-out-unison-part-1-code-as-ha...

Zambyte 1y ago

Speaking of git front ends, I want to give a shout-out to Jujutsu. I suspect most people here have probably at least heard of it by now, but it has fully replaced my git cli usage for over a year in my day to day work. It feels like the interface that jj provides has made the underlying git data structures feel incredibly clear to me, and easy to manipulate. Once you transition your mental model from working branch with a staging area to working revision that is continuously tracking changes, it's very hard to want to go back.

steveklabnik 1y ago
GitButler and jj are very friendly with each other, as projects, and are even teaming up with Gerrit to collaborate on the change-id concept, and maybe even have it upstreamed someday: https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf1Aa5gPr0FXzdcywqUUw@mail.gmail.com/ https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf...
- AceJohnny2 1y ago
  This is exciting, convergence is always good, but I'm confused about the value of putting the tracking information in a git commit header as opposed to a git trailer [1] where it currently lives. In both cases, it's just metadata that tooling can extract. Edit: then again, I've dealt with user error with the fragile semantics of trailers, so perhaps a header is just more robust? [1] https://git-scm.com/docs/git-interpret-trailers https://git-scm.com/docs/git-interpret-trailers
  - steveklabnik 1y ago
    I'm not an expert on this corner of git, but a guess: trailer keys are not unique, that is Signed-off-by: Alice <alice@example.com> Signed-off-by: Bob <bob@example.com> is totally fine, but Change-id: wwyzlyyp Change-id: sopnqzkx is not. I've also heard of issues with people copy/pasting commit messages and including bits of trailers they shouldn't have, I believe.
    - 1y ago

esafak 1y ago

> He meant to build an efficient tarball history database toolset, not really a version control system. He assumed that someone else would write that layer. Famous last words: "We'll do it the right way later!"

zahlman 1y ago
On the flip side: when you do intend to make a larger project like that, consciously focusing on the internal utility piece first is often a good move. For example, Pip doesn't offer a real API; anyone who wants their project to install "extra" dependencies dynamically is expected to (https://stackoverflow.com/questions/12332975 https://stackoverflow.com/questions/12332975) run it as a subprocess with its own command line. I suspect that maintaining Pip nowadays would be much easier if it had been designed from that perspective first, which is why I'm taking that approach with Paper.

palata 1y ago

> I would love to do a whole blog post about how mailing list collaboration works and how cool various aspects of it are, but that’s for another time. This is actually the part I would be interested in, coming from a GitHub cofounder.

schacon 1y ago
You'll be the first to know when I write it. However, if anything, GitHub sort of killed the mailing list as a generally viable collaboration format outside of very specific use cases, so I'm not sure if I'm the right person to do it justice. However, it is a very cool and unique format that has several benefits that GitHub PR based workflows really lose out on.
- jen20 1y ago
  By far my biggest complaint about the GitHub pull request model right now is that it doesn't treat the eventual commit message of a squashed commit (or even independent commits that will be rebased on the target) as part of the review process, like Gerrit does. I can't believe I'm the only person that is upset by this!
  - schacon 1y ago
    If this is something you're interested in, you may want to try the patch-based review system that we recently launched for GitButler: https://blog.gitbutler.com/gitbutlers-new-patch-based-code-review/ https://blog.gitbutler.com/gitbutlers-new-patch-based-code-r...
    - jen20 1y ago
      This does look interesting! I’ll take a closer look.
  - bhasi 1y ago
    You are not alone. Coming from Gerrit myself, I hate that GitHub does not allow for commenting on the commit message itself. Neither does Gitlab. Also, in a PR, I find that people just switch to Files Changed, disregarding the sequence of the commits involved. This intentional de-emphasis of the importance of commit messages and the individual commits leads to lower quality of the git history of the codebase.

zwieback 1y ago

Of all the many source control systems I've used git has the worst usability yet it's my favorite

esafak 1y ago
Why?
- steveklabnik 1y ago
  Not your parent. I never understood the "git cli sucks" thing until I used jj. The thing is, git's great, but it was also grown, over time, and that means that there's some amount of incoherence. Furthermore, it's a leaky abstraction, that is, some commands only make sense if you grok the underlying model. See the perennial complaints about how 'git checkout' does more than one thing. It doesn't. But only if you understand the underlying model. If you think about it from a workflow perspective, it feels inconsistent. Hence why newer commands (like git switch) speak to the workflow, not to the model. Furthermore, some features just feel tacked on. Take stashing, for example. These are pseudo-commits, that exist outside of your real commit graph. As a feature, it doesn't feel well integrated into the rest of git. Rebasing is continually re-applying `git am`. This is elegant in a UNIXy way, but is annoying in a usability way. It's slow, because it goes through the filesystem to do its job. It forces you to deal with conflicts right away, because git has no way of modelling conflicts in its data model. Basically, git's underlying model is great, but not perfect, and its CLI was grown, not designed. As such, it has weird rough edges. But that doesn't mean it's a bad tool. It's a pretty darn good one. But you can say that it is while acknowledging that it does have shortcomings.
  - kccqzy 1y ago
    It's more than that; it's also git's incredibly unfriendly way of naming things. Take for example the "index" which is actually a useful thing with a bad name. Most tutorials start by explaining that the index is a staging area on which you craft your commit. Then why is it called index and not staging area? Incredibly bad name right there from the get go. If you ask what the word "index" means in computer science, people usually think of indices into an array, or something like a search index that enables faster searching. Git's index doesn't do any of that. And git's model leaks so much implementation detail that many people mistake these for essential concepts; there are people who would tell you any version control system that doesn't have the "index" is not worth using because they don't allow one to craft beautiful commits. That's patently false as shown by jj and hg. This useful concept with a bad name becomes one amorphous thing that people cannot see past.

jakub_g 1y ago

Very interesting to get some historical context! Thanks for sharing Scott. Small remark: > As far as I can tell, this is the first time the phrase “rebase” was used in version control ClearCase (which I had a displeasure to use) has been using the term "rebase" as well. Googling "clearcase rebase before:2005" finds [0] from 1999. (by the way, a ClearCase rebase was literally taking up to half an hour on the codebase I was working on - in 2012; instant git rebases blew my mind). [0] https://public.dhe.ibm.com/software/rational/docs/documentation/manuals/cc42win/cc_intro.pdf https://public.dhe.ibm.com/software/rational/docs/documentat...

schacon 1y ago
Good pull. I was wondering if that was a true statement or not. I am curious if Linus knew about that or made it up independently, or if both came from somewhere else. I really don't know.

piokoch 1y ago

We should say thank you to greedy BitKeeper VCS owners, who wanted Linus Torvalds to pay them money for keeping Linux source in their system. They managed to piss of Linus sufficiently, so he sat down and created Git.

szvsw 1y ago

As someone who wrote my first line of code in approx 2010 and used git & GH for the first time in… 2013? it kind of amazes me to remember that Git is only 20 years old. GitHub for instance doesn’t seem surprising to me that is <20 years old, but `git` not existing before 2005 somehow always feels shocking to me. Obviously there were other alternatives (to some extent) for version control, but git just has the feeling of a tool that is timeless and so ingrained in the culture that it is hard to imagine (for me) the idea of people being software developers in the post-mainframe age without it. It feels like something that would have been born in the same era as Vim, SSH, etc (ie early 90s). This is obviously just because from the perspective of my programming consciousness beginning, it was so mature and entrenched already, but still. I’ve never used other source control options besides git, and I sometimes wonder if I ever will!

eterm 1y ago
What surprises me more is how young Subversion is in comparison to git, it's barely older. I guess I started software dev at a magic moment pre-git but after SVN was basically everywhere, but it felt even more like it had been around forever vs the upstart git.
- mrlonglong 1y ago
  I'm old enough to have used RCS. Very primitive and CVS was soon in use. Git is a breath of fresh air compared to these ones.
  - eterm 1y ago
    Any version control where you had to manually (and globally) "check out" (lock) files for editing was terrible and near unusable above about 3 people. Version control systems where you didn't have shallow branches ( and thus each "branch" took a full copy / disk space of files) were awful. version control systems which would have corruption data-bases (Here's to you Visual source safe) were awful. Subversion managed to do better on all those issues, but it still didn't adequately solve distributed working issues. It also didn't help that people often configured SVN to run with the option to add global locks back in, because they didn't understand the benefit of letting two people edit the same file at the same time. I have a soft-spot for SVN. It was a lot better than it got credit for, but git very much stole the wind from under its sails by solving distributed (and critically, disconnected/offline) workflows just a bit better that developers could overlook the much worse UX, which remains bad to this day.

bananapub 1y ago

since it seems it has been forgotten, remember the reason Git was created is that Larry McVoy, who ran BitMover, which had been donating proprietary software licenses for BitKeeper to core kernel devs, got increasingly shirty at people working on tools to make BK interoperate with Free tools, culminating in Tridge showing in an LCA talk that you could telnet to the BK server and it would just spew out the whole history as SCCS files. Larry shortly told everyone he wasn't going to keep giving BK away for free, so Linus went off for a weekend and wrote a crappy "content manager" called git, on top of which perhaps he thought someone might write a proper VC system. and here we are. a side note was someone hacking the BitKeeper-CVS "mirror" (linear-ish approximation of the BK DAG) with probably the cleverest backdoor I'll ever see: https://blog.citp.princeton.edu/2013/10/09/the-linux-backdoor-attempt-of-2003/ https://blog.citp.princeton.edu/2013/10/09/the-linux-backdoo... see if you can spot the small edit that made this a backdoor: if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) retval = -EINVAL;

mjcarden 1y ago
I think that was the first time I ever saw Tridge deliver a conference presentation and it was to a packed lecture theatre at the ANU. He described how he 'hacked' BitKeeper by connecting to the server via telnet and using the sophisticated hacker tools at his disposal to convince Bitkeeper to divulge its secrets, he typed: help The room erupted with applause and laughter.
- harry8 1y ago
  Every single action, including Telnet, including typing help, the nc command, was suggested by the audience with Tridgell prompting with a minimal “how are we going to find out…” A bk client was hacked by the audience in 2 minutes. It was the most devastating take down I’ve ever seen of the attacks. Linus later said the “git” wasn’t Tridgell at all, but in fact Linus himself. I think that was the only lca Linus missed for a few years either side.

qntmfred 1y ago

I think the git usage patterns we've developed and grown accustomed to are proving inadequate for AI-first development. Maybe under the hood it will still be git, but the DX needs a huge revamp.

overboard2 1y ago
What do you mean?
- qntmfred 1y ago
  if I'm working in Cursor for example, ideally the entire chat history and the proposed changes after each prompt need to be stored. that doesn't fit cleanly into current git development patterns. I don't want to have to type commit messages any more. If I ever need to look at the change history, let AI generate a summary of the changes at that point. let me ask an LLM questions about a given set (or range) of changes if I need to. we need a more natural branching model. i don't want to have to create branches and switch between them and merge them. less typing, more speaking.
  - vhantz 1y ago
    You should ask a LLM to create a VCS that will let you not do all these things you don't want to do.

mrlonglong 1y ago

When are we moving to SHA256? Some code bases must be getting massive by now sfter 20 years,

waynecochran 1y ago
Are you worried about hash collisions from different objects? The probability of a collision of N distinct objects with SHA-1 is (N choose 2) * 1 / 2^161. For a trillion objects the probability is about 1.7 x 10^-25. I think we can safely write code without collisions until the sun goes super novae.
- deleted 1y ago
  [deleted]
- mrlonglong 1y ago
  It's not that I'm worried about, it's the fact malicious files can be crafted for a particular hash that could replace the original.

jordigh 1y ago

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be the UI, how there wasn’t even a git commit command in the beginning, but it still paints the whole thing in somewhat romantic tones, as if the blob-tree-commit-ref data structure were the perfect representation of data. One particular aspect that often gets left out of this creation myth, especially by the author of Github is that Mercurial had a prominent role. It was created by Olivia Mackall, another kernel hacker, at the same time as git, for the same purpose as git. Olivia offered Mercurial to Linus, but Linus didn’t look upon favour with it, and stuck to his guns. Unlike git, Mercurial had a UI at the very start. Its UI was very similar to Subversion, which at the time was the dominant VCS, so Mercurial always aimed for familiarity without sacrificing user flexibility. In the beginning, both VCSes had mind share, and even today, the mindshare of Mercurial lives on in hg itself as well as in worthy git successors such as jujutsu. And the git data structure isn’t the only thing that could have ever possibly worked. It falls apart for large files. There are workaround and things you can patch on top, but there are also completely different data structures that would be appropriate for larger bits of data. Git isn’t just plain wonderful, and in my view, it’s not inevitable either. I still look forward to a world beyond git, whether jujutsu or whatever else may come.

brandonmenc 1y ago
I was always under the impression Monotone - which was released two years before Mercurial - was the inspiration for git, and that this was pretty well known.
- jordigh 1y ago
  Yes, Monotone partly inspired both. You can see that both hash contents. But both git and hg were intended to replace Bitkeeper. Mercurial is even named after Larry McVoy, who changed his mind. He was, you know, mercurial in his moods.
- 1y ago

js2 1y ago

> I started using Git for something you might not imagine it was intended for, only a few months after it’s first commit I started using git around 2007 or so because that company I worked for at the time used ClearCase, without a doubt the most painful version manager I have ever used (especially running it from a Linux workstation). So I wrote a few scripts that would let me mirror a directory into a git repo, do all my committing in git, then replay those commits back to ClearCase. I can't recall how Git came to me attention in the first place, but by late 2008 I was contributing patches to Git itself. Junio was a kind but exacting maintainer, and I learned a lot about contributing to open source from his stewardship. I even attended one of the early GitTogethers. As far as I can recall, I've never really struggled with git. I think that's because I like to dissect how things work, and under the covers git is quite simple. So I never had too much trouble with its terribly baroque CLI. At my next job, I was at a startup that was building upon a fork of Chromium. At the time, Chromium was using subversion. But at this startup, we were using git, and I was responsible for keeping our git mirror up-to-date. I also had the terrible tedious job of rebasing our fork with Chromium's upstream changes. But boy did I get good at resolving merge conflicts. Git may be the CLI I've used most consistently for nearly two decades. I'm disappointed that GitHub became the main code-review tool for Git, but I'll never be disappointed that Git beat out Mercurial, which I always found overly ridged and was never able to adapt it to my workflow.

nocman 1y ago
> I started using git around 2007 or so because that company I worked for at the time used ClearCase, without a doubt the most painful version manager I have ever used Ah, ClearCase! The biggest pain was in your wallet! I saw the prices my company paid per-seat for that privilege -- yikes!
- TorKlingberg 1y ago
  I meant to write a blog post titled "What's good about ClearCase" in 2014, and I wish I did because now I've forgotten most of it. ClearCase is a terrible version control system I wouldn't wish on my worst enemy, but it did have some good points that git still doesn't have. Large binary file support, configuration records, winkin, views. With various big companies going towards giant monorepos and the local git repo just being a view into the super-centralized repo, I think they will re-invent parts of ClearCase.

talles 1y ago

Why did git 'won' over mercurial? Because Github was better than Bitbucket? Or maybe because of the influence of kernel devs?

TiredOfLife 1y ago
For me it won (10+ years ago) because for some reason git (a deeply linux oriented software) had better Windows support than Mercurial (that boasted about Windows support). You could even add files with names in various writing systems to git. I am not sure that Mercurial can do that even now.
- cjbillington 1y ago
  Huh, that's not my recollection. Mercurial on windows was "download tortoisehg, use it", whereas git didn't have a good GUI and was full of footguns about line endings and case-insensitivity of branch names and the like. Nowadays I use sublime merge on Windows and Linux alike and it's fine. Which solves the GUI issue, though the line ending issue is the same as it's always been (it's fine if you remember to just set it to "don't change line endings" globally but you have to remember to do that), and I'm not sure about case insensitivity of branch names. Pretty sure Mercurial handles arbitrary filenames as UTF-8 encoded bytestrings, whether there was a problem with this in the past I can't recall, but would be very surprised if there was now. Edit: does seem there at least used to be issues around this: https://stackoverflow.com/questions/7256708/mercurial-problem-with-non-ascii-letters-in-filenames-between-windows-and-linux https://stackoverflow.com/questions/7256708/mercurial-proble... though google does show at least some results for similar issues with git
  - cpeterso 1y ago
    When evaluating successors to CVS back in 2007, Mozilla chose Mercurial because it had better Windows support than git. 18 years later, Mozilla is now migrating from Mercurial to git.
    - binarno_sp 1y ago

yapyap 1y ago

> 20 years ago > 2005 wow.

7e 1y ago

Git, still a ripoff of BitKeeper. All innovation begins as closed source.

masfoobar 1y ago
> All innovation begins as closed source I think you need to check your history. In the early days, before closed/proprietary software, source code was often shared between programmers. Lets look at text editors. They did not begin "closed source" - but companies have a team of people to help SELL their products, even if they are inferior to whats already out there. Baically, once computers matured was an opportunity to make a buck. Companies started selling their products for a fee. I would not be surprised if the source code was included before someone realised people can just pay for the executable. More money can be made by excluding the source code so new updates can also be for a fee. (Lets not talk about "End user Licence Agreements" in this post, OK) The "dominance" of closed source is really about companies with money controlling the status quo, with lawyers and sales teams knowing how to push it in favour. Companies like Micro$oft today have soo much money they dictate the direction our computers systems are going. They push it in a direction that favours them. They have a hand controlling the flow, like other big companies having a hand trying to change to stream for their intent and purposes. This is why -- whether you love him or hate him, I have much respects for people like Richard Stallman or others like Linus Torvalds.. to name a few! You want to talk about "innovation" ?? What do you think these "Closed source innovations" are build with? Software is created using a Programming language such as Python, C++, C, Javascript, etc... the VAST MAJORITY being free to use, under some sort of Open Source community! Lets also look at large companies in general.. many of which are not innovating... they are just purchasing smaller companies that are trying to do new things... closed source software or not. Lastly, lets also be honest that innovation is not created out of thin air -- everything is inspired by something previously.. whether a failed experiment or something already successful. New ideas come about with more failures.. but comes further ideas until, eventually, we have something successful! Linux may be inspired by other Operating Systems, and those were inspired by other things, etc. Innovation is progressive. Point I am making, if any company found ANY opportunity to build a closed-source version to shut down a popular Open Source equiverlant... THEY WOULD DO IT!

forgetmunch 1y ago

[flagged]

forgetmunch 1y ago

[flagged]

neves 1y ago

20 years! Which recent Git features do you find useful? I think I've never used any feature less than 10 years old. I'm probably missing something

ralgozino 1y ago
I don't know if this is a recent addition, but I started recently to use it: `git worktree` is awesome. It let's you have more than one copy of the repository at different points without doing the stash dance.
- kruador 1y ago
  This is, in some ways, reintroducing something that other source control systems forced on you (and you can see it in one of the videos that Scott linked, about using BitKeeper - Ep.4 Bits and Booze, https://www.youtube.com/watch?v=MPFgOnACULU https://www.youtube.com/watch?v=MPFgOnACULU). The previous tools I used (SourceGear Vault, MS Team Foundation Services) required you to have a separate working tree for each branch - the two were directly tied together. That's sometimes useful if you need to have the two versions running concurrently, but for short-lived topic branches or, as you say, working on multiple topics at the same time, it can be very inconvenient. Initially it was jarring to not get a different working directory for each branch, but I soon got used to it. Working in the same directory for multiple branches means that untracked files stay around - can be helpful for things like IDE workspace configuration, which is specific to me and the project, but not the branch. You can of course have multiple clones of the repository - even clones of clones - but pushing/pulling branches from one to another is a lot more work than just checking out a branch in a different worktree. My general working practice now is to keep release versions in their own worktree, and using the default worktree (where the .git directory lives) for development on the main branch. That means I don't need to keep resyncing up my external dependencies (node_modules, for example) when switching between working on different releases. But I can see a good overview of my branches, and everything on the remote, from any worktree.

jwrallie 1y ago

Sometimes I ask myself if Torvald's greater contribution to society wouldn't be Git, instead of Linux.

globular-toast 1y ago

> patches and tarballs workflow is sort of the first distributed version control system - everyone has a local copy, the changes can be made locally, access to "merge" is whomever can push a new tarball to the server. Nitpick, but that's not a distributed workflow. It's distributed because anyone can run patch locally and serve the results themselves. There were well known alternative git branches back then, like the "mm" tree run by Andrew Morton. The distributed nature of git is one of the most confusing for people who have been raised on centralised systems. The fact that your "master" is different to my "master" is something people have difficulty with. I don't think it's a huge mental leap, but too many people just start using Gitlab etc. without anyone telling them.

zoobab 1y ago

Decentralized, but centralized.

pjmlp 1y ago

And me 10 years cloning git repos from scratch instead of bothering to learn a plethora of archaic commands only to fix a broken commit. https://xkcd.com/1597/ https://xkcd.com/1597/ And it isn't as if I haven't used RCS, SCCS, CVS, Clearcase, TFS, Subversion, Mercurial before having to deal with Git.