A couple of years ago, I was modding a fresh install of Skyrim and thought, "I can use git branches to make it easy to switch between different mod combinations rather than uninstalling/reinstalling mods when something breaks or when I want to change things up." Worked well!
I had branches that were mostly vanilla with enhancements, and then branches that had all kinds of ridiculous mods. If I wanted to switch to playing a ridiculous build of Skyrim, I'd just close the game, checkout the branch I wanted, and start the game.
It's been a couple of years, but I don't recall it being particularly slow switching between branches. I had a pretty beefy rig to begin with, which probably helped.
I initially found git a bit confusing because I was familiar with mercurial first, where a "branch" is basically an attribute of a commit and every commit exists on exactly one branch. It got easier when I eventually realized that git branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space.
I initially found git a bit confusing because I was familiar with mercurial first, where a “branch” is basically an attribute of a commit and every commit exists on exactly one branch.
To be fair, Mercurial has some poor design choices which leads to a very different mental model of how things are expected to operate in Git. For starters, basic features such as stashing local changes were an afterthought that you had to install a plugin to serve as a stopgap solution.
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.
I wish all rules, Ts&Cs, contracts, etc came like this. It might make it less unfeasible to follow what's changed when something forces you to agree to the new version of the terms.
Fun story, in 2012 I got the idea of making a git based "cloud" save system with branching, to explore multiple story paths in games.
I implemented the FileSystemWatcher (the equivalent to Linux's inotify) component in C# on Windows, was able to detect when games were saved, and commit that to git, and stopped there.
Feel free to implement that, I'd love to save on implementation time 😇
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 think a common misconception is that there's a "right way to do git" - for example: "we must use Gitflow, that's the way to do it".
There are no strict rules for how you should use git, it's just a tool, with some guidelines what would probably work best in certain scenarios. And it's fine diverge from those guidelines, add or remove some extra steps depending on what kinda project or team-structure you're working in.
If you're new to Git, you probably shouldn't just lookup Gitflow, structure your branches like that, and stick strictly to it. It's gonna be a bit of trial-and-error and altering the flow to create a setup that works best
I think a common misconception is that there’s a “right way to do git” - for example: “we must use Gitflow, that’s the way to do it”.
I don't think this is a valid take. Conventions or standardizations are adopted voluntarily by each team, and they are certainly not a trait of a tool. Complaining about gitflow as if it's a trait of Git is like complaining that Java is hard because you need to use camelCase.
Also, there is nothing particularly complex or hard with gitflow. You branch out, and you merge.
Well to be clear, this was not supposed to be a jab at gitflow, or me complaining specifically about gitflow. I merely used "gitflow" as an example of a set of conventions and standardizations that comes nicely packaged as one big set of conventions.
But there's nothing wrong with gitflow. I was just saying - it are not set in stone rules you must follow religiously. If you're using it and it seems more practical to adapt the flow for your own use-case, don't worry it'd be considered wrong to not stick strictly to it
That given its popularity it would be more user friendly. Every good dev tool will have its internals or more advanced features. Git is no different. But it sure feels like it never took the idea of a polished user experience seriously. Which is fine. It’s a dev tool after all. But the UI conversation around git has been going on long enough (here included) that there has to have been a significant global productivity cost due to the lack of a better UI.
the UI conversation around git has been going on long enough (here included) that there has to have been a significant global productivity cost due to the lack of a better UI.
I don't think this is true.
Git is ugly and functional.
People love to complain about it being ugly, but it does what it's meant to. If there was actually a persistent productivity hit from its interface, one of the weird wrappers would have taken off, and replaced it.
But the truth is, those wrappers all seem to be written by people learning to use git in the first place, and just get abandoned once they get used to it.
I don't even think it's ugly. It just works and is intuitive if you bother to understand what you're doing.
I think some vocal critics are just expressing frustration they don't "get" a tool they never bothered to learn, particularly when it implements concepts they are completely unfamiliar with. At the first "why" they come across, they start to blame the tool.
there has to have been a significant global productivity cost due to the lack of a better UI.
I'm not so sure about this to be honest. If it were really that big of a problem, someone would have made an effort to resolve it. The fact that people still use it anyway suggests to me that it's a bit of an overblown issue.
If it were really that big of a problem, someone would have made an effort to resolve it. The fact that people still use it anyway suggests to me that it’s a bit of an overblown issue.
As I said in another reply ... how many GUIs and text editor plugins are there for git and how many use them?
What other CLI tool has as much work put into GUIs, wrappers and plugins that do not try to replace the underlying tool/CLI, even accounting for popularity?
Yea, I think they’re all different. Alternative shells are about more than polishing a UI, and in many ways so are distros. And text editors are basically platforms and have been for a while, though it is interesting to single out git as being more like something like vim compared to other CLIs (as you say, it’s different). But even so, it’s not nearly a platform like a test editor, most apps for it a UI wrappers that don’t alter its core utility/function, to my point.
I think the fundamental difference is that Git is a CLI tool. But that's not how or where people use and want to use it. So obviously various interfaces are being created. It's not alternative CLI that are created. It's UIs and GUI interfaces. For a lack of a [more-than-barebone] official one.
Shells remain CLI. Distros are also technically/technologically driven.
Maybe the better analogy is that with vim and nano, we see many text editors and IDEs with GUIs.
Maybe the better analogy is that with vim and nano, we see many text editors and IDEs with GUIs.
Interesting. I'm not so sure about the divide you draw between vim/nano and GUI IDEs. Historically vim and nano were basically the GUIs of their time. Preceding vim was ex and ed, which were basically CLI text editing tools build for the actually printed on paper typewriter interfaces computers like PDPs used to run. If you're not familiar, and you think vim can be obscure ... try running ed MYFILE! It's basically a sort of grep and sed REPL for editing text (where, interestingly, historically tools like grep actually came out of ed not the other way round). Vim can be used in a sort of ed mode with vim -e (AFAIU it's actually ex mode, which is a more advanced version of ed).
So I'd say vim is more like any sort of GUI/TUI or text editor plugin for git and git is like the old ancient CLI equivalent ed that no one knows about or uses anymore because having a visual mode just makes too much sense.
And this is basically where I fall ... I think a vgit should exist, that provides a terminal TUI of some sort, and that as with vim and ed it should totally supplant git while also having a CLI mode too. That this hasn't happened, back to my original point, is a problem and honestly a little strange.
I mean sure. I personally haven't researched and become an expert on this ... it is an early-user's misconceptions thread after all. And a dev can justifiably reflect on all of their tooling and consider their general usability against their popularity.
However, by the same token, your lack of any counter examples isn't exactly highly credible either.
Nonetheless:
Whenever I've seen an opinion from someone who's used both mercurial and git, their opinion is always that the mercurial interface and model "actually makes sense"
AFAICT, the git CLI (at least up until the more recent changes) has widely been recognised as being unnecessarily janky and confusing especially for common and basic tasks
Apart from that, many devs have shared that they always struggle to remember git commands and always need to rely on some reference/cheat-sheet (obligatory XKCD), which IMO is a product of it both having a poor CLI in need of polish and being a program/tool that isn't naturally constrained to CLI usage but rather naturally implemented with a graphical of some sort.
You didn't provided a single concrete example of something you actually feel could be improved.
The most concrete complain you could come up was struggling with remembering commands, again without providing any concrete example or specific.
Why is it so hard for critics to actually point out a specific example of something they feel could be improved? It's always "I've heard someone say that x".
Because this is a casual discussion and that’d be more effort than I’m willing to put in. Also, your premise is false: it can both be trivial NON-trivial to implement something better and relatively obvious that a better implementation could exist.
Also, if you’ve encountered these sorts of discussions before, I’d dare say it’s because people often avoid flame wars and you give off flame war energy.
I’ve mentioned two pretty concrete examples: be like mercurial and have a built in GUI. The basic commands being janky is also pretty concrete given the recent additions that have been made to correct that. But I don’t trust that you want a discussion because you’re being pretty demanding and aggressive here. Sea lioning would be somewhat apt … there is such a thing as meeting people where they are … do you have an example of something people often criticise about git that you don’t think can be improved or not easily? “Why is it so hard for replies to actually have a discussion rather than be demanding, argumentative and aggressive”
Because this is a casual discussion and that’d be more effort than I’m willing to put in.
I didn't asked you to write a research paper. You accused Git of suffering from usability issues and I asked you to provide concrete examples.
And apparently that's an impossible task for you.
If you cannot come up with a single example and instead write a wall of text on you cannot put the effort to even provide a single opinion... What does this say about your claims?
Yeah sure. git push says "did you mean git push -u branchname origin". Yes obviously I meant that. I always mean that.
I'd been copying and pasting that for about 5 years before I discovered there's a feature (auto branch setup or something) which means it will automatically do that. But it's not mentioned in the error message! Why?
Git has a load of --fixed-behaviour flags like that that are just not on by default and never mentioned.
The terminology is very poorly chosen in a lot of cases. "The index"? Wtf is that? "Staging area" is at least slightly better but would "draft commit" have been too much to ask? Ours/theirs is also a stonkingly bad choice of words. How does Git know which code is mine? It doesn't. Hell it isn't even consistent about which way around they are.
Someone has force pushed a branch and I want to update my local ref (without typing the whole branch name again). git pull gives a wall of text without the answer, which is.... git reset --hard @{u}. Catchy!
Or maybe I've got a branch that is tracking my fork but I want to pull from upstream. Can I do git pull upstream? Nope. I have to repeat the branch name git pull upstream branch-i-am-on. (Please don't say "but git doesn't know which branch you want to pull.)
Then there's the error messages... Make a branch called foo/bar. Now try to check out a remote branch foo. See that nice explanation about how git branches are actually files and directories, not just strings? Nope? Huh.
This is just a few I can remember off the top of my head but it's the tip of the iceberg.
The completely useless error messages kill me. And the commands that don't do what they say... WTF is the point in "clean" and "force" if they don't clean or force? And then there's the inconsistency in command arguments. With one you have to use force, even though it doesn't actually force, and the other you have to use "hard". Hard? I mean I guess hard makes sense once you realize that force doesn't actually mean force. Now I'm just waiting to run across the switch "--seriouslyguysimeanitthistime".
OMG, I can't up vote this thread enough... git is such a purposefully exclusionary step in software development that I can't believe it is the preferred solution. It is very powerful, but it is painfully obvious that no one has ever gone back and said, "but what if anyone else who wants to use this is not a Linux cli guru and already has an expert understanding of git commands?".
Why is it that learning to check in code is significantly harder than learning the actual IDEs that the devel uses to develop the code?
It is very powerful, but it is painfully obvious that no one has ever gone back and said, “but what if anyone else who wants to use this is not a Linux cli guru and already has an expert understanding of git commands?”.
This x100. I mean I think I know the answer - Git was written by a C kernel guy, and the devs that it attracted are C guys. The kind of people who think user friendliness is a weakness. Guess how you contribute a patch to Git? Well step 1 is reading a 10 page essay... Needless to say that isn't going to attract many people that care about beginners.
The kind of "polish" I'm talking about is the sort that a good UI/UX/GUI dev would do by tracking common user behaviours and needs or having testing users run the app through its paces. All of these confusing instances where better terminology, commands and error messages would come up through a process like that.
Now, one could say that this is a dev tool which shouldn't need to go through that process. That developers should be expected to understand the tool's inner workings and conceptual model well enough to not need any of that. But that gets back to my initial point. Git is so popular and basically ubiquitous now that that policy makes little sense. Many devs who use or are expected to use git are not capable of getting to terms with git's internals to the point of never having difficulty with the UI, either because of a lack of time, capacity or skill. Moreover, the time required to get familiar with git enough to never find the UI frustrating should not be underestimated ... it's not just conceptual but technical and specific to git's implementation details to the point of just knowing how the UI/CLI has been implemented.
If you want to trash such developers ... go ahead ... but they're still developer's doing work and it's to the industry's benefit to have a standardised and powerful VCS ... which means that at some point it's worth thinking about meeting developers where they are.
Beyond all of that ... one could also say "fuck that" and talk about how being popular and "the standard" requires being better. Git's centrality to the dev workflow as at text-editor levels. But while text editors have a portable format (IE "plain text" and character encodings) and so enjoy pretty healthy competition (vim, emacs, sublime, VSCode, Jetbrains ... etc) ... VCSs, AFAICT, don't have the same portability and neither the competition. I'm actually curious now ... are there drop in replacements for git that provide complete compatibility but are completely different implementations?.
It's interesting, IMO, to think about why/how this has come to be, but in the end, it means that there's a lot on git's shoulders here. Even a little bit of an improvement can go a long way, and so being critical (rather than cultishly defensive), I'd argue, is the correct aspect here on utilitarian grounds.
As for why git is in its current situation (without having really thought about it before) ... I'd actually speculate that there's something insidious here regarding it's imperfect/confusing UI. Namely that it has a monopolising force. Once it's gained critical mass, and once there are enough devs out there who have deep and experienced understanding of the tool, and enough internet content capturing that expertise, then moving off to another tool which doesn't have the same established expertise is prohibitively difficult. Comparing here VCS to text editing and programming languages may be part of it, where the basic difficulty of doing VCS (at least in so far as the complexity is exposed to the user) is likely somewhere between that of a text-editor and a programming language. In a similar vein, the solution space for VCSs is probably relatively small while text-editors and languages enjoy a good deal of design variety. And so, there's little interest or inventive or even capacity to come up with interesting alternatives for what is a relatively difficult/complex kind of tool, which gives any established VCS a good amount of competitive protection and inertia.
Keep in mind though, I'm not talking about the UI here, but the core functionality. That many GUIs exist shows that the UI is a relatively open design space. But that git itself has hardly explored that space on their own is my critique (where comparing to text editors like vim/nvim and emacs and the built-in features they have might be informative here).
Probably important to remember that Git was designed by Linus Torvalds, the same dude who developed the Linux kernel, and who is infamous for going off on big rage-fueled rants when questioned about his methods. So yeah, it’s going to be clunky and obtuse.
YOLO! I like my commit history to tell a story of hope, defeat, pain, ennui, and triumph. A story filled with cursing and humor. The code is WHAT was done. Comments in the code are WHY something was done. Commit logs are for entertainment purposes, and for batching changes together in bite sized chunks to make PR reviews easier.
I wanted to automate the setup of my desktop environment, but didn't know what got changed in the individual config files when I tweaked a setting in the UI.
So, I did a git init in ~/.config/, added all files to an initial commit, and then made the change in the UI. Afterwards, a git diff showed the exact changes I wanted.
Merge. One of the values of a VCS is to preserve history in detail, and merge is the only method that does that. Also, it's easy to foul a remote branch with the other methods if someone has already pushed changes to branch 1.
Shared branches should always only move forward. Most Git-* systems support stuff like protected branches.
I personally like tidying up your own feature branch with rebasing and then merging it into main (preferably using only FF merges). However this is not scalable for some larger projects, and for example monorepos also make this hard to accomplish. In those cases the solution ends up being squash+merge.
The extra information about the squashed commits is usually persisted to these systems (GitHub PRs, GitLab MRs, etc) so you don't really lose much, I guess. Although I do prefer keeping it all in plain git.
I feel it's a balance. Each operation has a purpose.
Rebasing makes sense when you are working in a feature branch together with other people so you rebase your own commits to keep the feature branch lean before you finally merge it into the main branch, instead of polluting the history with a hard to follow mess of sub branches for each person. Or when you yourself ended up needing to rewrite (or squash) some commits to clean up / reorganize related changes for the same feature. Or when you already committed something locally without realizing you were not on sync with the latest version of a remote branch you are working on and you don't wanna have it as a 1-single-commit branch that has to be merged.
Squashing with git merge --squash is also very situational.. ideally you wouldn't need it if your commits are not messy/tiny/redundant enough that combining them together makes it better.
Imho commit messages should express intent and not what is actually done to the code. An AI can't know the intent behind the changes, so this is useless. Now in reality most commit messages are pretty bad and this could help improve them somewhat, but it seems like a slippery slope into making commit messages pointless.
That was only a very rough version. His original plan was to use it as a backend for other VCS. Torvalds handed over the maintainership of the project to Junio Hamano after about 4 months. Much of what we know today as git are contributions from him and others.
None of this is to say that Torvalds didn't invent it. He invented the content addressed object storage format. But it's important to understand the actual history of git's evolution.
Git
Top