I’m completely lost…
Dear Vero,
As others have suggested, you pulled changes from upstream into your local repo and you now need to push them to your personal fork (i.e. you need to push then to origin).
git is more powerful than subversion, but this power comes with increased complexity. You can’t use git thinking it is subversion. In order to become effective you need to understand the new concepts. Learning about them is obviously not trivial but it is not that hard either. It just takes a little bit of reading and some practise.
In case you are interested, I have heard good words about this tutorial: https://learngitbranching.js.org/
Do take note that it has two sections: main and remote. The first one will teach you about working with your local repo (rebasing etc) and the other about working with remotes.
It there a way (magic flag?) to avoid this out-of-sync in the first place?
E.g., for the cronjobs I do not want to go there weekly and "git push"
stuff around.
Yes, but we need to know the contents of the cron scripts first.
all the best,
P.
On Sun, Jun 2, 2019 at 10:52 PM Panagiotis Mavrogiorgos
<pmav99@gmail.com> wrote:
...
Markus wrote:
It there a way (magic flag?) to avoid this out-of-sync in the first place?
E.g., for the cronjobs I do not want to go there weekly and "git push"
stuff around.
Yes, but we need to know the contents of the cron scripts first.
It simply follows the HowToGit on trac which leads to the mentioned problem.
What I am searching for is that the disk copy is the same as on the
server. As it is a cronjob there will be no local changes. Still, some
push magic seems to me missing from
https://trac.osgeo.org/grass/wiki/HowToGit#Keepyourlocalsourcecodeuptodate
thanks,
Markus
On Sun, Jun 2, 2019 at 5:12 PM Markus Neteler <neteler@osgeo.org> wrote:
On Sun, Jun 2, 2019 at 10:52 PM Panagiotis Mavrogiorgos
<pmav99@gmail.com> wrote:
…
Markus wrote:
It there a way (magic flag?) to avoid this out-of-sync in the first place?
E.g., for the cronjobs I do not want to go there weekly and “git push”
stuff around.
Yes, but we need to know the contents of the cron scripts first.
It simply follows the HowToGit on trac which leads to the mentioned problem.
What I am searching for is that the disk copy is the same as on the
server. As it is a cronjob there will be no local changes. Still, some
push magic seems to me missing from
https://trac.osgeo.org/grass/wiki/HowToGit#Keepyourlocalsourcecodeuptodate
That might be the root of the problem. What you are linking is for cases when you have a fork and you are making local changes (it is under Contributing guidelines after all). It is hard to guess what is the specific problem here without seeing the script, but a simple git pull or something close to that should be sufficient just to update a copy for build. Perhaps the only single case when using Git is like using Subversion… (let’s see if that turns to be true! 
The cron script should be probably part of grass-maintenance repo…
On Sun, Jun 2, 2019 at 11:12 PM Markus Neteler <neteler@osgeo.org> wrote:
On Sun, Jun 2, 2019 at 10:52 PM Panagiotis Mavrogiorgos
<pmav99@gmail.com> wrote:
…
Markus wrote:
It there a way (magic flag?) to avoid this out-of-sync in the first place?
E.g., for the cronjobs I do not want to go there weekly and “git push”
stuff around.
Yes, but we need to know the contents of the cron scripts first.
It simply follows the HowToGit on trac which leads to the mentioned problem.
What I am searching for is that the disk copy is the same as on the
server.
Which version on the server? The orginal GRASS repo (https://github.com/OSGeo/grass.git) or a fork? If the aim is to have an unmodified local copy that is in sync with the original GRASS repo, you don’t need any other remote and it should be enough to pull.
As it is a cronjob there will be no local changes. Still, some
push magic seems to me missing from
https://trac.osgeo.org/grass/wiki/HowToGit#Keepyourlocalsourcecodeuptodate
In this case (have a local copy in sync with https://github.com/OSGeo/grass.git) push is not needed (no modifications and no fork added as another remote).
Works ar t least for me.
Markus M
thanks,
Markus
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
(... I am continuing to talk about grass.osgeo.org here)
On Mon, Jun 3, 2019 at 8:49 AM Markus Metz
<markus.metz.giswork@gmail.com> wrote:
On Sun, Jun 2, 2019 at 11:12 PM Markus Neteler <neteler@osgeo.org> wrote:
...
> What I am searching for is that the disk copy is the same as on the
> server.
Which version on the server? The orginal GRASS repo (https://github.com/OSGeo/grass.git) or a fork?
I have now cloned separately for `master` and `releasebranch_7_6` /
`releasebranch_7_4` since they are also used to compile the code for
online manual creation etc.
I am getting closer...
The version I (have to) use there as it is an ancient Debian box:
neteler@osgeo6:~/cronjobs$ git --version
git version 2.1.4
It seems that it works with
git fetch --all --prune || halt_on_error "git fetch error!"
git pull
If the aim is to have an unmodified local copy that is in sync with the original GRASS repo, you don't need any other remote and it should be enough to pull.
ok, so the "git fetch" step above is not needed (in this case of only
cloning without local changes as it is the server!)
?
thanks,
markusN