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

GRASS GIS GRASS GIS developer
,
1

Dear all,

I would argue that even core developers should not be using the main repo as their
personal one and that, at least most of the time, they should instead be using the same
procedure as every other contributor.

Branches in git branches are really “cheap” (especially compared to e.g. SVN). They do
make it very easy to experiment and the more proficient you become with git you do tend
to use them more and more. If every core dev starts pushing their personal branches on
the main repo, very soon there will be noise that can effectively become too much for
UIs to properly display. For example, please visit
QGIS and click on the branch selector. They only have
release branches (like GRASS) and the UI is already at its limit. Imagine having e.g.
100+ more branches there…

with kind regards,
Panos

2

Hi Panos and all,

On Fri, May 17, 2019 at 5:09 AM Panagiotis Mavrogiorgos <pmav99@gmail.com> wrote:

I would argue that even core developers should not be using the main repo as their
personal one and that, at least most of the time, they should instead be using the same
procedure as every other contributor.

Speaking to people here at the Minneapolis sprint this seems to be the preferred way, although not always applied fully.

In any case, we should be using this at the beginning to be on the safe side. Then we can evaluate.

If every core dev starts pushing their personal branches on
the main repo, very soon there will be noise that can effectively become too much for
UIs to properly display.

This can be mitigated by deleting the branch after merge. There should be a button for that.