[HN Gopher] 20 years of Git
___________________________________________________________________
20 years of Git
Author : videlov
Score : 162 points
Date : 2025-04-07 16:37 UTC (6 hours ago)
(HTM) web link (blog.gitbutler.com)
(TXT) w3m dump (blog.gitbutler.com)
| alkh wrote:
| 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
| schacon wrote:
| 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 wrote:
| 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 wrote:
| I don't know if it's lucky or unlucky for you that you managed
| to skip Subversion
| jmclnx wrote:
| :)
|
| 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 wrote:
| 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/). 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... with equivalent OpenPGP
| https://gitlab.com/sequoia-pgp/sequoia/-/blob/main/openpgp-p...
| rwoerz wrote:
| 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 wrote:
| 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 wrote:
| You can probably setup smudge and clean filters in Git to do
| keyword expansion in a CVS-like way.
| WalterBright wrote:
| 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 wrote:
| Hey Walter, what would you improve with Git?
| WalterBright wrote:
| 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 wrote:
| git over ipfs then?
| swsieber wrote:
| While I get how that's like git, it sounds even closer to
| unison:
|
| https://softwaremill.com/trying-out-unison-part-1-code-as-ha...
| WalterBright wrote:
| 20 years later :-)
| WalterBright wrote:
| I had actually done a writeup on it, and thought I had lost it.
| I found it, dated 2/15/2002:
|
| ---
|
| Consider that any D app is completely specified by a list of
| .module files and the tools necessary to compile them. Assign a
| unique GUID to each unique .module file. Then, an app is
| specified by a list of .module GUIDs. Each app is also assigned
| a GUID.
|
| On the client's machine is stored a pool of already downloaded
| .module files. When a new app is downloaded, what is actually
| downloaded is just a GUID. The client sees if that GUID is an
| already built app in the pool, then he's done. If not, the
| client requests the manifest for the GUID, a manifest being a
| list of .module GUIDs. Each GUID in the manifest is checked
| against the client pool, any that are not found are downloaded
| and added to the pool.
|
| Once the client has all the .module files for the GUIDs that
| make up an app, they can all be compiled, linked, and the
| result cached in the pool.
|
| Thus, if an app is updated, only the changed .module files ever
| need to get downloaded. This can be taken a step further and a
| changed .module file can be represented as a diff from a
| previous .module.
|
| Since .module files are tokenized source, two source files that
| differ only in comments and whitespace will have identical
| .module files.
|
| There will be a master pool of .module files on WT's server.
| When an app is ready to release, it is "checked in" to the
| master pool by assigning GUIDs to its .module files. This
| master pool is what is consulted by the client when requesting
| .module files by GUID.
|
| The D "VM" compiler, linker, engine, etc., can also be
| identified by GUIDs. This way, if an app is developed with a
| particular combination of tools, it can specify the GUIDs for
| them in the manifest. Hence the client will automatically
| download "VM" updates to get the exact tools needed to
| duplicate the app exactly.
| endgame wrote:
| Sounds like it's also halfway to a version of Nix designed
| specifically for D toolchains, too, using GUIDs instead of
| hashing inputs.
| WalterBright wrote:
| It wasn't designed specifically for D toolchains, that was
| just an example of what it could do.
| pmarreck wrote:
| yeah, allow me to introduce you to the Nix whitepaper, which
| is essentially this, and thus worth a read for you:
|
| https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf
|
| Another possibly related idea is the language Unison:
|
| https://www.unison-lang.org/
| WalterBright wrote:
| Thank you. Looks like my idea precedes Nix by 2 years!
| pmarreck wrote:
| NixOS may end up being "the last OS I ever use"
| (especially now that gaming is viable on it):
|
| https://nixos.org/
|
| Check it out. The whitepaper's a fairly digestible read,
| too, and may get you excited about the whole concept
| (which is VERY different from how things are normally
| done, but ends up giving you _guarantees_ )
| XorNot wrote:
| The problem with NoxOS is all the effort to capture
| software closures is rendered moot by Linux namespaces,
| which are a more complete solution to the same problem.
|
| Of course we didn't have them when the white paper was
| written, so that's fair but technology has moved on.
| exe34 wrote:
| So you invented nix :-D
| frutiger wrote:
| Your description (including the detailed description in the
| reply) seems to be missing the crucial difference that git uses
| - the hash code of the object is not some GUID, it is literally
| the hash of the content of the object. This makes a big
| difference as you don't need some central registry that maps
| the GUID to the object.
| fragmede wrote:
| Every git repo has a copy of that mapping instead of there
| being a central registry though, and because the commit
| author's name and email, and the date of the commit and a
| commit message (among other things) go into the hash that
| represents a commit, it's not that big a difference, is it?
| Given a collection of files, but not the git repo they're
| from, and libgit, I can't say if those files match a git tag
| hash if I don't also have the metadata that makes up the
| commit to make the git hash, and not just the files inside of
| it.
| ajross wrote:
| Yes, but the commit object (which includes metadata)
| references a tree object by its hash. The tree object is a
| text representation of a directory tree, basically,
| referencing file blobs by hash. So yes, you can recognize
| identical files between commits. It's true there's no fast
| indexing: if you want to ask the question "which commits
| contain exactly this file?" you have to search every
| commit. But you don't need to delta the file contents
| itself.
| fragmede wrote:
| but people don't use the file hash, that's internal to
| git. I go to the centralized repository of repositories
| at github.com and look up tagged version 1.0.0 of
| whatever software, which refers to a git tag which
| references a commit hash (which yes it references a tree
| object as you said).
| XorNot wrote:
| That's for human consumption though, which is what
| frustrates so many "hashing will solve everything!"
| schemes - it breaks as soon as you need a bug fix.
|
| At the end of the day none of us want "exactly this hash"
| we want "latest". Exact hashes and other reproducibility
| are things which are useful when debugging or providing
| traceability - valuable but also not the human side of
| the equation.
| WalterBright wrote:
| There doesn't need to be a _single_ central repository, there
| can be many partial ones. But if they are merged, they won 't
| collide.
|
| The GUID can certainly be a hash.
| frutiger wrote:
| > The GUID can certainly be a hash.
|
| It can't be, because a GUID is supposed to be a globally
| unique. The point is, it needs to instead be the hash of
| the content.
|
| This can't be an afterthought.
| kbolino wrote:
| UUID versions 3 and 5 are derived from hashes (MD5 and
| SHA1 respectively).
| frutiger wrote:
| GUID and UUID are different.
| johnisgood wrote:
| How so? I thought they are the same.
|
| Tremulous had GUID / qkey.
|
| https://icculus.org/pipermail/quake3/2006-April/000951.ht
| ml
| cma wrote:
| Bitkeeper maybe somewhat of a precedent (2000)?
| pmarreck wrote:
| Isn't this basically... a Merkle Tree, the underlying storage
| architecture of things like git and Nix?
|
| https://en.wikipedia.org/wiki/Merkle_tree
|
| Except that instead of a GUID, it's just a hash of the binary
| data itself, which ends up being more useful because it is a
| natural key and doesn't require storing a separate mapping
| WalterBright wrote:
| I'd never heard of a Merkle Tree before, thanks for the
| reference.
| Zambyte wrote:
| 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 wrote:
| 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/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf...
| AceJohnny2 wrote:
| 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
| steveklabnik wrote:
| 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.
| bananapub wrote:
| ~I think it's more that not all existing git commands
| (rebase, am, cherry-pick?) preserve all headers.~
|
| ignore, misread the above
| steveklabnik wrote:
| That's a downside of using headers, not a reason for
| using them. If upstream git changes to help this, it
| would involve having those preserve the headers. (though
| cherry-pick has good arguments of preserving vs
| generating a new one)
| bananapub wrote:
| ah, I'm sorry, I misread your comment (and should have
| mentioned the cherry-pick thing anyway).
| steveklabnik wrote:
| It's all good!
| aseipp wrote:
| Mostly because it is jarring for users that want to
| interact with tools which require these footers -- and the
| setups to apply them, like Gerrit's change-id script -- are
| often annoying, for example supporting Windows users but
| without needing stuff like bash. Now, I wrote the prototype
| integration between Gerrit and Jujutsu (which is not
| mainline, but people use it) and it applies Change-Id
| trailers automatically to your commit messages, for any
| commits you send out. It's not the worst thing in the world
| and it is a little fiddly bit of code.
|
| But ignore all that: the actual _outcome_ we want is that
| it is just really nice to run 'jj gerrit send' and not
| think about anything else, and that you can pull changes
| back in (TBD) just as easily. I was not ever going to be
| happy with some solution that was like, "Do some weird git
| push to a special remote after you fix up all your commits
| or add some script to do it." That's what people do now,
| and it's not good enough. People hate that shit and rail at
| you about it. They will make a million reasons up why they
| hate it; it doesn't matter though. It should work out of
| the box and do what you expect. The current design does
| that now, and moving to use change-id headers will make
| that functionality more seamless for our users, easier to
| implement for us, and hopefully it will be useful to
| others, as well.
|
| In the grand scheme it's a small detail, I guess. But small
| details matter to us.
| AceJohnny2 wrote:
| Thanks for the explanation!
|
| While you're around, do you know why Jujutsu created its
| own change-id format (the reverse hex), rather than use
| hashes (like Git & Gerrit)?
| esafak wrote:
| How long did it take you to become proficient? I assume your
| organization uses git and you use jujitsu locally, as a layer
| on top?
| steveklabnik wrote:
| (not your parent)
|
| > How long did it take you to become proficient?
|
| As with anything, it varies: I've heard some folks say "a few
| hours" and I've had friends who have bounced off two or three
| times before it clicks.
|
| Personally, I did some reading about it, didn't really stick.
| One Saturday morning I woke up early and decided to give it a
| real try, and I was mostly good by the end of the day, swore
| of git entirely a week later.
|
| > I assume the organization uses git and you use jujitsu
| locally, as a layer on top?
|
| This is basically 100% of usage outside of Google, yeah. The
| git backend is the only open source one I'm aware of.
| Eventually that will change...
| renerick wrote:
| It's really not that long. Once you figure out that
|
| 1. jj operates on revisions. Changes to revisions are tracked
| automatically whenever you run jj CLI
|
| 2. revisions are mutable and created before starting working
| on a change (unlike immutable commits, created after you are
| done)
|
| 3. you are not working on a "working directory" that has to
| be "commited", you are just editing the latest revision
|
| everything just clicks and feels very natural and gets out of
| the way. Want to create a new revision, whether it's merge, a
| new branch, or even insert a revision between some other
| revisions? That's jj new. Want to move/reorder revisions?
| That's jj rebase. Want to squash or split revisions? That's
| jj squash and jj split respectively. A much more user-
| friendly conflict resolution workflow is a really nice bonus
| (although, given that jj does rebasing automatically, it's
| more of a requirement)
|
| One notably different workflow difference, is absence of
| branches in the git sense and getting used to mainly
| referring individual revisions, but after understanding
| things above, such workflow makes perfect sense.
| Zambyte wrote:
| I don't really remember exactly how long until I felt
| particularly comfortable with it. Probably on the order of
| days? I have never really used any other VCS besides vanilla
| git before, so I didn't really have any mental model of how
| different VCSs could be different. The whole working revision
| vs working branch + staging area was the biggest hurdle for
| me to overcome, and then it was off to the races.
|
| And yes, I use jj locally with remote git repos.
| lowboy wrote:
| Not parent, but for me it was a couple hours of reading (jj
| docs and steve's tutorial), another couple hours playing
| around with a test repo, then a couple weeks using it in
| place of git on actual projects where I was a bit slower.
| After that it's been all net positive.
|
| Been using it on top of git, collaborating with people via
| Github repos for ~11 mos now. I'm more efficient than I was
| in git, and it's a smoother experience. Every once and a
| while I'll hit something that I have to dig into, but the
| Discord is great for help. I don't ever want to go back to
| git.
|
| And yes, jj on top of git in colocated repos (https://jj-
| vcs.github.io/jj/v0.27.0/git-compatibility/#co-lo...).
|
| If you set explicit bookmark/branch names when pushing to git
| remotes, no one can tell you use jj.
| pmarreck wrote:
| Can second this. Beware that your old git habits may die hard
| though. (It's nice that it uses Git as its storage backend, for
| now, though)
| filmgirlcw wrote:
| jj is fantastic and I love it so much. Takes the best things I
| liked about hg but applies it to a version control system
| people actually use!
| esafak wrote:
| > 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!"
| palata wrote:
| > 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 wrote:
| 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.
| zwieback wrote:
| Of all the many source control systems I've used git has the
| worst usability yet it's my favorite
| esafak wrote:
| Why?
| jakub_g wrote:
| 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/documentat...
| schacon wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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-backdoo...
|
| see if you can spot the small edit that made this a backdoor:
|
| if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) retval
| = -EINVAL;
| qntmfred wrote:
| 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.
| mrlonglong wrote:
| When are we moving to SHA256? Some code bases must be getting
| massive by now sfter 20 years,
| waynecochran wrote:
| 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.
| jordigh wrote:
| 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 wrote:
| 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 wrote:
| 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.
| schacon wrote:
| This is all fairly speculative, but I didn't get the
| impression that Monotone was a main inspiration for Git. I
| think BitKeeper was, in that it was a tool that Linus
| actually liked using. Monotone had the content addressable
| system, which was clearly an inspiration, but that's the only
| thing I've seen Linus reference from Monotone. He tried using
| it and bailed because it was slow, but took the one idea that
| he found interesting and built a very different thing with
| that concept as one part of it is how I would interpret the
| history between these projects.
| forrestthewoods wrote:
| > I still look forward to a world beyond git
|
| I dream of the day. Git is a local minima. Version control
| could and should be so so so so much better than Git.
|
| In my 18 years of professional dev I've never actually used Git
| professionally. Git is for hobby side projects. Perforce and
| Sapling are for adult projects.
|
| And it's doubly tragic because Mercurial is much better than
| Git. It's VHS vs Betamax all over again. I eagerly anticipate
| the DVD and Blu-ray of version control.
| schacon wrote:
| I'm curious why you think hg had a prominent role in this. I
| mean, it did pop up at almost exactly the same time for exactly
| the same reasons (BK, kernel drama) but I don't see evidence of
| Matt's benchmarks or development affecting the Git design
| decisions at all.
|
| Here's one of the first threads where Matt (Olivia) introduces
| the project and benchmarks, but it seems like the list finds it
| unremarkable enough comparatively to not dig into it much:
|
| https://lore.kernel.org/git/Pine.LNX.4.58.0504251859550.1890...
|
| I agree that the UI is generally better and some decisions
| where arguably better (changeset evolution, which came much
| later, is pretty amazing) but I have a hard time agreeing that
| hg influenced Git in some fundamental way.
| jordigh wrote:
| Please don't do that. Don't deadname someone.
|
| I'm not saying that hg influenced git, but I'm saying that at
| the time, both were seen as worthy alternatives. Lots of big
| projects were using hg at one point: Python, Mozilla,
| Netbeans, Unity.
|
| Sure, you managed to get Github in front of everyone's face
| and therefore git. For a while, Bitbucket was a viable
| alternative to many.
|
| Were you involved with the decision to sponsor hg-git? I
| understand that at one point it was hoped that this would
| help move more people from hg into Github, just like
| Subversion support for Github would. I think the latter is
| still there.
| eternityforest wrote:
| I just wish they'd extend git to have better binary file diffs
| and moved file tracking.
|
| Remembering the real history matters, because preserving
| history is valuable by itself, but I'm also really glad that
| VCS is for most people completely solved, there's nothing
| besides Git you have to pay attention to, you learn it once and
| use it your whole career.
| johnisgood wrote:
| I am rooting for pijul.
| js2 wrote:
| > 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.
| talles wrote:
| Why did git 'won' over mercurial?
|
| Because Github was better than Bitbucket? Or maybe because of the
| influence of kernel devs?
| TiredOfLife wrote:
| 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.
| yapyap wrote:
| > 20 years ago
|
| > 2005
|
| wow.
___________________________________________________________________
(page generated 2025-04-07 23:00 UTC)