|
Top-level
Imagine you're someone with an interest in learning how to code. Perhaps you're from one or more communities that face serious stereotype threat in this area (e.g. a woman or a BIPoC person) - that is, you don't have a ton of role models and may even have been told outright that coding isn't *for you*. But you decided to Do The Thing anyway, because you're a badass. 149 comments
I am extremely convinced that git is the Great Filter for people trying to get into coding on their own. It never ceases to make me sad and frustrated that we've settled on the Worst Possible Tool to do source management. Nothing in git is named or grouped coherently. It's the opposite of discoverable. Even with tab completion. By the way, you know who doesn't get tab completion? Windows users. Which is most people who are gonna try to learn to program on their own. Don't tell anyone, but by git aliases map my old SVN finger macros over to the arcane git commands. @jhulten I should use more aliases, except I'd have to implement them across multiple operating systems and shell environments @tess A decade ago I used freshshell to automate my dotfiles for *nix hosts. Now that I have WSL, I am covered everywhere. @tess I was consulting and would get a laptop for six months, sometimes overlapping between clients. I got it down to about 20 minutes to install most of my config and standard tools. @tess That's why asshole coders need to stop being gatekeepy about real coders using git from the command line Honestly, the devs that feel better than others because they use CLI are likely the worst at actually commitng properly. GUI's make it so much easier to cherry pick files and lines, and makes it much harder to make mistakes  @tess Totally. It was a tool made for an unusual case in a different era, created by experts designing for experts. I would love to see a modern VCS tool emerge, one that focuses on the common use cases for modern development, and designed with novices in mind. @tess Is it? It's older than git by a decade, right? And it's still a commercial product, I thought. @williampietri free for a lot of small-scale use IIRC, and pretty constantly updated also IIRC, plus what's wrong with paying for a good tool? But fine, use subversion plus a decent OSS shell integration. @tess Version control is an area where I'd be especially cautious about vendor lock-in. Especially in this age of enshittification. There's no way I'm trusting a company owned by private equity over a long-term relationship. And that's before we get to all the open-source concerns, where I think git has a legitimate edge. I think the Perforce/SVN centralization/SPoF model can be fine for companies. But that centralized control mindset doesn't work for richer relationship approaches. @williampietri even OSS projects have a central repo with the "canonical" source; I don't see the difference between hosting code on github or equivalent vs having it on a hosted SVN server.  @williampietri @tess i feel like warning about vendor lock-in for Git alternatives is funny. Sure GitHub the company doesn't control(?) Git the software but in terms of mindshare/how most people are exposed to Git they absolutely have the majority. Most people will host their code or touch code hosted on GitHub and `git` is just how you interact with it 😅  it depends... if you start in linux kernel development or surrounding middleware, it's The Most Natural tool pretty much soon after you start - rest is more complex than git. mostly worked with hardware (from big iron to network equipment to embedded) or design, all after uni. Uni are rarely to give proper sw de loop anyway Your source management tool should be the *easiest* tool you use, not the hardest. The order of difficulty in tasks should be: write code > test code > build code > manage code But in the real world the order is, somehow: manage code > build code > test code > write code This is incredibly stupid. @sophieschmieg precisely. Also: it's a graph theory peg being rammed into a source control hole. Chrome at least gives us a bunch of common functionality that sands *some* of the sharp edges off of it, but it's still awful to use and I'm still learning tricks that make my experience with it less painful five years after starting with it. @tess the fact that Chrome/gerrit and GitHub actually take different parts of git to mean certain things (in Gerrit you have individual commits as the thing that gets reviewed, with branches being used for separate versions, in GitHub it's branches and pull requests that get reviewed instead) is also a great sign that this isn't the best source control could be. And really, code review should be a first class citizen for a source control system anyways, and not tacked on by third party tooling  @tess Is this about command-line git usage? A decent GUI client made it so much easier, for me. @sindarina @tess It definitely can! Unfortunately there are also so many *bad* GUIs, too. Like when they replace Push and Pull with a single function named Sync. It's seems simpler until every tutorial you read is now referencing commands you don't have. Plenty don't do this, but it shouldn't be incumbent upon the person just getting started to know the difference. @tess I wrote code as my job for 25 years and spent very little time or energy on source code control. This had pluses and minuses and would probably not be possible any more. I did not work on teams very much until the very end of my career (last year in the industry was 2020). @tess Right!?!? And don’t get me started with some of the tool chains. Looking at you JavaScript. @tess 100% agreement about git not being the right thing to hand to people who are new to source control. When I was a TA, the professor wanted students to turn in assignments with a "real" tool. I opted for SVN over git. Students still did silly things when committing to the course repository, but I wasn't about to tell them to pick up a tool whose handles consisted almost entirely of sharp edges. The course was "make Roombas play soccer," not "how to lose your source code like the pros." my observations during hackathons with (mainly) students say me: @aytvill @tess (a) was definitely true... the prof's intention was for students to collaborate over svn, but I'm pretty sure most teams just hacked locally and committed to an assignment's tag when it was time to turn in. I'm not sure I understand your points (b) and (c). Were they complaining that the uni setting simplifies the collaboration problems you get in industry [so SCm as taught at school isn't helpful], and big FLOSS projects require use of git [so learning other tools doesn't help]? b) if your team has luxury of personal meetings, typically enforced by mgmt, then async dev mode turns into sync slot mode - you go away from bazaar to cathedral c) large FLOSS is bazaar at roots and that's what makes cathedral folks to abhor at dealing with what they perceive as chaos ;)  @trurl @tess I've been using lesser source controls (rcs, cvs, pvcs, clearcase, mks, some real esoteric ones) for years, then subversion for over a decade. Then I had to move to git, sourcetree and crapbucket. Then I learned fear. I've read many guides, but I still couldn't explain what a rebase is. @tess I am pretty far removed from teaching tools like this nowadays. If advising a smart, driven friend who's running Windows (like, say, my friend with a bio PhD who keeps asking me questions about awk and shell scripting), I would probably suggest they use their IDE's support for git or a shell extension like https://tortoisegit.org/. Is that a reasonable starting point these days? It doesn't help with the git model (or the myriad of oopsies like, "I rebased and can't push to remote anymore," and "I checked out a floating HEAD what is a floating HEAD oh god"), but at least it provides a UI layer that might help keep them from straying into that territory in the first week. @trurl oh neat, I didn't realize Tortoise did a git implementation! I used their SVN integration for along time. (Unfortunately, I'm now developing on three platforms for five, so I can't consistently use Tortoise.) @trurl @tess +1 for using the IDE. One chicken-and-egg reason for git becoming so ubiquitous is the amount of tooling for it. The fact that I can pull up VSCode and do all my day-to-day git stuff with just a couple of clicks makes it easy to ignore how awful it is under the hood. Comparing to Perforce, which I also have to use daily, which has minimal VSCode support, and I have to jump back to the (admittedly, 100x better) command line for the 10k edge cases.  @tess we do think you're right about this we have friends who've chosen to approach this from the documentation angle (cf. https://www.kickstarter.com/projects/essential-randomness/the-fujoshi-guide-to-web-development/description ) and we do hope that will help but it sure would be nice if the core git people would, like, loop in a tech writer for advice on names and conceptual organization and then actually take their advice @tess I miss the simplicity of SVN. Sure, it didn’t have a local copy of the entire damned repo, but who cares. Commit in SVN to a remote server does what I need, without the “are you sure?” semantics of commit+push. @tess there's got to be a shareware WinGit out there somewhere with a crudely implemented File Manager overlay to your repository "3. Okay, you actually wanna do development? Then learn git. The names confuse you. You end up fucking up your source tree six times before you learn reflog." Oh, so there's a way to unfuck a git repository other than blowing it away and {restoring it from time machine/blowing it away and cloning one of your remote repositories}? |
Gregory's Server
Imagine the steps you need to go through:
1. Pick a language. Python, Ruby, etc. There are nice tutorials online. You do them and feel smart.
2. Download a runtime and start writing code locally, testing it out. This can be tricky if you are trying to do web stuff, but whatever. You feel smart.
3. Okay, you actually wanna do *development*? Then learn git. The names confuse you. You end up fucking up your source tree six times before you learn reflog. You feel like an idiot.