[GRASS-dev] svn/trac -> git/github migration plan

[Vaclav Petras]

On Wed, May 15, 2019 at 4:24 PM Markus Neteler <neteler at osgeo.org> wrote:
>
> On Wed, May 15, 2019 at 10:20 PM Luca Delucchi <lucadeluge at gmail.com>
wrote:
> > On Wed, 15 May 2019 at 21:40, Veronica Andreo <veroandreo at gmail.com>
wrote:
> > >> Another thing is the need for new contributing guidelines. Git is
not Subversion and committing to master won't work (please, let me know if
you want me to show some examples).
> > >
> > > I am very interested in such examples, esp. how the workflow will be
from now on for example when making a small change in manuals.
> >
> > Yes, it is important to know this. How to use branches and also how to
> > update local version from the master one. Should we use a private
> > clone and make pull request to the main repository o use the main
> > repository directly?
>
> AFAIK it is recommended to open an own "feature branch" in the own
> fork and then open a pull request.

Exactly. The important part to recognize is that trying to emulate the
Subversion workflow, i.e. simply committing to master, would soon turn into
a repo full of automatic merge commits in the best case and big confusion
in the worst case. Basically all projects (I think I checked QGIS, PROJ,
GDAL, PDAL) have fork+branch+pull request as their best practice. This
means that even if you are a core developer, you still should do that. The
exception common for the core developers is that they skip the fork part,
i.e. they branch in the main repo. However, I haven't seen that formalized,
so I think it is a tolerated practice rather than a guideline.

Hopefully, for the general case, GRASS GIS will not need any special
instructions. Often projects simply point to GitHub documentation for
making and maintaining a fork and making a pull request.

Although there will be extra steps for the people with direct access to
source code comparing to Subversion, the benefit is that there is (will be)
actually an extra step and that's CI build and (hopefully) test as well.
This should catch many issues before they get to master.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20190515/537da076/attachment.html>