Hi, On Wed, May 17, 2017 at 3:55 PM, Bastien Nocera <had...@hadess.net> wrote: > On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano wrote: >> > -------- Original Message -------- >> > Subject: Re: Proposal to deploy GitLab on gnome.org >> > Local Time: May 17, 2017 2:10 PM >> > UTC Time: May 17, 2017 12:10 PM >> > From: had...@hadess.net >> > To: Carlos Soriano <csori...@protonmail.com> >> > desktop-devel-list@gnome.org <desktop-devel-list@gnome.org> >> > >> > On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop- >> > devel- >> > list wrote: >> > > Hey Bastien, >> > > >> > > Not sure if you read the wiki and the workflow we outlined in >> > there, >> > > since we mention how this works. You will realize that's not >> > > necessary for you, neither a git-bz alternative since you will >> > use >> > > just git: >> > > - git-bz apply equals to git checkout remoteBranch >> > >> > No, it doesn't. git-bz apply on a master or version branch will >> > allow >> > me to amend commits. It does everything but push. The above doesn't >> > allow me to apply the same set of patches to a development and a >> > stable >> > branch for example. >> >> Doesn't git rebase do precisely this? > > I don't quite understand the workflow for users to create merge > requests with patches added, compared to my experiences with GitHub for > example, so bear with me. > > If I'm a registered developer for the GNOME org, or that particular > module, I'd create my merge requests as wip branches in the main > repo?Or as branches in a separate repo that I have the control of? > > What about developers that don't have GNOME commit access? Do they > fork, play in their corners and then create a merge request?
The typical workflow as advised by github (and therefore I believe that's similar in gitlab), if not mistaken, is: 1/ clone the repo you want to fix into a new public remote by clicking a "fork" button in the web GUI. So for instance if your nickname is 'bastien' in git.gnome.org, let's assume that 'gnome-shell' repo is under git.gnome.org/git/gnome/gnome-shell, then clicking the button will create a new remote git.gnome.org/git/bastien/gnome-shell. Notice that the origin URL is slightly different from current (adding gnome/), that's because github/gitlab need are all prefixed with some kind of project or user namespace (so I guess git.gnome.org will have to update project URLs with this concept, no?). 2/ Clone your personal repo into a working branch on your computer. 3/ Make your commits and push. 4/ Go back to the web GUI and click the merge request button. Personally I don't think I ever did this, because I want to checkout a code before even being sure I would do a patch. Creating a public repo just to read code is dumb. 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. 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? > Does that > merge request automatically create a branch in the upstream repo? How > do we stop merge request spam, or the unbounded growth of the repo with > all the wip branches, if that's the case? No. AFAIK, merge requests don't create an upstream branch. Fortunately this would be a very bad security issue! Jehan >> > > - git-bz attach equals to git push origin HEAD:fix2340issue, then >> > > click create merge request. >> > >> > Does this rewrite the commit message to include the PR or bug >> > number? >> >> No, as written in the wiki you write "Closes: $number" and it will >> handle things automatically. >> Of course some addition could be done to do the rewrite. > > Right, so that's not automated, and you can't know what to put in the > commit messages until you've create the merge request. Kind of a > chicken and egg problem. > >> > Do we end up with separate merge requests and bug numbers, >> > segregating >> > users and developers? And yes, clicking a button is a problem when >> >> Yes. They are different concepts in this tool, which I though it was >> an improvement. The bug is more about the discussion of what is >> wanted/motivation/reasoning/design/etc., the merge request is about >> pure code. >> Not sure I would frame it as segregating users and developers though. > > As Jehan mentions, it is. Users filing bugs look at open issues, most > of the time, but don't look at merge requests at all. > >> > "git-bz file" took care of all the clicky stuff on the command- >> > line. >> >> Right, that can be improved. >> >> > > And since you will have access to all projects...not need for >> > your >> > > own repo. >> > > >> > > Do you mean you don't like the extra step that is clicking once >> > per >> > > issue the "create merge request" button? >> > >> > I don't like the fact that the bug report and the merge request are >> > separate. >> > >> > > If that's the case, why is the command line tool we mention in >> > the >> > > wiki not good for you? (you will need some alias for adapting it >> > to >> > > your needs, or maybe we can modify to make the "create merge >> > request" >> > > more comprehensible?) >> > >> > The only mention of a command-line tool says: >> > "There is a CLI tool which allows a wide range of actions to be >> > done >> > from the command line, although it isn't particularly user >> > friendly." >> > which is a bit low on details to allow me to comment on it. >> >> It's rather vague, I agree. But you can explore it yourself, the >> readme of the project is quite explanation. But I'm afraid is not up >> to the expectations you have as it is right now. Would be good to >> improve this of course. > > Do you have a link to the tool and its documentation? There's nothing > in the Wiki linking to it, it just says "a tool exists". > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
