2 years ago, while interviewing internally, I asked the team what VC they use. It was Team Foundation's proprietary VC (and not a DVCS). I mentioned to them that even MS recommends Git for Team Foundation's usage.
"Well of course, MS invented Git!"
Wrong on so many levels:
1. Conflating Github with Git.
2. They bought it, not invented/founded it.
3. Most importantly, MS's recommendation to use Git for TF existed long before they bought Github.
Needless to say, I didn't join that team. Unfortunately, misconceptions like these, and a refusal to use Git[1] due to its complexity are quite common at the company - and it is one of the larger SW companies[2] in the country.
[1] I'm OK with any DVCS. Even I prefer Mercurial to Git. But most of the company prefers SVN or TF's version control. In 2015, many teams had to be dragged kicking and screaming by IT from CVS to SVN. In 2015, when Git already dominated the world.
[2] By number of employees with "SW <something>" in their title. Not by revenue, etc.
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.
My take is completely opposite from yours. I think it's great when someone "gets" that git is an extremely powerful and capable tool with a horribly unintuitive user interface. Whether you call that "complexity" or just "terrible UX", to me that's a sign that someone has good instincts regarding the risks associated with this kind of "complexity". Whether I agree that a decision to shun git for that reason is justified depends on the specific situation.
> ... 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.
^ this. The comment's arrogance and narrow-mindedness is preposterous, and would be a strong signal to me to stay away.
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.
> That sort of arrogance is an important signal to me that I should limit my exposure to the people displaying it.
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 say this as a senior dev with 8+ years of experience working with git: git is nightmarishly complex. Highly stateful, insanely large CLI surface, huge amounts of terminology/concepts relative to the complexity of what you're actually trying to do with it. I've learned to navigate its waters over the years, fully appreciate the difference between git and GitHub, etc etc, and I don't blame anybody for being scared away by its complexity.
Git is super complex, yet it can be used successfully with just a few commands.
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.
As a whole, you are absolutely correct. But 99% of your daily interactions with Git come down to a handful of commands. Hell, print out a cheat sheet and tape it to your desk for the first few months of using it and you will be more than fine.
Until you make the slightest mistake and your work area gets into a state not covered by the cheat sheet. But of course, the standard recommendation seems to be just to remove the work area and check it out again :p
I’ve used git for 15 years or so. I use the same 5 commands. I haven’t run into a situation like you describe where I lose everything.
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.
Well, that proves the point that just having a cheat sheet isn't a complete solution. And unfortunately, I am the co-worker more experienced with Git :p. Well not quite, I have a co-worker who is roughly on my level and we keep helping each other and of course trying to google ourselves out of every corner we got us into.
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.
Well, be fair, grandparent argued that a cheat sheet would help "for the first few months", not that it is a "complete solution", so I don't see how my suggestion "proves" anything.
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.
Considering the popularity of git itself and the fact it is successfully taught at bootcamps and university at a satisfactory level, I would disagree that being a “deep tool” is part of the reason it’s not 100% ubiquitous. The easy parts are still very accessible to newcomers and the existence of deep part doesn’t negate that.
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…
The more relevant point is: do you refuse to work on some code or use a VCS on your code because of this complexity?
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?)
It might be hugely complex, but at the same time, I'd posit that 90 percent of devs use only 1 percent of its functionality, 95 percent of the time they use it, and get work done.
To be fair, most people who find it complex do so because Git has a very crappy UI. You don't need to understand the internals to use Mercurial, and I would imagine that's true for most other DVCS's. In that sense, I sympathize with them.
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.
I'm the guy people at $work call to do git submodule reorganization, troubleshoot lfs or recover disasters. I'm certainly comfortable with git. It gets the job done. The same can be said of svn.
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]
Same here. I use Git at work, but anything I control I use hg. The only factor making me more likely to use Git is Magit, and no good equivalent for hg in Emacs.
You could miss out on some good junior developers if you pick one thing they are ignorant about and reject them because of it. There are plenty of bright junior developers who don't know everything, have opinions on things that they think they know, but will work hard and pick things up once they get some time at it. Of course, if they outright refuse to use something then that's another story.
Not knowing git doesn’t have to be a permanent state. I am grateful for being taught git and tons of other stuff. I’ve thought many people many things and still have a lot of debt.
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.”
I would say "friction" is the right word and "dumb" is not the right word here. Centuries ago (in Internet time) there was a culture among server devs that anyone who could not or would not, learn and correctly execute 100 things in the shell that today are obscure and obsolete, was "too dumb" and "not professional" . Evolution and intelligence have moved along since then, and others crusted over and embedded the minimal practices needed.
Does a typical enterprise need a distributed source control system? It makes a lot of sense for open source.
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...
The (side?) benefit of a DVCS is that you commit locally. So I can do all my fun experiments on my team's codebase on my laptop - it doesn't pollute the number of branches on the server, etc.
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.
> 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.
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.
> Does a typical enterprise need a distributed source control system?
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.
I find distributed version control super useful for the enterprise. I have way more private repos than public.
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.
Git is a very malleable tool, you can use branches for many purposes, do all kinds of complex merges (e.g. subtree, etc). I think it can be made to fit most workflows.
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).
"Well of course, MS invented Git!"
Wrong on so many levels:
1. Conflating Github with Git.
2. They bought it, not invented/founded it.
3. Most importantly, MS's recommendation to use Git for TF existed long before they bought Github.
Needless to say, I didn't join that team. Unfortunately, misconceptions like these, and a refusal to use Git[1] due to its complexity are quite common at the company - and it is one of the larger SW companies[2] in the country.
[1] I'm OK with any DVCS. Even I prefer Mercurial to Git. But most of the company prefers SVN or TF's version control. In 2015, many teams had to be dragged kicking and screaming by IT from CVS to SVN. In 2015, when Git already dominated the world.
[2] By number of employees with "SW <something>" in their title. Not by revenue, etc.