|
Top-level
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. 136 comments
@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. I agree git focused too much on the most complex uses. But I also think git could be way better for the common use cases while still supporting less common ones. And I think and approach of "who cares about common open-source use cases" is not going to lead to much improvement in open-source version-control systems. Is there a package or distribution that does care about the niche needs of the FOSS community that is also routinely and happily used by people who are not members of that community? Earnest question because I can't think of anything, even Linux repos mostly avoided until there were non FOSS-centric distributions and I remember how controversial that was back when  @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 😅 There is no vendor lock-in here. You can use git entirely locally. You can use git with other hosting services. Whereas I believe there are exactly zero other companies with Perforce-compatible cloud repositories. @williampietri @Eramdam @tess and changing providers for that central source of truth is supported out of the box and trivial.  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. svn, frex. I found svn fine even on a large team, and comprehensible. Being slightly quixotic — I don’t know if testing should be first-hardest, but William “IEEE 755” Kahan says so and I find it so. It just isn’t paid or scheduled so!  @tess when you mean git, you don't mean github or gitlab, right? not a fan, but have had my name parked in them for eternity. i use them for submitting issues, but won't post my work on either. i use git and can't even imagine doing anything remotely technical without it BUT! i use it as a solo repository because as one of the first black women on github and gitlab... let's just say it was not fun. i've had for years now a very private homelab with all my coding work & experiments. @airadam @tess yeah. i was like, ohellnaw. but just setting it up was a learning experience and showed me what i want and don't want in the form of security theater. was Dx autistic at 50. it's one explanation for how easily i have take to techical things since i could read. but i don't fit the skin hue, nor age nor gender of what US views as a savant or a genius. so i learned real quick after a string of abuse to get my stuff offline & run my own homelab. +20 years now. @blogdiva the CLI is rage-inducing. I regularly use Gerrit, which is fine. But the tool itself is a nightmare. (I mean, five years in I can mostly do what I want with it but I still have to look up the arguments for a three-way rebase.)  @tess I wish I could figure out an easier way to test code. In general, I find a 2:1 ratio: for every line of code I want to test, there are 2 lines of test framework. @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 Don't forget the help command that tells you all about the internal implementation details of the command, instead of providing basic explanations and coherent examples of how to use it. @tess At the time git became dominant, I was doing most of my work in Mercurial. As someone familiar with CVS and Subversion, Mercurial's command set felt much more logical to me than git's; I'm not sure if that would also hold for folks new to version control. My feeling at the time was that git became the dominant VCS because of GitHub. @tess - Perhaps you will have all the same objections to #Mercurial that you do to #Git, but I find Mercurial more sensible and preferable. And there's #TortoiseHg for those who are uncomfortable at the command line. @tess Yes! I used to volunteer at a "web development for women" workshop with a prepared curriculum. Everything was like "Don't worry if you don't get it, just type what I type!" Then we'd get to the git part and spend 45 minutes just going from person to person trying to explain why they were doing such a non-intuitive thing. @tess You'd have real momentum with people making things work, and then the instructor would say, "Great! Now we're going to set up a repo and commit!" And they'd type along and do it, but then call one of us over and say something like "But what does this DO? Does it publish it on the web? Can someone else copy it if I put it here?" Every course or tutorial says git is *essential*, but if you just want to make a website for your freelance photography business... it's really not. @tess I really want to learn Fossil (https://fossil-scm.org/home/doc/trunk/www/index.wiki). I’m fine with git but also I strictly limit what parts of it I will use and have my own patterns. But of course no one wants to run Fossil for a project because of course not. Of course a bunch of Fossil features are one that github, gitlab, bitbucket, etc also have added in subtly different ways on top of git. Wheeeee. @tess I view git the way I view nitroglycerin: leave it alone as much as possible. Even then it still just blows up for no reason. Source code management does not have to be this hard. There’s no good reason for it, and I think you’re right: its real purpose is to drive the “unworthy” out of the profession. @tess Darcs has a great UX compared to Git. I really struggled to learn Git after starting with that. #Darcs can work for personal projects or small teams, but lacks a “GitHub”. Linus considered it for the Linux kernel, but it doesn’t perform well enough on huge trees. I used to be a contributor to Darcs I but now use Git exclusively because there’s no getting away from git. Once I mastered #Git it was simpler to just use one tool. @tess I came to git fairly late as everywhere I'd worked up until then had used other source control systems (ADC, SCSS, TFS, etc). Meanwhile, I notice that the bootcamp grads I meet have been basically taught that git and source control are the same thing, there's never been any other way to manage source, and anyone who doesn't know it is an idiot 🤬 @tess@mastodon.social I might be the exception, then! @tess I really think the free, private, online repos of GitHub were a huge factor in the rapid adoption of git and its becoming the de facto standard. There never were any free online SVN repos worth a darn. I mean yeah, there was SourceForge, but it was only free for open source projects. And it was full of ads, ugly, and clunky as sin. @tess is having a relatively easy filter (however artificial) reeeeealy a bad thing though? It definitely improves the SNR of contributions.  @tess @tess Mercurial's "commit first, branch retroactively" model is _so_ much better as an on-ramp, I remain very disappointed that Git "won". Git doesn't have an on-ramp, you have to understand why you want history to be a directed graph from the outset Git was designed to be a code colaboration tool, and it is probably the best such ever. It was never designed to be a version control system, even though if you squint real hard and stay away from most of the subcommands, it can be used as such. @tess Windows users would/should start with UI tools. No need to teach them CLI is the only right way to do things. @tess I was a software developer for about 20 years when I first encountered git. Version control was obvious to me as a concept as I had used CVS, SVN, Clearcase and TFS before. While I always had a feeling that one can do great things with git, I never felt able to actually type the right commands. And I always feel like a complete idiot when trying to do something not entirely trivial. But there was a solution: I became an architect, I don't code anymore, it's someone else's problem now. :D  @tess Yes, I held out against git for ages when starting out, to the point where I was being asked to send PRs etc and didn't know how to do it. To be honest even now I don't use anything much beyond git clone, git pull and the clicky buttons in VS Code.  @tess I feel like git is the last bastion of the old toxic “just fucking rtfm” part of the open-source community. The kind of people who think that GUIs are for losers, anybody who doesn’t use GNU/Linux doesn’t deserve respect, and that if you don’t like it, you should fix it yourself instead of complaining. It’s getting somewhat better. Somewhat. |
Gregory's Server
@tess
Don't tell anyone, but by git aliases map my old SVN finger macros over to the arcane git commands.