Earlier quoted context omitted.
Let me ask, do you think that the content of my message reduces to "graphical user interfaces are harder to use than CLI"?
Yes, I do!
[deleted]
Apache Software Foundation joins GitHub open source community
111–120 of 255 posts
Re: Apache Software Foundation joins GitHub open source community
#112Earlier quoted context omitted.
The majority of git users I know don't know how to create or apply a patch. The few that do only do so in the odd FOSS project that requires it. Whereas when using Github you click a button, get your own copy, do whatever you want to it, and then click a button to open a pull request. You _tried_ to make it look like using GitHub.com is somehow... complicated. But it's dead simple and you even added steps, like "wait…
> You might like the mailing list Wrong. I fucking hate mailing lists. > You _tried_ to make it look like using GitHub.com is somehow... complicated. Please actually point out how the GitHub workflow can be even more simplified than what I outlined above. > But it's dead simple and you even added steps, like "waiting for PR to merge" That's not an added step. It's a necessary precondition for the following step (whic…
Can you clarify the flow that doesn't involve github and also doesn't involve mailing lists?
Re: Apache Software Foundation joins GitHub open source community
#113Earlier 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…
GitHub could support this workflow - they would need to find a way to integrate patches into GitHub Pull Requests.
One way to do it would be an "upload patch" option on others' repositories, where GitHub forks the repository for you under the hood, possibly creates a branch for you, and applies your patches linearly to that branch. It opens a pull request to the targeted branch of the upstream repository from your branch. Then when the pull request is closed, it cleans things up for you (temporary branch, fork) under the hood, if desired.
Re: Apache Software Foundation joins GitHub open source community
#114Earlier 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…
I agree that the initial review creation process is a bit complex with the GitHub flow. But most of the time, you end up needing to make changes to your diff based on review comments, etc.
Then there is hooking up PRs to your automation setup.
This is where the GitHub approach shines imo.
Re: Apache Software Foundation joins GitHub open source community
#115Earlier quoted context omitted.
Better participation. A lot more people know how to use GitHub's tools. It'll likely increase the amount of development, participation, pull requests, etc that ASF projects get. Does it matter that GitHub themselves is not open source?
while that's true, a big project like apache could push gitlab instead, as that's _more_ free and open-source.
They could even consider HN darling and 100% Free Software Forge SourceHut, but it seems major FOSS brands are looking for maximising network effects (and associated lock-in) these days
Re: Apache Software Foundation joins GitHub open source community
#116Earlier quoted context omitted.
> Please actually point out how the GitHub workflow can be even more simplified than what I outlined above Adding a remote is generally a one-time cost and is unneeded for every PR, so adding that command (along with all the associated comments) makes it appear more complicated. The reality for most GitHub users is that they simply have to do: `git push origin `
You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows. > Adding a remote is generally a one-time cost It's not a constant cost, unless you're saying you only ever intend to contribute to one project ever. It's a fixed cost that you will pay N times, where N is the number of projects you contribute to.
> You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows.
Having to create a fork per PR is a rather antiquated way of doing it. In my experience, you can almost always push to origin and create a new PR from the branch, but maybe I've just been lucky with the projects I contribute to.
> It's not a constant cost, unless you're saying you only ever intend to contribute to one project ever. It's a fixed cost that you will pay N times, where N is the number of projects you contribute to.
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 both N times, where N is the number of projects you contribute to.
Re: Apache Software Foundation joins GitHub open source community
#117For many years now, it's felt like Apache software foundation is where projects go to die.
It's a shame its taken so long, but I'm glad to see this news - it's pretty much guaranteed to increase participation in Apache projects.
Re: Apache Software Foundation joins GitHub open source community
#118Earlier 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…
You can create a pr with the open source "hub" tool with a single command.
Re: Apache Software Foundation joins GitHub open source community
#119Earlier quoted context omitted.
> You might like the mailing list Wrong. I fucking hate mailing lists. > You _tried_ to make it look like using GitHub.com is somehow... complicated. Please actually point out how the GitHub workflow can be even more simplified than what I outlined above. > But it's dead simple and you even added steps, like "waiting for PR to merge" That's not an added step. It's a necessary precondition for the following step (whic…
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.
Re: Apache Software Foundation joins GitHub open source community
#120Earlier quoted context omitted.
> Please actually point out how the GitHub workflow can be even more simplified than what I outlined above Adding a remote is generally a one-time cost and is unneeded for every PR, so adding that command (along with all the associated comments) makes it appear more complicated. The reality for most GitHub users is that they simply have to do: `git push origin `
You can't push to origin unless it's your own project or your team's. We're talking about PR-based workflows. > Adding a remote is generally a one-time cost It's not a constant cost, unless you're saying you only ever intend to contribute to one project ever. It's a fixed cost that you will pay N times, where N is the number of projects you contribute to.
Right, you set origin to the branch you own, and upstream to the original project. Then `git push origin foo` works, and you can get a URL printed directly on commandline to start the PR flow.
I agree it's a cost per repo you contribute to. However, you can also do it reasonably cheaply with scripts. I recall you have to use hub in addition to git commandline, but once you get it set up then it's basically zero extra commands if you bake it into a clone. Run a script that does the fork to your github username and clone to your local box, do your normal modifications and commits, then git push origin and click on the URL to get dropped into the upstream PR workflow.
The fork bit only needs to be done once.