![](https://secure.gravatar.com/avatar/df289df50fdbf5082ca7446e87c1ea72.jpg?s=120&d=mm&r=g)
Am 14.01.2018 um 13:03 schrieb Jabier Arraiza:
Hi, in git time maybe is better 2 patches substituted by 2 merge request ¿aproved?.
Any user can do a fork, start coding and submit a MR to the proyect. with or without access rights.
This is, I think, the git way to it, instead patches.
Also I couldent find the way to get in sync automaticaly my inkscape personal repo with inkscape one.
If this can be done by default, we can sugest leave in forks master branch clean and work with personal branches and MR.
This also reduce the number of branches in master (they realy not removed anyway you press remove it after MR merge.)
Cheers, J.
Hi Jabier,
your mail arrived just as I sent mine - and I fully agree. The workflow you describe is also the one I prefer (I actually use it myself most of the time - at the very least for larger code changes that have a regression risk).
However it really seems we need to improve our git documentation. I wasn't aware many of our developers were not used to it. For me it always felt like the "natural" way to do stuff whereas bzr always bugged me - seems many people actually feel the other way round. Also I always felt git was well documented but apparently people are struggling nonetheless, so a "copy+paste"-like section in the Wiki with the basic git commands tailored to work for the Inkscape project might be helpful.
There's one technical issue for which I'm currently not unhappy with people committing to the main branch: Unfortunately AppVeyor (CI provider for Windows builds) does not support building of GitLab merge requests yet, so currently only branches in the main repository will be built (unless one creates an AppVeyor account and enables builds for one's own repository which is why my own MRs are checked even though they are always committed to my own repository).
Best Regards, Eduard