131–140 of 255 posts
Earlier quoted context omitted.
To all you who think this idea is unfounded or dramatic, remember that this is the entire point of FOSS. Whether this idea holds water is irrelevant, it's aligned to FOSS and it's strange that they don't appear to care or have valued other things over it.
Hmm based on this, the .org tld and the server providers can have control over the project too. Right? If so, we should use an open source distributed protocol.
Earlier quoted context omitted.
I guess gitlab is the same. The important flow is that there's a very easy way to fork and send a pull/merge request.
"Easy" like: git diff master..bugfix > bugfix.patch # or `format-patch` # now attach/upload bugfix.patch Instead of: # make sure you click around github.com to create third fork git remote add unnecessary-third-fork $THIRDFORK git push unnecessary-third-fork bugfix firefox $THIRDFORK # now click around to file a PR # now wait for your PR to be merged # now click around on github.com to delete $THIRDFORK # ... unless…
And you do need that fork. If you want any kind of CI/CD stuff on the repo you sort of need to pull the changes in from a third party source to make sure nothing bad will happen.
now try to keep your patches up to date with constant rebases and comments from reviewers. Maybe some parts are ok, but some are not so you go back and forth for a couple of weeks. Fewer people will want to go through this extra hassle that they don't even get paid for.
It confuses me why so many traditionally pro-FOSS projects move to a not-free-nor-open tool like GitHub. Do they think that they’ll get enough new contributors this way to offset the (more than slight) irony?
Earlier quoted context omitted.
Your references to clicking repeatedly, and the general fact that github.com's innovation is the GUI it puts on top of a git workflow.
I'm mystified about what's going on right now. Both versions involve clicking. Both versions involve command-line steps. The difference is that the GitHub version requires more of both, needlessly. That's the point of what I wrote. That's the only point. I don't understand this context where I'm being forced to defend an argument that's been foisted upon me and that I never made and never even thought of trying to ma…
Earlier quoted context omitted.
> you can almost always push to origin Why am I having to repeat myself here? You can never push to origin unless it's your own project or your team's project. > It's a constant cost in the same way that looking up where to submit your patch to is a constant cost. You will pay [...] N times, where N is the number of projects you contribute to. In other words, it's not a constant cost.
>why am I having to repeat myself here Because you are incorrect and not reading the responses. >you set origin to the branch you own...
In 2009, I brought the idea of using github up on the members@ list and was called a troll. Agreed, at the time, the message was trolling... https://imgur.com/a/JPQtCQ4 I brought it up again later in 2010 and 2011 on the members@ list too. Lots of discussion with the general consensus that it wouldn't happen because it isn't an 'open' platform. I even wrote a blog post about it in 2011, which was also discussed on me…
Nice effort. Some people are slower to adapt than others... as you say in your blog post, GitHub (or something like it) was always going to be much more attractive for people to contribute than the "old ways" of mailing lists... but there's always the risk you'll invest on a platform that will be dead in 2 years. So being conservative is necessary for larger organizations.
Earlier quoted context omitted.
What? You get to imagine some bad argument that would make it most convenient for you, and then demand that I defend that argument, as if it were one that I wanted to make? This is what I'm responsible for? Dealing with someone who resorts to strawmanning the person/idea at the other end when challenged?
I'm not imagining it, and that's the problem you're running into. It's a consequence of what you said.
Earlier quoted context omitted.
Can you clarify the flow that doesn't involve github and also doesn't involve mailing lists?
You could upload the .patch to something other than GitHub.
Earlier quoted context omitted.
> you can almost always push to origin Why am I having to repeat myself here? You can never push to origin unless it's your own project or your team's project. > It's a constant cost in the same way that looking up where to submit your patch to is a constant cost. You will pay [...] N times, where N is the number of projects you contribute to. In other words, it's not a constant cost.
>why am I having to repeat myself here Because you are incorrect and not reading the responses. >you set origin to the branch you own...
Don't jump in to the middle of the conversation here and then tell me that I'm not following along after saying to me that, in fact, you configure your remotes to be able to push to them. I know that! That you have to configure your remotes and that you can't just ignore it is _my_ position!
The intense cognitive dissonance that comes out when GitHub is criticized on this site is friggin' _nuts_.
Earlier quoted context omitted.
> Does it matter that GitHub themselves is not open source? That's for Apache to decide, but consider: Git itself was written, by Linus Torvalds, because Linux (the kernel) was using non-open source version control at the time called BitKeeper, and the non-open source nature of it was causing increasing problems in the Linux developer community, both ideological and eventually practical problems too, caused by the li…
"Ideological and eventual practical problems too" is way too general. The very specific flash-point was Linus throwing an unjustified hissy-fit defending Larry McVoy of BitKeeper being difficult about Andrew Tridgel (Tridge of Samba fame) "reverse engineering" the data traffic of Bitkeeper for inter-operability (really just sniffing client packets with wireshark or something). Whether the name "git" pertains to Tridg…
He connected to a BK port and typed "help". BK helpfully output a bunch of protocol help. He used that to implement something minor (I think for archival?) and McVoy wasn't having it.