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

GRASS GRASS developer
41

Hi,

st 15. 5. 2019 v 18:20 odesílatel Vaclav Petras <wenzeslaus@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.

+1 my cent

Ma

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

42

Hi,

st 15. 5. 2019 v 18:47 odesílatel Markus Neteler <neteler@osgeo.org> napsal:

This are the authors who have a GitHub account known to us. There is a lookup table which maps SVN account to GitHub account (in addons/tools/svn2git somewhere).

http://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git/AUTHORS.txt

Please check if you are on the list. This list contains all
contributors including Addons!

Ma

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

43

Hi,

st 15. 5. 2019 v 21:32 odesílatel Helmut Kudrnovsky <hellik@web.de> napsal:

svn: hellik

gh account: hellik
email: hkmyricaria@gmail.com

in the case you have write access to Addons, you can directly modify
the file :slight_smile: Thanks, Ma

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

44

Martin Landa wrote

Hi,

st 15. 5. 2019 v 21:32 odesílatel Helmut Kudrnovsky &lt;

hellik@

&gt; napsal:

svn: hellik

gh account: hellik
email:

hkmyricaria@

in the case you have write access to Addons, you can directly modify
the file :slight_smile: Thanks, Ma

I have write access :-).

https://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git

which file should be updated/checked?

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html

45

čt 16. 5. 2019 v 8:25 odesílatel Helmut Kudrnovsky <hellik@web.de> napsal:

https://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git

which file should be updated/checked?

tools/svn2git/AUTHORS.txt

Ma

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

46

Hi,

Being no developer by education I can only second this!

Guidelines and simple, minimal example workflows would be very, very welcome (we learned fork->branch->commit->pull request (and then?, how do I keep my fork in sync, ...) ! I also agree that we should be vary of duplicating git documentation but rather have minimal description of recommended workflows, starting with the most common cases (which of course can evolve over time) and point to more lengthy explanations other places. Just like: https://trac.osgeo.org/grass/wiki/HowToSVN#SVNusage

git also has some pitfalls people should be aware of, like e.g. handling of line endings:
https://help.github.com/en/articles/dealing-with-line-endings
These can be pretty annoying, but circumvented if taken into account early on...

And then there are some more possible git adjustments (in the codebase), like proper markdown formating of the README as well as probably some stuff from here:
https://github.com/grass-svn2git/grass/community (yes, I am aware that this is not the final repo)

Thanks for the massive work, Martin (and others involved). Looking forward to GRASS on git!

Cheers
Stefan

Currently, I am struggling in another project with line endings which makes contributions across plattforms complicated...

-----Original Message-----
From: grass-dev <grass-dev-bounces@lists.osgeo.org> On Behalf Of Luca Delucchi
Sent: onsdag 15. mai 2019 22:21
To: Veronica Andreo <veroandreo@gmail.com>
Cc: Martin Landa <landa.martin@gmail.com>; grass-dev <grass-dev@lists.osgeo.org>
Subject: Re: [GRASS-dev] svn/trac -> git/github migration plan

On Wed, 15 May 2019 at 21:40, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi,

Hi,

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?

I think it is very important that those of you more familiar with git and GitHub develop or show example workflows of how to contribute, backport (if that will be still called like that), and so on.

+1

my 0.01 cent
Vero

--
ciao
Luca

www.lucadelu.org
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

47

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

Hi,

st 15. 5. 2019 v 18:20 odesílatel Vaclav Petras <wenzeslaus@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

48

On Thu, May 16, 2019 at 1:30 PM Vaclav Petras <wenzeslaus@gmail.com> wrote:

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

Hi,

st 15. 5. 2019 v 18:20 odesílatel Vaclav Petras <wenzeslaus@gmail.com> napsal:
> Another thing is the need for new contributing guidelines. Git is not Subversion and committing to master won't work

...

That's the tricky part. The direct commit-push workflow brings issues and projects tend to avoid it.

Agreed. Here two draft workflows, for
- core devs, and
- external contributors.

### Core developers
# workflow for core-developers, no fork needed but using feature
branches on master

# <make local source code changes>
vim ...
# fetch all branches from all remotes
git fetch --all
# list existing branches:
git branch -a

# create new local branch (pick a new name for feature_branch_name)
git checkout -b $feature_branch_name

# list local changes
git status
git add file1.c file2.py ...
git commit -m 'my change with reasonable explanation...'

# push feature branch to origin, i.e. original GRASS GIS repo master
git push origin $feature_branch_name
# create pull request in GitHub Web interface (the link is shown in
the terminal)

# during PR review phase, make more local changes if needed
git add .
git commit -m 'my second change'
git push origin $feature_branch_name
# ..... will be added to existing pull request

# NOTE: for different pull requests, simply create different feature branches.

#### External contributors
# workflow for external contributors - they have to fork the repo in
GitHub Web interface
# create fork via github GUI
git clone $my_for_url
# all steps see above
...
# push feature branch to own fork repo of GRASS GIS
git push origin $feature_branch_name # here: origin is fork repo
# create pull request in GitHub Web interface (the link is shown in
the terminal)

Certainly we need to write this up in a Wiki page.

Thanks to Carmen Tawalika for drafting the workflow.

Best,
Markus

49

On 2019-05-16 14:16, Markus Neteler wrote:

#### External contributors
# workflow for external contributors - they have to fork the repo in
GitHub Web interface
# create fork via github GUI
git clone $my_for_url
# all steps see above
...
# push feature branch to own fork repo of GRASS GIS
git push origin $feature_branch_name # here: origin is fork repo
# create pull request in GitHub Web interface (the link is shown in
the terminal)

May I suggest cloning the grass repo and adding the fork as an additional remote, this makes merging changes from the grass repo easier.

  git clone https://github.com/OSGeo/grass.git
  cd grass
  git remote add github https://github.com/&lt;username&gt;/grass\.git
  git remote set-url --push github ssh://git@github.com/<username>/grass.git
  ...
  git push github <feature-branch>

This way origin is the authoritative source for the code, and additional remotes are forks.

Kind Regards,

Bas

50

On Thu, May 16, 2019 at 8:26 AM Bas Couwenberg <sebastic@xs4all.nl> wrote:

On 2019-05-16 14:16, Markus Neteler wrote:

External contributors

workflow for external contributors - they have to fork the repo in

GitHub Web interface

create fork via github GUI

git clone $my_for_url

all steps see above

…

push feature branch to own fork repo of GRASS GIS

git push origin $feature_branch_name # here: origin is fork repo

create pull request in GitHub Web interface (the link is shown in

the terminal)

May I suggest cloning the grass repo and adding the fork as an
additional remote, this makes merging changes from the grass repo
easier.

…

+1 for Markus, Carmen, and Bas. That’s what I see used elsewhere too.

51

Martin Landa wrote

čt 16. 5. 2019 v 8:25 odesílatel Helmut Kudrnovsky &lt;

hellik@

&gt; napsal:

https://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git

which file should be updated/checked?

tools/svn2git/AUTHORS.txt

AUTHORS.txt updated in svn to primary gh email

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html

52

Hi,

On Thu, May 16, 2019 at 3:16 PM Vaclav Petras <wenzeslaus@gmail.com> wrote:

+1 for Markus, Carmen, and Bas. That's what I see used elsewhere too.

Great, thanks for the suggestions.

I have written up a draft document:

https://trac.osgeo.org/grass/wiki/HowToGit

Please expand, discuss, ...

Markus

53

Hi devs,
please stay tuned for re-enabled write access (for merging), we are
working on it.
We just have a lot on our plate here during the Berlin sprint (locals
and remote participants).

cheers,
Markus