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.
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?)
> 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.
It doesn't even matter if they can think of one; assuming your own use cases for software are everyone's is proceeding from false premises and is the sort of thing that leads to (and necessitates) "hacky workarounds" and eventually the adoption of better software we should've had in the first place.
Assume nothing about user's use cases. A VCS should not be imposing arbitrary limitations on the files it's indexing. It's like the old-school filesystems we (surprise, surprise) deprecated.
Git is an absolutely abysmal industry standard and as far as I'm concerned is further proof of my theory that tech is lacking (and actively discourages) much-needed creatives from the field.
With them having more representation we would have replaced it years ago.
> As you do, I find the discourse around tech to be a pit of dismissiveness, avoidance, denial, resignation, and learned-helplessness
I have a whole tirade on this, but I completely agree. It seemed while going through college that the whole prescriptivism and general attitudes in tech are built in such a way so as to discourage certain mindsets which the industry DESPERATELY needs, and my hypothesis is that not having representation of those mindsets across the board has contributed to a much of the degradation of UX over time (along with collective laziness of course; low level languages being more work to use, much as I enjoy high level conveniences myself).
Right? Whether or not it's practical, it's the way we learn.
I used to see that sort of haughty "well why do you want to do X" response all the time on stackoverflow/its ilk (I've basically deprioritized results from that entire network of sites now), which isn't even a good tack as there are plenty of others who might want to do X for other, valid reasons; "why" shouldn't even be a question as far as learning goes.
Centralization is just the natural order. No one actually wants to "be their own bank" or credit union. Who needs the headache?
It's like how libertarians are constantly surprised in the rare instances that they get what they supposedly want that it turns out they didn't want it at all, but rather their idealized version.
Cryptobros don't have any concrete idea of how putting stuff behind a cryptographic proof makes it ""decentralized"". Which is why it does end up being centralized, just around the management of a handful of resource collectives.
considering "effective at Google" == projects destined for the Graveyard, I feel like they could've been asking themselves better questions