Follow

GitHub workflow cargo culting rant 

re: GitHub workflow cargo culting rant 

re: GitHub workflow cargo culting rant 

GitHub workflow cargo culting rant 

GitHub workflow cargo culting rant 

GitHub workflow cargo culting rant 

GitHub workflow cargo culting rant 

@sir While I do wish the email-based workflow had more prominence, the reality is that it hasn't caught on among a very large group of developers.

Consequently, I wish glossier front-ends, such as GitLab, GitHub, and Gitea, would allow accountless submissions; a page where a person could attach a patch and contact info and be done with it. I don't want to have to sign up with these rando instances to contribute one patch - but that feature alone would alleviate what I find to be the biggest problem with the non-email based workflow in an otherwise decentralized system.

GitHub workflow cargo culting rant 

GitHub workflow cargo culting rant 

GitHub workflow cargo culting rant 

GitHub workflow cargo culting rant 

re: GitHub workflow cargo culting rant 

re: GitHub workflow cargo culting rant 

re: GitHub workflow cargo culting rant 

re: GitHub workflow cargo culting rant 

re: GitHub workflow cargo culting rant 

re: GitHub workflow cargo culting rant 

@a1batross @sir it's typical package splitting idiocy. I use it actively, the package is git-email
@sampo @sir yeah, I found it.

Maybe they did to get rid of Perl dependency? No! Git still wants Perl no matter what.
@sampo @sir (and I'm not sure if it's even possible to not have perl in git)
@a1batross @sampo @sir I don't have perl in git on a gentoo machine that only needs to pull and push, but it is necessary for email and other things.
@siina @a1batross @sir yeah, I have one machine where I only use it to pull the portage tree and it doesn't need perl. on debian the main package pulls in perl, debian doesn't need a sensible reason to split packages, nor does it need to inform you in any way that you may be missing functionality.
@siina @sampo good. So what's Debian problem?

@sir I didn't read Git source code but I suppose some part of it uses perl.

@a1batross @sampo like half of git is implemented in perl lol, get over it

@sir @a1batross @sampo And a large chunk of debian, specially dev side is done in perl.
@amerika @a1batross @sampo @sir Well so far I don't hate it, which is quite good for a language which isn't C or Shell. (And Elixir could still get much better)

re: GitHub workflow cargo culting rant 

re: GitHub workflow cargo culting rant 

re: GitHub workflow cargo culting rant 

not sure why github workflow has gitea or any server at all?

0. discover
1. signup for github (how is this different from any other service website today)
2. click on "fork" on the target repo's page

## A (if it's a small change in one file)

3. edit right in the browser (or ctrl+{a,c,v} into your desktop editor if you need more stability and functionality)
4. commit change(s)
5. send PR (if you start by pressing edit button on the target repo's file – it will clearly suggest to make a PR after commit was saved to your auto-forked repo)

## B (for changes across multiple files)

3. add ssh key on github site
4. clone repo to the desktop over ssh
5. > Write & commit change(s)
6. git push
7. back to the still open github page of your fork and send a PR

@dym
>signup for github (how is this different from any other service website today)

it is different from the email workflow, which is exactly what I am pointing out. Also note that GitHub, Gitea, GitLab, Phabricator, etc - all require this step on potentially hundreds of instances.

>edit right in the browser

Fuck this shit. I immediately close pull requests from anyone who used the browser editor, because it means they didn't test their changes. Test your fucking changes.

i use web editor for typos in docs and readmes all the time, there is literally nothing to test lmao

this "GNU purism" stance is why some programming communities have a bad rep
@dym @sir I doubt that the idea of using the proper tool for a certain task is "GNU purism". Thinking your browser is an OS and should be used for every task imaginable (from the mistaken idea of "convenience") is why browsers are the piles of steaming shit they are today.
@tyil @sir you gatekeeping the past for no other reason than to prove superiority of your efficiency?
@dym @sir "gatekeeping the past"? What's that supposed to mean.

I see me claiming superiority either, just calling you out on bullshit, and explaining how your specific way of thinking has lead to objectively worse software over time.
@tyil @sir bullshit calling does not bring positive change. OS is where the apps are, and they all on the web.

you only want apps from the past where everything was written in assembly to run on casio watch – thats gatekeeping.

ease of build on top of webstack have proven to be more profitable than 10 years of research and development for a single enterprise product, or you also believe that internet should have never gone beyond academia?
@dym @sir You're making a lot of assumptions there, and all of them are wrong.

@mia Having never applied for a "full stack developer" job is easily my proudest accomplishment.

That shit needs to stop.

i was expecting some number of counterpoints, but alas
@dym If you had made any points, there would be something to counter. Instead, you made a number of ad hominems based on false assumptions of me.

@tyil @sir @dym I would like to know what you mean by the "mistaken idea of conveniece"? I understand the technical argument about bloated browsers but especially for non low level tech people it often seems really more convenient then anything else we have to do things in the browser.

@AnianZ @sir @dym Something that may seem convenient at first, but turns out to actually be a major step down. Many people claim they do (or don't do) something because "they're lazy", but in turn it leads them to spend way more effort on doing something simple in the end. It's perhaps a short-term gain, but a long-term loss.

@tyil @sir @dym fair point. But especially in the example here unsing the browser editor of e.g. Github might be exactly the right tool for editing documentation. It makes it more accessible to people who might not even know git but are familiar with how to use a Browser and create an account. Of course for code changes that might be a horrible idea as has been pointed out.

@AnianZ @tyil @sir have you heard of travis-ci? the point is you commit and push changes, and it test them for you, since you'd work on a laptop on the train and dont have time, power, or connectivity to recompile the rust core atm

@dym @sir @tyil the maybe it's worth waiting with you contribution until you have the time, power or connectivity to properly test your change. And depending on what you are doing no automated testing can substitute testing you changes yourself.

@AnianZ @sir @tyil i bet even if i test my changes you still dont trust me and gonna test them yourself as well, so why double the work, just test all changes yourself

@dym @sir @tyil Because four eyes are better the two? "I don't test my changes, because the maintainter will test them anyway" is nonesense, rude in my opinion and wasting the time of the maintainer.

@AnianZ @sir @dym Perhaps for documentation, but even in that context I'd rather just use my regular editor and view my changes properly. For prose, something like travis-ci which is mentioned later wouldn't work at all, for instance. You need a human to read it, and experience has taught me that reading the finished product is important to get an idea of how it actually reads. Does the text flow well, is it grammatically correct, and surely other things that makes natural language so hard for machines to work with.

@dym @sir One note is that #Git isn't a #GNU project and if by purism you mean "one tool to do one thing and be the best at it", this is related to #Unix #philosophy and, while #GNU's ideas emerged from it in order to replace Unix, GNU is Not Unix (GNU), and so doesn't need to follow that philosophy.

@dym @sir One has to keep in mind that #Git was never designed to be used without #email (and it's rare to see any revision control system that isn't based on email). Of course, new workflows are welcome, but many projects don't provide ways to send stuff by email for unregistered users of a given repository host and don't provide in the hosted files a way to contact head of the project by email so to send suggestions or issues.

GitHub workflow cargo culting rant 

GitHub workflow cargo culting rant 

GitHub workflow cargo culting rant 

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!