I don't mix relationships with work. Being kind to people for the purposes of recommendations is not the same as a relationship.
Relationships are a thing I support outside work. Inside work, I might build rapport and expand my professional network; that is NOT THE SAME as meeting people for the sake of pursuing relationships, and as much as possible one should be kept away from the other.
I think one of the points that the author is trying to convey is that there's no simple "no" available. The only "no" is one of two bad options.
My guess is that given the having to say "no" in this context over and over means the difficulty can get to you and you end up saying "yes" on occasion.
As the git people love parroting of its myriad kitchen sink commands, "if you don't like it you don't have to use it".
I'd rather have a single integrated tool than the shopping list of "just use X and Y and Z" people are prescribing in this thread for getting the so-called git ""ecosystem"" ""working"".
Not that I'll necessarily use all the added features; but the ones I do want being integrated is absolutely relevant to my interests.
> Unfortunately for git alternatives, the momentum behind git is in large part pushed by the "social network" aspect of GitHub
And there was a time everyone thought facebook wouldn't dethrone myspace, [something.js] wouldn't replace [somethingelse.js], and so on.
First mover doesn't mean a lot in software. The network effect you brought up does, but there'll be plenty of people who don't want to get caught up in that "trap" and git/MS-land to seed a decent alternative. (Why should your code discovery networking site be prescribing your choice in VCS, anyway?)
I agree with all of this, for sure, and I look forward to the situation changing. And I hope when it does, it does so in a way where the system has more than just Git as an SCM option.
I had hopes for bitbucket for a while, but it stagnated, and then Atlassian got their mitts on it.
> Forget that you know git, github, git-lfs, even software engineering for a moment. All you know is that you're developing a general project on a computer, you are using files, and you want version history on everything. What's wrong with that?
>but I'll reluctantly accept that me not knowing how to use the tool is not entirely the tool's fault
I don't buy this. A good tool should do its job and stay out of your way. The amount of pointless knowledge I now have just to be able to use a version control system for my job still to this day annoys me.
Linus Torvalds isn't some infallible god, and it may be useful for linux kernel development, but we're not all linux kernel developers; and tools like VCSes, when designed well, should be unnoticed until the exact moment you need them, convenient and simple to use, and not get in your way or create problems for you where there weren't any to begin with. (Holy run-on sentences, Batman!)
In contrast, git goes out of its way to throw itself in your face at every opportunity, exacerbate your problems, and create a maze you either have to navigate precisely or just decide "fuck it" and do a copy/replace file trick just to get back on track with what you were actually doing.
The fact that people keep prescribing "just learn all its intricacies" or other band-aids (like the other "use with" software suggestions here) rather than even acknowledging it as a problem, to me, points to the lack of UX expertise in the field, and to stockholm syndrome.
(Which, funnily enough, is a problem things like git contributes to. It being one of the first things required to learn in CS, I constantly wonder how many of my peers might've switched out of the field given the mess it is, assuming CS wasn't for them. And, in turn, the breakthroughs we might've missed out on having earlier.)
Tools should be simple and usable, not throw up arbitrary barriers to entry.
considering "effective at Google" == projects destined for the Graveyard, I feel like they could've been asking themselves better questions