Hi Panos, all,
On Sat, May 18, 2019 at 5:59 PM Panagiotis Mavrogiorgos
<pmav99@gmail.com> wrote:
hello Markus,
I would suggest that:
- even core devs fork the main repo
- "origin" is the personal remote GRASS repository (e.g. in my case https://github.com/pmav99/grass)
- everyone adds the main GRASS repository as a secondary remote (e.g. "upstream")
yes, it sounds good to me (while my opinion only counts 0.02 cents here).
This way:
1. You always push to "origin" and you create a Pull Request from the Github UI
2. To get updates you always pull from "upstream"
3. You always rebase your code to "upstream/master".
4. You don't need separate instructions for non core-devs.
Updated in a similar way to
https://trac.osgeo.org/grass/wiki/HowToGit#Workflowforcoredevelopers
Just my 2 cents.
For fetching the updates, is this enough:
git pull --all
?
Thanks for your recommendations,
Markus
On Sat, 18 May 2019, 19:11 Markus Neteler, <neteler@osgeo.org> wrote:.
For fetching the updates, is this enough:
git pull --all
?
Μmm… sometimes yes, but I wouldn’t suggest it.
Git pull is essentially 2 operations in one. It is a git fetch, followed by a git merge.
The potential problem is with the merge step.
When you have no local changes, git pull works just fine. When you have local changes though, there might be a conflict with the remote ones. And if there is a conflict, you need to resolve it.
Resolving the conflicts is not something you can avoid; you will eventually have to do it, but you should probably not try to do it before you have reviewed the (remote) changes you just fetched.
This is why I almost always do this in 3 steps:
- git fetch --all
- Review the fetched changes. It’s often convenient to use a git client here. gitg, qgit and tig are easy to use and lightweight options.
- git merge
By injecting step 2 you can both check if there are any conflicts and think what’s the best way to resolve them. Moreover, if there are conflicts, you can choose to postpone resolving them (resolving conflicts takes time). If you do git pull you will have to resolve them straight away.
P.
On Sat, May 18, 2019 at 12:11 PM Markus Neteler <neteler@osgeo.org> wrote:
On Sat, May 18, 2019 at 5:59 PM Panagiotis Mavrogiorgos
<pmav99@gmail.com> wrote:
I would suggest that:
- even core devs fork the main repo
- “origin” is the personal remote GRASS repository (e.g. in my case https://github.com/pmav99/grass)
- everyone adds the main GRASS repository as a secondary remote (e.g. “upstream”)
yes, it sounds good to me (while my opinion only counts 0.02 cents here).
This way:
- You always push to “origin” and you create a Pull Request from the Github UI
- To get updates you always pull from “upstream”
- You always rebase your code to “upstream/master”.
- You don’t need separate instructions for non core-devs.
Updated in a similar way to
https://trac.osgeo.org/grass/wiki/HowToGit#Workflowforcoredevelopers
Hi, any opinions on what should be the primary and secondary remote? The the fork or upstream? As far as I understood, Bas is suggesting adding the fork, Panos adding the upstream. There does not seem to be that much difference, but the commands are different, so we need to decide for the instructions. GitHub help suggests cloning fork and adding upstream. Syncing to upstream seems more straight forward when cloning upstream and adding to the fork…
On Sun, May 19, 2019 at 5:24 PM Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Sat, May 18, 2019 at 12:11 PM Markus Neteler <neteler@osgeo.org> wrote:
On Sat, May 18, 2019 at 5:59 PM Panagiotis Mavrogiorgos
<pmav99@gmail.com> wrote:
I would suggest that:
- even core devs fork the main repo
- “origin” is the personal remote GRASS repository (e.g. in my case https://github.com/pmav99/grass)
- everyone adds the main GRASS repository as a secondary remote (e.g. “upstream”)
yes, it sounds good to me (while my opinion only counts 0.02 cents here).
This way:
- You always push to “origin” and you create a Pull Request from the Github UI
- To get updates you always pull from “upstream”
- You always rebase your code to “upstream/master”.
- You don’t need separate instructions for non core-devs.
Updated in a similar way to
https://trac.osgeo.org/grass/wiki/HowToGit#Workflowforcoredevelopers
Hi, any opinions on what should be the primary and secondary remote? The the fork or upstream? As far as I understood, Bas is suggesting adding the fork, Panos adding the upstream. There does not seem to be that much difference, but the commands are different, so we need to decide for the instructions. GitHub help suggests cloning fork and adding upstream. Syncing to upstream seems more straight forward when cloning upstream and adding to the fork…
GDAL [0] suggests to clone upstream, then add your own fork. For those who don’t have write access to upstream it does not matter IMHO. For those who do have write access to upstream, it might be safer to have origin refer to the personal fork. Ideally, you would set up the local repo such that you pull from upstream and push to your fork.
my 0.2c (trying to learn fast)
Markus M
[0] https://github.com/OSGeo/gdal/blob/master/CONTRIBUTING.md#initiate-your-work-repository
Hi,
ne 19. 5. 2019 v 17:43 odesílatel Markus Metz
<markus.metz.giswork@gmail.com> napsal:
For those who do have write access to upstream, it might be safer to have origin refer to the personal fork. Ideally, you would set up the local repo such that you pull from upstream and push to your fork.
+1 Ma
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
On Sun, May 19, 2019 at 5:53 PM Martin Landa <landa.martin@gmail.com> wrote:
ne 19. 5. 2019 v 17:43 odesílatel Markus Metz
<markus.metz.giswork@gmail.com> napsal:
> For those who do have write access to upstream, it might be safer to have origin refer to the personal fork. Ideally, you would set up the local repo such that you pull from upstream and push to your fork.
+1 Ma
+1 markusN
On Sun, May 19, 2019 at 6:53 PM Martin Landa <landa.martin@gmail.com> wrote:
Hi,
ne 19. 5. 2019 v 17:43 odesílatel Markus Metz
Ideally, you would set up the local repo such that you pull from upstream and push to your fork.
This is doable with: https://stackoverflow.com/a/4523625/592289
Nevertheless, occasionally, you might want to pull from your personal fork too. E.g. when you want to collaborate on a feature with others. One way to do this is to agree that the development will happen on a branch on your own fork. It doesn’t matter if you give write access to the other devs or if they make Pull Requests to your own fork, in the end you will have to pull those changes to your local repo. And in order to do that you will have to again edit your remotes.
For the record, in the above example the other devs would have to add your own personal repository as an additional remote.