2 ms·
I (with my background on the Mercurial crew back in the day) definitely think Git is ripe for disruption -- I've done some thinking on things you could do. (1)
by dochtman 9y ago
I (with my background on the Mercurial crew back in the day) definitely think Git is ripe for disruption -- I've done some thinking on things you could do.
(1) Good UX -- steal more from Mercurial here. No "index" or staging area by default, or at least a way to disable it. Being smoother about branch handling between local and remotes would also help significantly IMO.
(2) Network protocol and probably on-disk compatibility with Git and maybe Mercurial -- essential to gaining adoption.
(3) Better support for binary files, perhaps through using a modern content-defined chunking mechanism like FastCDC.
(4) Good support for narrow and shallow clones, maybe even making new clones (somewhat) shallow by default.
(5) Write it in Rust with a good modular architecture: good (including startup) performance, safe/robust and easier to reuse key parts (see also Facebook's Mercurial server stuff in Rust). The lack of a coherent/reusable architecture in Git has also been a key reason AFAICT that Git and Facebook are investing in Mercurial-based tooling.
(6) Use the inotify/FSEvents/whatever the windows equivalent is APIs to keep a daemon and have much faster status responses plus potentially record every change to the files on-disk -- sort of like Git's reflog, on steroids. Could also do smart build system integration here?
(7) Better support for very large trees (a la bup's midx extension to Git's storage format). It should really support Google/Facebook monorepo scale.
I have thought about starting something like this -- but I'm not sure this is the kind of thing where crowdfunding would afford me to build it out; and also not sure the big tech players would be willing to fund something like this (if they are, let me know though!).
- dilap 9y agoVery interesting list. I think the items that really have potential to address pain-points & be killer-features that motivate people to move beyond git will are (3) and (7) (big files and big trees). The rest are probably nice, but are more incremental improvements than something that's going to justify the huge leaving-the-standard-platform cost. Side note: Regarding good UX, I very much agree that git's command line is insane, and makes it unnecessarily hard for people to understand. However, I would disagree that the staging area is a bad idea! It's one of my favorite git features. I think it's just git's extremely confusing command-line terminology and shitty information display that it seem confusing. As a small piece of evidence in favor of this view, I'll say that I recently introduced a tech artist to git using the (extremely good!) GitUp app. He had no problem picking it up right away, including staging, committing, pushing, making branches & merging. I think this is because the excellent GitUp UI represents the concepts in such a nice visual way that they become very clear.