Re: Proposal to deploy GitLab on

On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote:
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
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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]