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

[Vaclav Petras]

On Thu, May 16, 2019 at 2:07 AM Martin Landa <landa.martin at gmail.com> wrote:

> Hi,
>
> st 15. 5. 2019 v 18:20 odesílatel Vaclav Petras <wenzeslaus at gmail.com>
> napsal:
> > 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). What other OSGeo projects are doing is that
> contributing guidelines say that you should do pull request. It seems that
> this is often preferred way even for core developers. From what I gathered
> from a small sample of people at OSGeo sprint, the core devs don't go
> though fork, but they do go through a branch. In GitHub, we can set
> "Require pull request reviews before merging" and "Include administrators"
> for the master branch to enforce that. I think we should do it at least at
> the beginning.
>
> I tend to agree. Contributes with a write access should do PR for
> massive/tricky changes. It's perfect platform to discuss/improve
> changes before merging. Trivial changes can be committed/pushed
> directly, no PR needed.
>

That's the tricky part. The direct commit-push workflow brings issues and
projects tend to avoid it. The most direct access is (usually?) going
through a branch in a main repo and merging that (merging through GitHub
PR). The point of PR is not only discussion but also testing. The CI should
run for every commit (chunk of commits in PR to be exact) before it goes
into master.

Additionally, it there are simply no trivial changes. Even a change in
documentation page can introduce an HTML tag not recognized by g.html2man
causing compilation to fail. Similarly, with asynchronous commits you are
at risk of conflicts and always in need of merge and the question is how
you want this to be recorded in code history. With Subversion, each
developer needs to resolve that before commit individually. With Git, you
can have history with locally created automatic merge commits, you need do
git pull --rebase locally, or you need to do PRs*.

I'm not saying this because I particularly like that, but because that's
how Git/GitHub** is used and that's what we are signing up for.

* PRs are called merge requests in GitLab; perhaps hinting more on what
they are for.
** This is not limited to GitHub, for example, GitLab by default locks
master when you create a new repo.

Vaclav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20190516/51c015b3/attachment.html>