What comes after Git? | Hacker News Reader

What comes after Git?

twitter.com

70 pointsmariuz173 comments

Git will be replaced by something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. It will likely come as part of an integrated work environment (some collaborative cloud workflow thing) in order to bypass git's role as gatekeeper/rite of passage for developers.

That's more a case of UI rather than implementation, yeah?

What's stopping us from just using those words to describe operations with Git?

I mean, what Git is, is a data structure with a set of operations on it, and the design of that is pretty fundamental at this point. We'd need to see something more novel[1].

(Sidenote: Git almost seemed an obvious trajectory for version control given how problematic file-based approaches have been. I've used far too many version control systems, including "ancient" awful ones like Harvest[2], and it just felt inevitable that we'd one day rely on an "always-branching" model.)

[1]: I did think of something more novel: semantic version control (https://news.ycombinator.com/item?id=25537455)

[2]: https://en.wikipedia.org/wiki/CA_Harvest_Software_Change_Man...

UX matters. Databases aren’t just data structures and their operations. They do compete based on interaction patterns and metaphors. VC can do the same.

I don't know a single database that is identical to another in implementation and just has a different UI/UX for it. Every single database has something specific for it in terms of implementation.

(Unless I guess we're talking forks of MySQL.)

I don't know if maybe you have a good example...?

Git changed its implementation with time too.

Not really. Under the covers, it has always been an object database where the objects key is the hash of that object, and other than blob, tree, commit and signed tag they haven’t really changed since then.

The protocol has become a bit smarter, by allowing there to be additional options passed for different communications options, and there is a slow but steady progress of moving from sha1 to sha256 for the hash function, but that isn’t rolled out yet completely.

Different tools have been added over time but the internals are pretty much the same as they’ve always been.

>>UX matters.

Of that was the case then how come Git reigns supreme in spite of the lack of a polished UI/UX?

It isn't the only thing that matters.

Git won because it was created by Linus and Linux moved to it, and that brought it a huge amount of publicity. Then GitHub came along and cemented its place.

Why don't you create your own wrapper that replaces names you don't like with pretty names you like? You can as well promote it, get lots of stars on GitHub and ultimately create official Git wrapper for your kind of people. It doesn't seem too difficult. I think it could be a single shell file.

> What's stopping us from just using those words to describe operations with Git?

The huge existing body of documentation, tutorials, StackOverflow questions, etc. that use the confusing standard Git terminology.

lol no

I feel like not having a git for human consumption is a huge missed opportunity, and I do hope something like that will arrive soon-ish. People in software development seem to not realize at all just how abysmally awful git's UX really is. Explaining git to a non-developer person who just wants me to assist with a python issue always feels a lot like explaing thermodynamics to someone who just wants to boil a kettle of water; yeah, sure, not interested, I've just sent you the file by email, please have a look.

I feel like making collaboration less painful has been the greatest innovation driver in the last few decades, and has paid off absolutely enormously. Imagine where a git/Github for other disciplines could take us. Given software developers build such tools, and given software developers overwhelmingly know how neat git really is, it's actually kinda strange that there's still such a dearth of good solutions in this space.

I'm like that. My own way of working involves files in folders and old versions of anything are overwritten or deleted. If they still exist it indicate an unfinished job. I don't keep draft versions of letters and emails either.

I would love to collaborate but when I start looking into git the amount of stuff I don't fully understand keeps growing. I should want something in my work flow that I don't understand? If it stops working just like that, the way everything seems to, I'm suppose to fix something that I don't understand?

When trying to figure out how it worked I read discussions from truly experienced users who decades into the process apparently still had to learn now to unstuck themselves.

I'm not saying its bad at what it does. Its much worse, I have no idea what the point is. It seems tailored to manage top of the developer pyramid issues that I imagine to be hard enough to justify its existence.

In applications I've seen copies of data get modified in different places then merged back together again. Its a horror movie!

> I have no idea what the point is.

As a lone developer, it lets you easily snapshot the state of your code at appropriate points and then compare those to the current state to find out what you broke. Of course, you can also do this by making copies manually, but that gets complicated if the program consists of more than file.

The real benefit is when you have more than one developer working on the program. If you make some changes on your machine, and I make some changes on my machine, and when we're done we want a single unified version of the program (with both your changes and mine) in order to deploy it, what should that look like? If all we can see is that line 123 in some file is different in your version and my version, how do we know which version of that line we want?

Git keeps track of (in the form of a graph structure) the fact than your version 1 is a descendant of our original version, your version 2 descends from your version 1, my version 1 descends from the original version, and so on ... and when we merge our versions, we get a final version that descends both from your latest version and mine.

You could do all this bookkeeping manually and figure out what to diff against what, but git gives you tools to work with.

> Of course, you can also do this by making copies manually, but that gets complicated if the program consists of more than file.

...and manual copies don't offer you the great automations that git provides you for free, like being able to tell when exactly each line has been changed last time (so you can check the whole context of how and why that change was made) or perform a binary search of a revision that introduced a bug. Even when working alone, these tools are invaluable.

To me, this is mostly a solved problem for casual contributors using the web interface of GitHub (and I assume gitlab, Bitbucket, and others). If more "serious" contributions need to be made, learning the basics of how git works isn't that difficult - branching, commits, and merging are basically all that a novice user needs to understand, and they're pretty easy to explain concepts (even if it means you're telling White lies about how it works under the hood).

We don't expect the average person to understand the tools and workflow of a mechanical engineer working with SolidWorks PDM - we shouldn't expect the average person to understand git (which is basically the software equivalent). I've never disagreed with the arguments that git is confusing or difficult to learn for non-software-developets, but I've never really understood why that's a problem.

I like to think of Git in analogy with cars.

Everyday folks aren't expected to know how their car works, much less tinker with it. Not the enthusiasts, who will find a way to grok the full specs of cars and tinker even if you tell them not to.

Normal everyday folks should be content leaving the gory details to their mechanics. I'd wager it to be the same with Git, as an everyday tool of software engineers, rather than that of layperson. This is not gatekeeping; it's a fact that Git is not your usual point-and-click stuff and UIs that attempt to do so can only simplify it so much. Real enthusiasts can always learn how to use Git if they want to, there's no need to make it simpler or easier for the 'casuals'.

The fact that people even have trouble with self-descriptive software like Microsoft Word - which is probably, in terms of UI, one of the easiest, most accessible UIs ever with years of research and iteration - speaks to the fact that not everyone will 'get' Git, nor sho uld there be a need to please or try to reach to everyone with a software that has as many complicated features as it does for the multitude of engineering problems it tries to solve.

> Git will be replaced by something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others.

If that were actually the case, then the dominant programming language today would be COBOL, rather than anything we have now.

Given how much COBOL is still in production, I suppose it depends entirely on your definition of "dominant" ?

Given that if you are starting a new project now, you'd almost never even consider using Cobol, that would be a very weird definition of 'dominant'..

To me, dominant is defined by lines of code currently in production.

The difference between my example vs. what you defined, is that hype and/or popularity determine what people use for _new_ projects. But that doesn't really assess how dominant a language has been in the past (or even in production currently).

Java is another dominant language that you might not use for a new project. Same with C.

> To me, dominant is defined by lines of code currently in production.

That definition biases towards verbose languages with lots of headers and boilerplate code (e.g. C++, Java)

> Java is another dominant language that you might not use for a new project. Same with C

I would very much consider using Java for a new project, same with C(1) if the project is in "real time" (I think that C++ hides too much things under the rug which can create latency issue).

1: Zig isn't ready yet to be a replacement

Those are the usecases that Git already handles. Each and every single one of them. Somehow you conspicuously left branching out of it, which is the main value added by any version control system along with merging. Thus I really don't see the point of arguing that Git will be replaced by a tool that does exactly what Git has been doing by design since it was released.

I think what will kill git is integration with language servers and IDE's. The reason is git and everything before it doesn't capture high level change/refactoring information.

You really want to record, mapped X to Y. Not 500 files changed in 4218 places.

Darcs supports “replace” semantics where you can rename a variable say across the whole project with just as you suggest, a single meaningful commit.

That's interesting I'll check that out.

Hasn't there been many attempts of that sort over the years? I recall some similar efforts being made to simplify Git for use with writers, etc.

I think git is here to stay for a long time. However, I wonder if there's space for a command line git wrapper makes it much harder to shoot yourselves in the foot via scenarios documented at: https://ohshitgit.com/

I imagine this could be achieved by using more intuitive nouns for subcommands (reflog, rebase) and giving informative warning messages on the command line when you are about to screw something up irrevocably.

Eventually, one would hope that some of the more effective features of such a wrapper can find their way back to the git project itself.

git has a steep learning curve for sure, but eventually scenarios described at oshitgit should be common knowledge for anyone using it.

personally i think putting out sites like that is more helpfull than dumbing down git

git pull rebase should be a top level command for example. Now you don’t get extraneous merge commits if you pull after making a local commit. I have it as an alias for git pull.

You can make that the default `pull` behavior in your Git config:

    git config --global pull.rebase true

You should also enable `rerere`[0]:

    git config --global rerere.enabled true

[0] https://git-scm.com/docs/git-rerere

Personally, I think that git pull should not be a command that one can run in normal situations. The common expectation when one is making changes, is to commit and then push. So why shouldn't the same apply when getting changes from the remote. That is, fetch and then apply to the local work tree.

I'm not sure what I'd gain from that. I'm not going to undo my colleagues work so I can put mine in instead

But you need to figure out how to integrate your collegue's work into your own working tree. Automatically merging the changes isn't what should be done in all cases.

This is the way it works in Mercurial, where pull doesn't automatically merge or rebase. You might want to look at your colleagues' work without disturbing your uncommitted changes or merging your commits right at that very moment.

Well, if I want to look at my colleagues' work without disturbing my uncommitted changes or merging my commits right at that very moment, I use `git fetch`.

Right, as do I. And "git fetch", as u801e was saying further up the thread, is perhaps what most people should actually prefer most of the time. Mercurial only has this pure fetch operation (although it calls it pull) and no combined fetch-and-merge operation.

There is no reason fetching and merging have to be connected, so perhaps the most prominent command (as a counterpart to "push") shouldn't be this combined operation.

OTOH, I use `git fetch` very rarely, since it's super rare to have unpushed or uncommited changes on the branch where I want to pull others' work from - so, in practice, I usually use `git pull`. The workflow is usually like this:

1. Work on my branch. 2. Checkout to master (with `git stash` if needed) 3. `git pull` 4. Do whatever I wanted to do with the updated branch (switch back and rebase, or test something, or start a new branch etc.)

In a code-reviewed, merge request-oriented workflow there's little point in splitting `git pull` into separate commands.

On occasion, others will force push their feature branch that's associated with a merge/pull request. In that case, running git fetch origin and git reset --hard origin/branch-name to get your local tracking branch in the same state as the remote is the appropriate thing to do.

Indeed, I forgot that I have `git fetch` also disguised under my `git mr` alias :)

I am with you on this one. Pull existing by default is one of the numerous aberration of git. It is just an alias for fetch/merge or fetch/rebase anyway. It doesn't even work the same way for everyone as you can configure what it does.

It's up there with stashes (which actually are just temporary commits ahead of the head anyway) and staging as things which shouldn't be there by default.

Git really likes making things complicated for newcomers.

Anyone who's ever used Darcs [1] knows that you can do a lot better than Git! So does anyone who's ever used Mercurial, for that matter.

Darcs failed to reach mass adoption, and lost against Git back in the mid-2000s, which for me, at the time, felt like a big step backwards (and in other ways a step forward, since Darcs had some icky bugs and performance issues). Some 15 years later it's amazing that we are still stuck with Git.

What makes Darcs different is that it does not need to organize history sequentially. It knows what commits depend on other commits, and a branch is simply a "sea of patches" whose order is inferred. This means that you can share commits across branches without conflicts (unless the branches actually conflict, of course). Darcs' equivalent to "git cherry-pick" simply pulls along with it any commits that your cherry-pick depend on.

Darcs had flaws that prevented it from succeeding, and the fact that it was written in Haskell didn't help attracting developers. Darcs' philosophy lives on in Pijul, which also looks promising, but unfortunately seems doomed to the same fate of remaining a niche tool. Git ate the world thanks to GitHub, and the next VCS needs a similar kind of killer app that justifies the switch.

[1] https://en.wikipedia.org/wiki/Darcs

Hear, hear, except that Darcs' philosophy lives on in Darcs, thanks to Ben Franksen particularly, and I don't think the world needs anything else like Github. An "experimental" implementation of the Darcs 3 theory is in the current release https://hub.darcs.net/darcs/darcs-2.16/browse/CHANGELOG

Interesting! I just assumed Darcs development had stopped. Where can I read about this new Darcs 3 theory?

I think the next VCS needs to offer a value proposition other than just "better than Git", though. The easiest way to accomplish this would be to piggyback on something popular.

For example, if Microsoft started offering a new VCS system built into Visual Studio Code that were enabled for free by default and had awesome built-in integration (VSCode's current VCS integration is nearly useless, IMHO), then I think it could reasonably compete with Git, though it might require competing with Github. (Of course, Microsoft could do this with Github.)

Even with this, I don't think a better Darcs would suffice. For example, one thing that Git handles poorly is large files, and it doesn't do well with large repos, either. I think we'd need something like Darcs paired with awesome scalability (Perforce-style central server with partial client-side checkouts) combined with support for arbitrarily large files.

> For example, one thing that Git handles poorly is large files, and it doesn't do well with large repos, either.

To be fair though, it's a source tracker which are usually small-ish text files. It's not really meant to be a Digital Asset Manager, say.

Git can do a shallow clone as well for very large repos. Much of that deep information becomes probably useless over time, unless you're doing code archaeology.

Well, the thread is about what comes after Git. If you ask me how Git could be improved, then what it's "meant" for doesn't matter if there are unsolved use cases.

Also, there's no particular reason Git couldn't be modified to work well with large files.

> Git couldn't be modified to work well with large files.

Apologies for the late response. Yes. I absolutely agree with that. The trick though is that when changes happen to a large file, what's the best way to do a diff? What if it's bzip2 or encrypted?

The other issue is that stagnant large files in your history need to be pruned. I'm not sure how to do that in git right now other than rewrite history.

Pijul is the spiritual successor to darcs I think.

> What makes Darcs different is that it does not need to organize history sequentially. It knows what commits depend on other commits, and a branch is simply a "sea of patches" whose order is inferred. This means that you can share commits across branches without conflicts (unless the branches actually conflict, of course).

Is that property relevant, though? I mean, although it does not need commits to be sequential, well... They already are, and there is no way around that. And sharing commits across branches, whether it's in the form of cherry-picked commits or pure old diff/patch workflows, is something that Git already handles.

Additionally, is there any workflow that does require any of those properties/features?

Meanwhile, how about Darcs' computational cost?

It's absolutely relevant. Git needs the "rebase" command to stitch independent histories together; Darcs doesn't.

With Darcs, all merging can be thought of as rebasing, except histories remain compatible and mergeable. With Git, on the other hand, rebasing the same commits multiple times result in the same conflicts that need to be fixed every time, which is why "rerere" exists. Darcs does not need "rebase" or "rerere" or any of the other tools for complicated history surgery.

As for workflows that "require any of those properties": There's wide agreement that Git is overly complex (exhibit A: hundreds of HN posts about learning to use Git) and is especially daunting for beginners, compared to easier tools like Subversion and Mercurial that provide nicer UIs. Darcs brings modern version control to users without incurring the complexities of Git.

It's not perfect — it had/has corner cases where merging became computationally expensive, though I hear there are new developments to fix this — which is why I said the future isn't Darcs.

> It's absolutely relevant. Git needs the "rebase" command to stitch independent histories together; Darcs doesn't.

That's the part I don't get from your argument. Git has rebase. It works. So where exactly do you see the value added by Darcs? I mean, it's not as if users can only merge or rebase if they use Darcs, right?

> As for workflows that "require any of those properties": There's wide agreement that Git is overly complex (...)

No, there isn't. In fact, that statement is patently false. git is the simplest and most straight-forward version control system I ever used. Things just work out of the box, they work well, and they work exceptionally fast. Branching is free, merging is free, tagging is free, it's trivial to checkout, it's trivial to setup a shared remote repository, and it's even trivial to setup a remote repo on a USB pen. You don't need to install servers to get it to work locally or remotely, you don't need to bother with extensions to get basic functionality working, and you don't need to use absurd ad-hoc patterns to get basic features such as branching.

So is there actually any objective point that can be made in favour of Darcs? I mean, being fast and usable surely is not it. So, what real-world value does Darcs offer?

Rebasing rewrites history, and Git's strict linear histories mean you can no longer push or easily resolve conflicting histories (see: "git rerere") that have diverged.

With Darcs, you can. You can merge/cherry-pick any history without incurring other conflicts than "real" conflicts where people have worked on the same lines of text. This eliminates a large group of commands Git has to provide ("rebase", "cherry-pick", "rerere", "reset", etc.) because the entire problem space doesn't even exist. Darcs is utterly magical that way.

> No, there isn't.

I have to disagree there. There's a huge corpus of material showing that people struggle with Git.

For example, a cursory search of HN shows many, many threads that devolve into discussions about how unnecessarily complicated and complex Git is. You can also go on Stack Overflow or other forums and look at all the users whose repositories are stuck in a state they don't understand. I suspect no other VCS has forced so many users to give up and wipe their local repo to start over again. Git's UI has gotten better over the years since I started using it around 2007, but it's not great at explaining repository state.

Many less-than-technical people — such as designers — have been forced into using Git as part of their work. Subversion was extremely popular in this group, and the transition to Git was slow precisely because Subversion offered simplicity where Git didn't.

Anecdotally, I work with a bunch of highly competent, highly technical colleagues — some of whom I consider to be better developers than myself — who still sometimes struggle working with Git. Most developers don't want, I think, to be "Git experts"; they just want to get stuff done. Most users, myself included, arguably use just a tiny subset of Git commands that deal with the daily pull/push/commit workflow. When I joined my current company, people weren't even practicing clean histories, but using "git merge". But once you get into rebasing (which many people do not do) and diverging histories across multiple levels of branches, you open a whole can of worms that Git is not good at dealing with. Rerere, while a huge time-saver, doesn't solve everything in such complicated scenarios.

Perhaps you're perfectly fine with all of this, but in that case you are not representative of the average user, in my opinion.

> git is the simplest and most straight-forward version control system I ever used

Since I started out, I've used RCS, Visual SourceSafe, CVS, Subversion, Perforce, GNU Arch, Darcs, and Mercurial. The only tool more complex than Git was GNU Arch (though, admittedly, required jumping through some ridiculous hoops to work around its lack of native branching support), but Git is without question the most complicated and complex that has been in mainstream use.

> So does anyone who's ever used Mercurial, for that matter.

So I've used mercurial and git in production. The one thing that turned me off on mercurial was that branching information was stored as part of the commit. This led sometimes to weird conflicts where the branch list needed to be merged. Granted that's been several years ago, so it might be different now, I don't know, and with git I have no need to.

I definitely appreciate branching data being meta data outside of the branch.

Also Darcs had severe issues maybe a decade ago where merging would appear to cause infinite locking. It wasn't a coding bug, it was due to their originally flawed theory of patches. So while it may be awesome, the world has definitely moved on.

It's worth reading this from pijul:

> Did you solve the “exponential merge problem” darcs has?

> Yes, we solved the exponential merge problem. The only caveat is that Pijul does not (yet) have an equivalent of darcs replace. In other words, Pijul works in polynomial time for all patches that systems other than darcs know of. We’ve not yet thought all the theory of this through, but it might be added in the future.

So good, but polynomial time can still be large beasts computationally.

Well, the actual complexity of apply and unrecord is O(p c log h), where p is the size of the patch, c the size of the largest conflict in which p is involved, and h is the size of history. That makes Pijul perfectly usable, even on large repositories.

I was worried it was larger than n^2. Thanks for clarifying.

I have no opinion on the merits of Git-style branches vs. Mercurial-style branches (mostly because I haven't really used the latter, either), but Mercurial has supported Git-style branching (termed "bookmarks") for quite some time now, too.

Other than that, I like not having to deal with the additional complication of Git's staging area in Mercurial (anything I personally did with the staging area I can replicate much better with Mercurial interactive commit feature), plus Mercurial's evolve extension, which turns commit amending, rebasing and all other kinds of history editing into non-destructive operations.

A paradigm shift, perhaps. Possibly, a notion of "changeset" which is more coherent with the actual code changes. For example, Unison language (https://www.unisonweb.org/) is a good candidate.

I would also like to have the following workflow (in functional language like Haskell, in more imperative language it would be trickier):

Before I start working on a code change, I mark the functions and types that are to be modified. A tool then calculates a "change boundary", a set of function calls that potentially have a different semantics in the new code. After I am happy with the boundary, I will start working on a replacement code inside the boundary.

The old code will still be available alongside to run and inspect during the whole development process. An automatic test suite generator will run the tests on the old code and by observing the boundary, it will automatically create a regression test suite for the replacement code.

Once I am done with the new code, and it is tested, I will let the tool replace it in the defined boundary as a new change.

So I will have a guarantee (through types) that I am only changing things that have to be changed, nothing else.

Git submodules just don't seem to work in practice, and that could be a big chance for a competing scm to overtake git. Having dependency management inline with scm would allow for more simplicity in the overall process.

This is also my biggest issue with Git. And integrated/streamlined support for large files.

what would be a typical large file you want to have in your codebase? usually this shouldn't be a consideration

I recently had to deal with a PowerPoint document which is slightly larger than 50 megabytes, which in todays terms, isn't very much. Before, I had kept it in SVN and that has no issues storing larger files. It is a bit shocking that Git has issues with not so tiny files.

I want to use it for files not just source code. For instance including graphics, the pdfs generated by latex or just anything. Or storing lots of directories. Currently, I use dropbox for that, but if git could do that...

though i agree that there isn't a proper vcs out there for large files (adobe bridge was a nice attempt) git wasn't designed for that and one might wonder whether you want git to be _that_ multi purpose.

If you have a significant project, you want to store at least a reasonable amount of media with it. Images, documentation. Git doesn't necessarily have to be the best system for handling high-gigabyte sized binaries, but should at least deal gracefully, with small and medium sized binary files. I am also not sure, why not more effort was spent making Git support large files even well.

By the way, if you're storing large files under version control in Git it is often useful to use the "--depth=1" flag when cloning or pulling repositories. That way you only download the stuff you really need and leave the rest of the history on the server until you need it.

Git LFS can do that.

Git LFS is basically the CVS of binary file version control.

It is a pile of garbage, but it's better than nothing.

In addition to what others posted here, sometimes it is nice to put generated files under version control with the source code that generated them. For example, simulation results, deep learning models, graphs that you need to include in your LaTeX documents (which can be considered partly source code, partly generated content).

Also, deep learning training data often consists of large image files, and can also be considered "source code", and in any case it can be very useful to put these under version control.

And finally it can be useful to put external dependencies as tar-files into your source tree.

I appreciate you laying this out because it's something I have struggled with and thought I just didn't know the right way to handle it.

For writing tests in a deep learning code base, rather than simply including a native data file (image, CSV, whatever), I've taken to writing a fake data creator class. It always feels like overkill when an alternative solution is including a native data file or two that already exists.

It doesn't matter actually. Tools should be easy to learn and as free of edge cases as possible. An example happening is constant propagation in Rust: it's the same feature, but with every release it can cover more of the code base.

Git LFS has been a thing for years.

Git LFS is not integrated well enough, imho. As I posted elsewhere, this software uses a separate network channel for transferring large files. You can't use it with git-daemon and git-shell, but you'll have to setup another server, configure access control etc. and your repository will be split into different parts of your file system.

Git LFS lacks a "host your own server" setup. That's a big downside. Hosting your own revision history should be simple.

I'm doing that with LFS on a gitlab droplet on digital ocean and its trivial (with like a hundred gb repo). Dunno if it was bad in the past but it's not hard now.

If you want a terrible time, have several members of your team not install git lfs, and have them be the main people that commit binary files.

LFS uses some sort of internal filtering and tracking to determine which binary files might have changed. It seems to have trouble deciding if there are actually dirty files that need changed. So you can't just say, "Okay, go find all the binary files that didn't actually get moved to LFS and correct them"

Instead you end up with random moments where you want to commit a single file and git instead detects 1000 png files that it absolutely could not go on without doing something about.

But then the diff is a disaster so good luck understanding that what it is actually mad about is that it wants to move the files into LFS. The only way I finally figured it out was to manually load the object blob and notice one of them was an LFS pointer file.

I personally think git annex handles things more elegantly, but lfs won that battle.

There’s literally built in functionality to “find all binary files that didn’t get moved to LFS and correct them”. You can do this with of without rewriting history.

Pretty sure I tried that before and it didn't catch them all.

This and also path based access (limiting access to certain directories/files within a branch).

been using submodules for years without any issues other than the routine before "deinit" was introduced was somewhat tricky.

could you elaborate?

I've been using git submodules for years but there are some real problems with them:

* Changing from a subdirectory to a submodule breaks lots of things like git reset and git bisect.

* Having to remember to git module init, update etc. I always have to look up the commands and never remember what the difference is.

* I don't care that there are unlisted files in a submodule, either don't bug me about this in status, or integrate commands in such a way that they work transparently across the main module and submodule.

* Related to the previous: Coordinating a single logical change across submodules involves several manual steps and has plenty of scope to go wrong.

Submodules are stupid easy, what issues do you have with them?

Once I accidentally added a sub-module to a repo. Had to jump through all kinds of hoops to fix that.

- An edit in .gitmodules

- An edit in .git/config

- A removal in .git/modules (seriously?)

https://stackoverflow.com/questions/1260748/how-do-i-remove-...

https://gist.github.com/myusuf3/7f645819ded92bda6677

Deinit didn't work?

And that's the only issue you had with them?

To be honest, I doubt better submodules are gonna help you overtake Git, there's too much inertia in this market. Take for example Mercurial which is a great tool and exists forever, yet it still lost its battle to Git.

I'd rather believe that submodules are fixed at some point or an alternative solution appears that works much better. Git subtree is around for a while and there's also Git X-Modules https://gitmodules.com which is modules on the Git server.

The more I learn about the underlying architecture of git and how it was developed and evolved, the more I see the Unix philosophy at work. As a result, I don't think git will ever be replaced, but merely evolve further according to the needs of developers (and others). In the near future, I think we're likely to see more specialized git frontends and additional collaborative functionality than another version control system.

Like PHP.

I think the Fossil system, built on SQLite and its powerful query system, is a superior architecture.

"Unix philosophy" has always been in the eye of the beholder. I think Perl showed the 1980s Unix philosophy of "small programs, working together", was often overly cumbersome.

Git still works great.

Why would it need to be replaced, just because it's 15 years old? I can think of a zillion things that are over 15 years and still very much working.

The plumbing is great. The porcelain would deserve a more consistent and easier to use implementation.

magit is grand. but editor specific.

I often just magit on a separate terminal and edit with some other IDE/editor.

You don't need to learn emacs beyond C-X 0 and C-X C-B really.

Productivity is higher than with manual git commands.

That's like saying that the Git CLI is specific to CLI users. It is, but anybody can use the CLI or open Emacs no matter what they use to edit the code. I personally started using Emacs for Org-mode, but I code in the Jetbrains IDEs.

Now the Jetbrains IDEs have a absolutely terrific Git integration, but if they didn't I could still open Emacs and use Magit.

> The porcelain would deserve a more consistent and easier to use implementation.

Many have taken a crack at it over the years, from very early on.

Issue's no porcelain will even replace the built-in one (and what improvements are added to the standard are generally flawed to hell, just look at how messy the brand new `git switch` already is, the git core team simply has no taste when it comes to CLI), and as the creator of a new high-level CLI by the time you'll have good enough feature coverage for it to be useful you'll know the plumbing so well the porcelain will make perfect sense. So you'll abandon the project as offering little value for the maintenance cost. And a few years later somebody else will come in and create their own, and repeat the cycle.

Git just works most of the time, and any issues that arise tend to have to do with the complexity of the codebase rather than git (e.g., rebasing a large feature-branch over dozens of commits).

Besides, auxiliary tools aside (I use git shell and a bunch of aliases), the git executable too is still improving. It will be a long time before anything that might replace it reaches both the maturity and the tipping point of having enough extra features to make it worthwhile to consider switching.

I agree, Git will be replaced when there’s a general limitation affecting many developers and something comes along that solves that. It won’t be replaced for the sheer sake of it or because we’re “bored” of it.

It’s also still actively developed so it’s not like some “stale” software we use because of inertia.

> Git still works great.

Of course, for people that know how to use it. I'd argue that the heavy use of Github combined with the adoption of advanced Git workflows is currently the biggest threat to open source. There's no such thing as "submitting a patch" these days. You're expected to be a master of a project's Github workflow to contribute. Most of us (myself included, with a few exceptions) just don't bother.

I dont understand this issue. I'd argue that github PR model has simplified "submitting a patch" to a tremendous degree.

Github and git are very different. Github is easyer to use, but doesn't cover all of git's use cases. So actually I'm all for reworking the base commands to support a workflow more similar to GitHub's, but still distributed.

Before Github, submitting a patch required reading some documentation in the project about how to submit patches, set up one's git config to properly generate the patches and email them. Then came the part of actually making the changes, generating the patches and running a git command to submit them.

With Github, one has to fork the project, run some commands to clone the repo from the fork, make the changes, push them, and then go back to the web interface to create the pull request.

It didn't even require that. You fixed something from the immediately-buildable tarball that you'd rebuilt and tested, or even something that didn't need a rebuild (config, doc, interpreted source), and sent the change, perhaps using M-x diff-backup. You didn't have pull 100Mb of git stuff, figure out how to rebuild the build framework, find you hadn't got the submodules, prat about with a pull request, and then whatever demands it makes of you, etc.

I was fine with that as a maintainer too, on three very active major projects at one time (using a 48Mb Pentium 1). A maintainer's job is partly to make it easy for contributors, not for the maintainer, but tending the contributors will help in the end.

> You fixed something from the immediately-buildable tarball that you'd rebuilt and tested

That entirely depends on whether the necessary libraries and headers are installed on the system you're using.

> even something that didn't need a rebuild (config, doc, interpreted source), and sent the change, perhaps using M-x diff-backup

Unless someone uses emacs and gnus or something similar, email clients could end up mangling the diff unless it was sent as an attachment (which would make reviewing the code and posting an inline response more difficult).

Both seems non perfect to me.

Having to set up one's git config or having to fork a repo seem to be accidental complexity is both cases.

To be fair, setting up one's git config is a one time step. But there is a bit of effort required to keep one's GitHub fork up to date relative to the repository it was forked from.

git fetch upstream ; git rebase -i upstream/master isn't that hard.

It depends on whether the histories have diverged and how many conflicts there are. A lot of people aren't very proficient with the use of git and will have problems (e.g., running git pull) and creating a merge commit in their branch or having conflicts they need to resolve.

The next time they open a PR using that branch, it will have commits that will clutter the branch.

Isn't this "knowing how to use it" come with the usual dose of RTFM and/or trying things?

Moreover, I suggest you fork the project and apply your own modifications instead of worrying about a GitHub project administrator to accept your changes

Don’t you just need to open a pull request? Or is there more ceremony that I’m missing?

What you says is true, it can be very difficult to submit ad-hoc patches to large projects. In my experience, however, this has been due to brittle, undocumented automated checks and newbie-hostile maintainers who have built a complex contribution process. I'm not convinced that a different version control system would change this. There are also many projects on GitHub that are very pleasant to work with.

It's the usual "controversial" Twitter post to boost one's account, I suggest not looking too much it and moving on

For me the question is less whether Git stopped working, but whether there is any progress being made beyond Git. As Git is around for 15 years now, it is a justified question, if there are any exciting new developments beyond Git.

I think Fossil adds things beyond Git, because it also supports "bug tracking, wiki, forum, and technotes." https://fossil-scm.org/home/doc/trunk/www/index.wiki

I think it's odd that so many people use a DVCS as part of a development system so dependent on a centralized server for everything else.

If you come from games you'll see where git fails miserably. Modern AAA games have terabytes of assets. p4 has handled this. git, has not. p4 also manages the fact that unlike source code you often can't merge certain assets so you need networked access controls (as in A can't edit this now because B is edit it).

Note I love git, but I don't know any big game studios using it. Some indies get by because their games are smaller but even then it can be a pain.

Does it have to be a goal for Git? Most of the development is not game development

But there's no good fundamental reason why it has to be that way.

The general point is: Git mostly works fine for what it is, but version control can 1) be easier to use, and 2) serve more purposes than Git currently does.

Imagine a perfect, seamless version control system that does everything you want with minimal effort. Git isn't that, not even if you've put in the time necessary to become an expert.

What about git-annex for the large asset files?

There seems a focus on new=improved in human thinking.

Often this is true, but fetishing change for its own sake becomes inefficient.

I think there is a good space around "version control for everyone else". I have been using overleaf for writing papers, which just does auto sync, and commits to a git repository in the background. It isn't perfect, but it is the best thing I know of for letting experts and beginners work together smoothly.

Mac OS has had a built-in file versioning system (separate from Time Machine) since Lion or so that works with any program that uses the standard document saving APIs. Most Mac users probably aren't aware that their computer stores potentially hundreds of previous versions of their documents (in evictable space, of course). The interface for it is kind of trash and isn't accessible in every app, though.

(Over the summer, I made a command-line [https://gitlab.com/jcfields/versions] and a GUI program [https://gitlab.com/jcfields/restore] for accessing this system outside of the standard UI, if anyone's interested, though the binaries are not notarized so the OS will show a scary warning the first time you use them.)

Granted, it's not exactly the same thing since you're not making commits at discrete and meaningful points like in a software version control system and since it works on an individual file level, which might not be ideal for every workflow, but it's still really useful when you realize you need to roll something back to an earlier state.

I think modern versions of Windows use the Volume Shadow Copy service to store backups of files at given snapshot points (such as when your computer runs a scheduled backup or creates a System Restore point), which can be pulled up in the file properties. I use to use NTBackup to do basically the same thing in a more crude way back in the Windows XP days. This isn't as nice as the Mac Versions feature since it requires setting up periodic backups, but it's something.

I'd be curious if any of the free desktops have come up with a simple and user-friendly solution to this. I feel like this is an area where there's a lot of room for improvement, since the majority of users would probably benefit from these systems but most aren't even aware they exist.

I work at a games studio, where artists/designers create and manage game assets via our game's source control. I personally dislike Git, but I absolutely think Git is a borderline-unacceptable choice for everyone that hasn't been hazed into the industry with it. The amount of "I accidentally lost all my animation files for ____ feature" is huge. I think most of the positive talk about git UX just waters down to "I know it already", which is evidenced by most of the responses to valid git UX criticisms being "You just don't understand." To me, version control should be as complex as a user wants it to be. Meaning, UX so obvious that you don't need docs or manuals or youtube videos to do the simplest of tasks if you don't want to. There should definitely be room for power users to be power users, but I think git absolutely fails at letting both novices and those that aren't interested in version-control-as-a-specialty be consistently productive and safe.

It's always been very curious to me that, for so many parts of dev, we re-invent the wheel a thousand times to try to find the "right" configuration, which ultimately leaves you with a very wide array of options for every one job, but for source control we seem to have just kind of shrugged and said "Git's fine."

What comes next, IMO, is semantic version control.

Version control that is aware of changes not at the file and line level, but at the function level, the module level, the library level, the language-specific construct level.

(Rich Hickey, creator of Clojure, played around with this idea, but I'm not sure where it went.)

Darcs should be able to support semantic patches, but currently the only alternative patch type is token replacement. How useful semantics might be in a project with N different components' semantics, I don't know.

There's a project that does diffs on Javascript at the AST level rather than the line level. I haven't tried it though and it is only for resolving conflicts.

He is referring to codeq: https://github.com/Datomic/codeq which has a last commit on 2014. But there have been recent rumours (https://medium.com/@sfyire/can-codeq-2-solve-clojures-weakne...) that Hickey is working in a new version of it. Fingers crossed!

I’d contend that we might have another 15 years to go before the general developer population have gotten so used to git that they are actually using it in an optimal way for their purpose.

Then we’ll find out what its real pain points are, and start working on something new to solve those.

What features should we be using in git that typical developers don't use?

I would guess some kind of answer involving complex branching schemes and/or "octopus merges", but I consider myself a fairly advanced git user and find those too hard to understand. I always stick to simple linear histories with occasional stable branches.

Git blame and git log per-file.

The commit messages could be the ultimate historical record of all the decisions and the "why"s.

Yet, on most projects, saying "I went to read the git log and found out the reason of x" instantly elevates you to a superhero status.

I guess we mix in different circles because all the developers here use git annotate and git log file|dir regularly. github even has buttons for both operations so you don't need to use the command line.

I would say that this command is much more useful than git blame:

  git log -p --follow <file>

IMO, rebase. I get so depressed everytime I see a merge commit, not to mention when a bisect ends up pointing to one. But it's very difficult to convince some developers it's a smoother workflow.

The state-of-the-art for backup is deduplicating software (Borg, Restic, Duplicacy). Gripes about Git's UI choices aside, Git was designed around human-readable text files and just doesn't do large binary files well. Sure, there's Git-LFS, but it sucks. The future of version control will: (1) Make use of deduplication to handle large binary files, (2) Natively supports remotes via cloud storage, (3) Doesn't keep state in the working directory so that projects can live in a Dropbox/OneDrive/iCloud folder without corrupting the repo, (4) is truly cross-platform with minimal POSIX dependencies.

I've been playing around with a proof-of-concept in Go based on the Restic chunker library: https://github.com/akbarnes/dupver

I'm watching Pijul, as it seems it has the potential to solve some merge problems, like using the same commit twice in two parents.

Sooner or later, we should stop using textual diff and switch over to higher level one/multiple, such as the AST-level diff (see what GrammaTech does, for example). This and integration of dependency management, is a must IMO.

I think the next SCM tool to Git, is what a Jetbrains IDE is to a text editor. It's an integrated environment on top of Git which deeply understands your code structure, dependencies, etc.

The file size limit of git is a bit annoying. I've moved to svn for a few projects that required large binaries to be shared and version controlled along with their source (for hardware design projects) and hit the 100Mbyte (IIRC) file limit. Im sure it could be fixed, but it is a limitation that has prevented me from using git in some cases

Git lfs is what you want.

The problem with this software is that it uses a different channel to transfer the large binaries.

If you're using git-shell or git-daemon to host your git repositories on a server, then you can't use that alone to also manage transfer/access of stuff that is managed through git lfs.

Broken on Windows.

Why isn't is integrated into Git out of the box? Why do I as a user have to be aware of a separate large file support? Why do I have to install and use a separate tool for this?

Everyone immediately says that when this topic comes up, but afaik it doesn’t even transfer or store files as deltas. Each time you change 2 bytes in a multiple GB file, you get to transfer and store an entire duplicate. IMO that is not a genuine solution to large files.

In fairness, that’s because gitlfs’s primary purpose is to store binaries where changes in the representation don’t actually map to anything useful. There definitely is a separate use case out there for storing large files where only deliberate changes are made to the objects.

Transferring only deltas is a performance optimization, not a question of semantics. Git-lfs needs to be able to perform binary diffs to save you from uploading 2 GB every time you touch a 2 GB file, not so that it can display useful diffs.

The tech to detect binary diffs has existed for a very long time as well. Since the previous revision is present on disk, there isn’t any good reason why they can’t at least delta compress the network transfer and validate hash on the other end.

But beyond that, what’s keeping the server from storing these deltas instead of full versions? Only argument I can think of is that server side corruption of a single file would break the chain of deltas and you’d lose every child.

But surely that can be solved using some sort of redundancy.

Put them in an artefact repository and pull them down at build time?

I agree; cvs, svn and git work ok and don't need that much change, what needs improvement is separation between code and media!

I'm making a simple .zip over HTTP solution for my MMO now.

It just has a naming scheme with dates and you send your last .zip date to the server and the server sends a list for you to download.

The good part with dates is that you can consolidate the data retroactively without breaking the system!

SVN?

A decade ago, something like that, a project I was on switched from SVN to Git. I don't know why, I don't know what problem was being solved.

"Git isn't that hard once you understand the internal model" one of the devs said.

I didn't need to understand the internal model of Subversion, we just checked stuff out and checked it back in. Within a month of adopting Git they had managed to lose a week's work. I guess they didn't understand the internal model. I kept my mouth shut.

For most corporate development teams, there is no problem that Git solves. Corporate development teams don't do distributed development. In a decade of using Git, I have never told another developer to connect to my local Git repo to get a piece of code. I would create a feature branch on the very non-distributed Github or GitLab server and they would go the single source of truth to get that piece of code. Like you would have done with Subversion. Only without the complexity.

In the Subversion days, non-technical people would use the same repo as technical people. Like tech pubs. With Git, they can't.

As I said, I have no idea what problem Git solves for the typical corporate software development organization. But I admit, it is complicated and hard to use, so in the end, as a developer I make more money. The more complicated it is to make software, the more money I make, and that's what's important.

Rock on, Git.

I have bet my startup on the future of git, as a decentralised store for personal data. My view is that git hasn’t peaked at all in terms of usage, and currently only serves the developer niche - while its future might be as a store of personal data for the general public. Sort of how computers were niche products compared to now when everyone has one in their pockets.

Git is distributed, not decentralized.

I'd like to see a git-like tool that works on the Abstract Syntax Tree rather than being basically a text tool. Of course such a tool might end up being very specific to a particular programming language, which would be not good.

Unlike CVS and Subversion, git is big enough that it won't just be replaced. What comes next needs to be incredible to even have a chance.

Personally, I think the next big VCS will have the ability to handle all files, including binary ones. (See https://gavinhoward.com/2020/07/decentralizing-the-internet-... .) As a bonus side effect, this would probably give that VCS the ability to handle source code by semantics.

I'd love to see something that allows for commutativity of non-conflicting commits. It's an artificial constraint that makes some obvious and trivial changes much harder than they should be.

I think Git will stay as long as we keep representing and working with code as plain text files. Of course I cannot think of a better way of working with code that is not via plain text files (otherwise I would be already rich) but somehow I doubt that programming in 2120 is going to be like programming today: manipulation of code as plain text (although we have to admit that programming has been "manipulation of plain text files" since its very beginnings).

Git is still good for tracking changes in plain text files.

I don't think the original stored program computers even had files, but I don't know when the first recognisable filesystem was. There have been a number of image-based systems which you can program directly, possibly by direct manipulation, even if you ultimately store the image as a (binary?) file.

I'm surprised Phabricator hasn't been mentioned. I haven't used it much, but it's rather huge in some circles.

Phabricator and git are almost oranges and apples.

Perhaps something that knows to deal with assets a bit better. Or maybe that could just be a new version of git. Also diffs could be more language aware. Maybe via a plug in system. Definitely some room for improvement.

Git-lfs?

Hg (or Perforce)?

But Git / BTRFS are Linux, Where Hg / ZFS are BSD. Something better could always come along, whether it gets significant adoption has very little to do with its technical capability.

Hg/Mercurial & Perforce both existed when Git was created, in fact perforce is part of why Git was created.

> perforce is part of why Git was created.

In what way?

Ah sheeit. I misremembered. The linux kernel used to use bitkeeper not perforce.

Mercurial and Git were both created around the same time in response to the same need for the Linux kernel to find a new vcs.

> Hg (or Perforce)?

They were there at the same time (or before) git, and they don't provide significantly more value than they did then.

While I do think they provide value beyond what git offers (my kingdom for revsets instead of the hell that is gitrevisions(7)!) the "market" rejected them then, it has little reason to switch now.

Well, what needs to be fixed? The way I see it:

- Built in better binary/large file support

- Need to be able to checkout subtrees and host monolithic repos (submodules are a pain)

- Better UI

Imagine Linus Torwalds 15 years ago sitting and thinking "so whats the next big new thing after svn?" Would be funny isnt it?

Git fanatics are addicted to the history log and the commit history. It’s not a 1:1 translation to create an accessible Git.

Let’s be honest, Git replaced Subversion for no reason other than fashion, and Git will be replaced for the same reason.

IMO what the open source community really needed is a google3 like CI system if only to give library/ecosystem projects like Gnome a greater appreciation of just how much havoc they've wreaked downstream and a better sense of usage patterns in general.

IMO the utter disaster that was gnome3/gtk3 transition is what killed what momentum there was for a mainstream Linux desktop.

don't fix what ain't broken?

i think as long as git keeps evolving and there are no major pitfalls for any programming language: why should it be replaced?

Because it is broken. Merges and rebases rarely work without manual intervention, a patch-oriented tool that is almost as fast as a snapshot-oriented tool, git. Something like Pijul looks promising.

It doesn't work because your changes conflict? How would anything else handle out of order modifications to files that cannot be resolved automatically? There will always been a requirement to do this manually - otherwise the VCS would be able to program for you (understand what is right/wrong).

Magit (Emacs)

Reply on news.ycombinator.com