What will be the next to replace Git? Many say it might be related to AI, but no one can say for sure.
Now here is a sentence that would make me immediately stop reading the article. Thankfully it is at the end, since it was a great and interesting read.
But now I wonder, the article does mention that Git has some core design problems. Are there any new emerging VCSs that iterate on the idea and are better (or faster, or have an unique idea about how to handle stuff), or is version control basically a solved problem with Git?
It felt like the wild west for a while because there were so many open problems and each implementation seemed to be focusing on a subset of them. Git handles all of them with decent enough speed that there isn't much incentive to go against the grain.
I think Git is good enough and so ubiquitous that we won't see a competitor until coding itself drastically changes shape. Who knows what that will look like, but if it's not collections of relatively flat files then Git may someday be replaced.
On the other hand, git has major issues with binary content, such as when making games. I know there is Plastic, which has some cool features, especially in regards to merging, but when Unity bought it, it got stuck in unreasonable overpriced proprietary licensing hell. Is there some kind of FOSS VCS that solves similar issues?
Pijul: patch-based like Darcs but apparently solves its performance issues. In theory this improves conflict resolution.
Jujutsu: kind of an alternative front-end to a git repo (but not a front-end to git). Has some different ideas, like no staging area (draft commit), and some other stuff I can't remember.
Sapling: from Facebook. Unfortunately only part of it is available. The server is not public yet (I guess it's tired up in Facebook infrastructure too much).
And it's definitely not a solved problem. Aside from the obvious UX disaster, Git has some big issues:
Monorepo support is relatively poor, especially on Mac and Linux.
Submodule support is extremely buggy and has particularly bad UX even for Git.
Support for large files via LFS is tacked on and half-arsed.
Conflict resolution is very very dumb. I think there are third party efforts to improve this.
I think the biggest issue is dealing with very large code bases, like the code for a mid-large size company. You either go with a monorepo and deal with slowness, Windows-only optimisations and bare minimum partial checkout support.
Or you go with submodules and then you have even bigger problems. Honestly I'm not sure there's really an answer for this with Git currently.
It's not hard to imagine how this might work better. For instance if Git repos were relocatable, so trees were relative to some directory, then submodules could be added to a repo natively just by adding the commits and specifying the relative location. (Git subtree almost does this but again it's a tacked on third party solution which doesn't integrate well, like LFS.)
Aside from the obvious UX disaster, Git has some big issues:
I find this blend of claims amusing. I've been using Git for years on end, with Git LFS and rebase-heavy user flows, and for some odd reason I never managed to stumble upon these so-called "disasters". Odd.
What I do stumble upon are mild annoyances, such as having to deal with conflicts when reordering commits, or the occasional submodule hiccup because it was misused as a replacement for a package manager when it really shouldn't, but I would not call any of these "disasters". The only gripe I have with Git is the lack of a command to split a past commit into two consecutive commits (a reverse of a squash commit), specially when I accidentally bundled changes to multiple files that shouldn't have been bundled. It's nothing an interactive rebase doesn't solve, but it's multiple steps that could be one.
Can you point out what is the most disastrous disaster you can possibly conceive about Git? Just to have a clear idea where that hyperbole lies.
I used it for an afternoon or so, a few years back and didn't find it anything useful. It would generate a text file with my commit messages, like redirecting git log. Please take this as an over simplification, maybe there's more to it and I just couldn't get the gist..
Gave up after clicking on the next links starting at get started page. I was looking for any example which shows commands with corresponding results. Has anyone here had better luck and could please share a few?
That command will produce a list of (dynamic) libraries that are being used by that helper. It will look somewhat like this (this is copied from my Arch instalation):
I was going to say there are about a gazillion free Git tutorials so this seems like a strange thing to charge quite a lot of money for. But it does look very well done.
I understand the "why would I pay for this" reaction. I think crowdsourcing is a better approach for these kinds of content. Once you reach certain level of financial commitment from the crowd, you can give away the PDF and sell the print copy.
That other people would care as much for a clean history like I do. Specifically, opening branches and leaving them open forever without merging them back into main, many useless commits rather than squashing or amending, or making branches-of-branches-of-branches. Drives me nuts
You get a cleaner history that removes noise from the run-of-the-mill commit auditing process. When you audit the history of a repo and you look into a feature branch, you do not care if in the middle of the work a developer merged with x or y branch. What you care about is what changes were made into mainline.
Instead of a commit history, you get a commit fairy tale, which is prettier than the truth, but probably less useful. You get something akin to merging the base branch into the feature branch but things look as if they were done in an order they weren't instead of getting an 'ugly' merge commit.
In many providers it’s possible to set up an automatic squash policy when merging to main. At our company the git history is just linear with well defined commits.
I don't think this is necessarily better. Some branches/projects are big enough that there are meaningful commits that should be made inside the project.
I guess it’s dependent on project, but IMO if a commit is important enough to be in the main branch, then that should have its own merge request. I like it when all commits in the main branch have gone through all the build pipelines and verification processes.
But if having separate MRs is undesirable, then you could always overrule the squash policy. I know it’s possible on Gitlab at least.
Commits should be reasonably small, logical, and atomic. MRs represent a larger body of work than a commit in many cases. My average number of (intentionally crafted) commits is like 3-5 in an MR. I do not want these commits squashed. If they should be squashed, I would have done so before making the MR.
People should actually just give a damn and craft a quality history for their MRs. It makes reviewing way easier, makes stuff like git blame and git bisect way more useful, makes it possible to actually make targeted revert commits if necessary, makes cherry picking a lot more useful, and so much more.
Merge squashing everything is just a shitty band-aid on poor commit hygiene. You just get a history of huge, inscrutable commits and actively make it harder for people to understand the history of the repo.
Well the MRs in the teams I’ve been working in have been small and mostly atomic. They’re focused on solving only one thing.
The team I’m currently working now in was bad at this before and often bundled way too many things in a single MR. It lead to overly long review processes and was error prone. It was too tough for the reviewer to get an understanding of what was going on.
Since we made the habit to make smaller MRs we have had much less of those issues.
That's excessively bureaucratic to the point of being useless in most cases.
Hard and fast rules are generally bad and "squash everything" is pretty much a by definition hard and fast rule with the result being "I'm just not going to care that much about my commit messages."
What are you on? Non-descriptive commit messages has never been any of our problems. All our commits that are pushed to the main branch are well written with clear issues linked to them.
Yeah I agree but in my experience developers seem to struggle with "keep important things in history; squash unimportant things". An open "merges allowed" policy leads to people unthinkingly merging branches with 50 "typo", "fix" commits for a 100 line change.
The key thing gerrit provides is relation chains. You can push to the server your local branch and it will make a “patch” (like a pull request) for each of the commits in your branch. The patches are automatically put into a relation chain which lets reviewers go through them in sequence. Also your CI can test them together.
The idea is you need to locally make your commits ready for master. This is where interactive rebase comes in. You’ll have a normal local working branch and when you’re ready for review you use interactive rebase to squash some commits together, redo the commit message on some, change the order, etc. Basically you clean up your working branch into a series of commits ready for main.
Being able to easily push a relation chain of reviews up makes it way easier to make commits that land on main that just do one thing.
The second part of the solution gerrit provides is patchsets. When you need to edit a patch to deal with review comments, you actually rewrite your local history using git commit —amend or interactive rebase and push to gerrit again. In gerrit this will make a new patchset of your patch that you can diff between, see comments on, etc. It works very well for dealing with review feedback and for reviewers to quickly rereview.
It achieves this magic through a change-id that is added via git hook to the commit message. Even if you rewrite your history and your commit id changes it will still consider the rewritten commit to be the same patch as long as the change-id stays the same.
It’s pretty hard to just explain it like this. Using the workflow for a bit makes it much easier to see the value it has.
Yeah I get what you're saying. Gitlab can pretty much do that too, you just need a branch & MR for each commit, and then you tell it to merge each branch into the previous one. It automatically rebases them when their dependency merges.
Definitely more tedious to set up than just pushing one branch though. Maybe I should make a tool for that... Does Gerrit test each patch in CI sequentially or just all of them together?
But in any case that wasn't really the problem I was talking about. What I'm saying is that whether or not you should squash a branch depends on what that branch is. Neither "always squash" not "never squash" are right. It depends. And developers seem to have a real problem with knowing when a change is important enough to warrant a commit.
Though I suppose if people have to actually review each commit they would get a lot more push-back to "fix fix fix" type commits so maybe you are right.
Does Gerrit require each individual commit to be approved or can you just approve the whole branch/changeset?
Yeah you’ve gotten the idea I was going for. The workflow of gerrit incentivises forming commits with single ideas. It’s not always squash or never squash, it’s squash when it makes sense to. You still have to stay on top of reviews to get devs to do it, but it’s so much easier that there’s no excuse.
For CI, it depends how you set it up but usually you would test each commit in the relation chain to ensure they’re cherry pickable, back portable. It also helps to push devs to make commits single well contained ideas. Patches higher up in the relation chain will build with the patches below it.
Often you’ll push a relation chain up, get reviews on all of them, get green from CI on all, and then merge them all together. Normally you would set it up to rebase the commits and ff merge them to main.
That it’s just like subversion but distributed. Both of those assumptions are wrong. It uses a lot of the same terminology as subversion, but most of the terms are conceptually different in sometimes major ways. It’s not really distributed unless you go out of your way to make it so. Most implementations use a single remote to sync back to on a regular basis. It is, however, really good about keeping changes in sequence locally until it can sync, something you can’t really do in subversion.
Git's internals are very easy to understand and once you know more about them, you'll have a much better idea of how it works (especially when it comes to tags and branches). They're so simple, you could even easily write your own scripts to parse git's internal data directory if you wanted to.
They're not that simple because of packfiles. But yeah loose files are very simple. Also the documentation for packfiles is pretty bad. You end up reading other people's random notes and the Git source code. (I actually have written a Git client from scratch.)
I don’t actually remember when I first learned Git. Maybe it was in a university lecture. I think my biggest struggles was learning how to resolve merge conflicts properly and efficient use of branching, but I never found any of the commands difficult to understand.
Git
Hot