I kind of like this friction. If a software developer finds git too complex, that’s an important signal that I should minimize my exposure to them. I’d never work in a team that dumb, and I wouldn’t want any dependencies on their code.
Of course there are other reasons not to use git, but complexity is not one.
> ... that I should minimize my exposure to them. I’d never work in a team that dumb ...
That sort of arrogance is an important signal to me that I should limit my exposure to the people displaying it. I personally see this sort of attitude as a sign that there may be a dangerous lack of empathy on their side, and I've seen that go south too often.
I find Git's CLI and workflow model complex because I had the "misfortune" of using other DVCS products (Mercurial, Bitkeeper, Bazaar NG, Darcs, etc) before it. All did a far superior job of presenting roughly the same conceptual model in their command-line tools. Git's is a step backwards.
Git didn't invent distributed version control, it didn't perfect it, it wasn't particularly superior to the others [it does have some benefits in terms of performance tho, yes], it was merely at the right place (the Linux kernel when Linus got sick of Bitkeeper's business model) at the right time (when people finally got sick of CVS and SVN garbage.)
And the rise of GitHub was certainly part of the rise of Git's prominence.
Slightly different circumstances and it could have been any of the other open source distributed revision control systems instead.
Different strokes for different folks and not everyone is capable of working together. Comically, people like you would find your comment also arrogant and stay away from both of us.
For what it’s worth, I work on empathy quite a bit and my filter is based on the idea that it saves both me and the other party pain. I don’t want to work in a team where developers are tolerated giving up on super basic technologies like git (what else isn’t tolerated “oh, tcp/ip is just too complex for developers, I give up”) and they probably don’t want me to work with them.
I think one of the best things about technology is that people have great capability to solve problems. Giving up is a bad characteristic. Asking for help is important. Having teams of various skill sets is important. But giving up on basic things instead of getting help and figuring it out is bad as a permanent state for a team.
I blame developers and even most users for being too scared to use it. I think it’s perfectly normal to be scared of it while using it.
I think all users of technology should have some basic competence. Like every human should be able to be a basic Unix user, every human is capable of using git. And every developer should be capable.
Every one should be able to use Git. However, Git really isn't the best tool for everyone - or even most developers.
Worst case scenario is that I lose a check in, but even that is rare as I can just copy over, start with a fresh clone, and reapply. I don’t think there’s a significant danger of messing up a project. And again, this is just basic developer capabilities and developers should be familiar with a vcs enough.
The practical approach was to write a simple GUI which supports the operations "Pull" "Stage" "Commit" "Push", which makes live quite easy. And otherwise, try to keep out of anything more complex, until really neede. Works quite well, but I cannot say I am entirely happy. There are some benefits though, due to our company using a GitHub Enterprise installation for all version control. Ironically, our group recommended that some years ago, but because GitHub comes with a lot of neat features, less so because our love of git :)
And yes, over time, I am picking up more of it, but I try to do that on a slow pace, because I consider VC a tool which is important for work, but which shouldn't take time away from work. And Git definitely takes a lot of time to learn, there are far too many mechanics exposed to the end user.
Also, without knowing which issues you're having with git it's impossible to know if it's lack of baseline knowledge or if you're running into real complicated problems.
If you have a GUI with "Pull" "Stage" "Commit" "Push" buttons, I strongly suspect you're not in the complicated end.
Given the context of this thread, comments like these are part of the reasons teams don't use Git.
One probably needs 10x such teaching moments with Git compared to other VCs - including good DVCS.
And I also take issue with calling its “non-100% ubiquity” a problem. There is plenty of space for other tools. If anything, there’s almost a “git monopoly”.
Sure it could improve in parts, but the general discussion here doesn’t seem to be focused on improvements at all…
That was the GP's point. He acknowledged it's complex. But it's a very clear and very large amount of value left on the table, so people that gets scared away by it will probably practice other kinds of harmful behavior.
(Of course, the option of just using a simpler VCS doesn't tell anything bad about people. Why did we standardize on git again?)
My issue wasn't with their refusal to use Git per se. It was their refusal to find something better than SVN.
Given the choice, I too would pick something other than Git. But still better than SVN.
I'm pretty sure half of the teams that find Git too complex wouldn't find Mercurial to be complex. But they haven't heard of Mercurial.
However my own projects always start with hg init. In addition to the UI being less insane it also feels consistent and nice to use.
At one point I was on a team using Darcs, which was another level of beautiful but clunky in many ways. It is why I'm rooting for the Pijul team. [1]
To clarify, I’m not criticizing not knowing git. Lots of people don’t know git. I’m criticizing the decision not to learn git and being unwilling to learn it due to its “complexity.”
Doesn't the uptake in Github which centralizes this distributed system kind of invalidate its main tenant?
I haven't been a hundred percent sure the overhead was ever worth it at most other types of paid gigs over the years. Adding complexity without value is a mistake imo. Maybe it's my own fault I haven't seen the value...
Indeed, even when forced to use SVN, I would simply check out the SVN trunk, create a Mercurial repository in that "working" directory, and then clone from their whenever I did any development (one clone per feature). I would then push back to the main Mercurial repository, and push that to the SVN server.
Other than that - true. No real DVCS benefit compared to SVN. I would imagine most of the nicer Git features that people use have, or could have, analogs in SVN.
Once did something similar with Git, the one time I was at a place that used SVN. I didn't trust any of the git-to-SVN tools so I just did all my work in a local git repo, then copied my working directory to an SVN-controlled directory and committed maybe once or twice a day, when I had something worth preserving.
The ~week before I switched to this workflow was nerve-wracking. Not being able to make all the branches I want for any purpose at all without it showing up for anyone else, or to make shitty commit messages for my own local junk-commits before it was ready for consumption by anyone else, was awful. Having to worry that every little vcs operation might mess up someone else's stuff was the worst.
Luckily I was working on an isolated part of a larger system on my own, so this worked OK. No incoming code to worry about, so SVN was write-only from my perspective.
Yes, unless you are working on a tiny number of source files. The value is that you can work on entire copies of a code base at a time instead of single files. Git does a much better job than making lots of local copies of source code, passing around big diff files and is a lot less hassle than older centralized source control systems.
> Doesn't the uptake in Github which centralizes this distributed system kind of invalidate its main tenant?
No. Not at all. Github is actually a peer with an a few integrated extras for managing tickets and requesting your code be merged into github's repo branches. Most of the centralization is around access control and automation (i.e. continuous delivery, unit tests, etc...).
> Adding complexity without value is a mistake imo.
The main value of GitHub is reducing some operational complexity. For a small 1-4 person team, it may be of little value, but for larger teams, access control, issues, and automation can have a lot of value. For really small teams, fossil is actually quite nice. That said, there are a lot of great alternatives to GitHub that give you similar features.
> Maybe it's my own fault I haven't seen the value...
Probably not. I did the first 20 years of my career without source control and was able to build some pretty big applications. I do think dvcs was a big improvement, and I'm glad it exists now.
It’s useful because it makes it easy to have multiple copies of a repo and merges and branches are trivial. Just for my own project I might have clones on multiple machines. When I mess up and make a change, it’s not a big problem and merging is easy.
For team collaboration, I find it better than centralized because it makes it easier to work on multiple branches. It also encourages merge requests from people outside the team.
Not git's fault, though.
The main issue is repository size, which is hard to get from bad workflows alone, with the exception of insistence on tracking large binary files in Git (rather than LFS, DVC, etc).
You'd think developers could at least make the stuff they have to use decent. But no.