On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote: > Hi, > […] > The typical workflow as advised by github (and therefore I believe > that's similar in gitlab), if not mistaken, is:
Unless you have push privileges, in which case you'd just create a wip- or feature branch and make a merge request. This is what's recommended on the GitLabWorkflows[1] page. > […] So I just clone the upstream, and only if I end up doing a patch, > I would only then "fork" on github, then update my local repository > to point to my "fork", so that I can push then click the "pull > request" button. That's still very cumbersome. For most of us active in this discussion, this won't be an issue since we'll have push privileges (see above). However. What you describe above is how I make drive-by patches on GitHub, and I agree it can be a bit cumbersome. Fortunately there are tools to help you. I use git-spindle[2] which has support for GitHub, GitLab and Bitbucket. The, above manual steps becomes something like this with git-spindle (using graphene as an example repo): $ git hub clone ebassi/graphene && cd graphene $ git checkout -b wip/my-cool-fix [ do some work ] $ git commit -a -m "My awesome fix" $ git hub fork $ git hub pull-request [ Write merge message ] > IMO this is a completely broken and over-complicated workflow. For > long term contributors, having their own remote can be > understandable. > But for one-time contribs? > With proper tooling, the workflow isn't very complicated at all. And it's definitely not "completely broken" as you suggest. Regards, Mattias 1: https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/GitLabW orkflows 2: https://github.com/seveas/git-spindle _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
