03-04-2017, 10:04 PM
One step at a time. there are a lot of little concepts to learn and small hurdles to jump over. be patient you'll get there and I will personally help you all the way. In fact, do not hesitate at all to contact me directly for help, you have my email and I am very easy to find on hangouts and gitter (where I invite you to join: https://gitter.im/corebos/discuss). I owe you that much at least !!
Now, to answer you question. "git pull" = "git fetch" + "git merge", so it isn't the same. Let me try to explain that. When you download a copy of coreBOS with "git clone" you get all the code in the state it is at that moment and ALL the history of changes that it has gone through. That historical information is saved in the .git directory. Now suppose we keep developing and a week goes by. Now your code is not up to date with the latest changes, so you have to launch "git fetch", that will bring into the history all the changes since you downloaded the code (or launched your last "fetch"). The "git fetch" command only updates the history, it does not update your code. So you could study each of the changes before applying them to your code. Mostly, we all just apply them, which is done by executing the "git merge" command. "git merge" will look in the history and apply any changes that are there that haven't been applied to your code. So every time you want to update your code you have to launch "git fetch" and "git merge". This is so common, and we do it so often that they have added a short cut for us: "git pull" = "git fetch" + "git merge".
In the end you can actually forget about all that and just always do a "git pull", that is what you need.
One last comment. Note that git will update your code, but it has no idea about your database. If that new code needs a new field to do some magic, that field will NOT be created by the code update. In fact, that code will break because it will look for the field and it won't find it. This is where coreBOS updater comes in. coreBOS updater is capable of analyzing the state of your code and compare it with the state of the database and apply any changes that are missing. It sounds like magic,.... and it is :-)
Finally, the error you are running into is most probably all about file permissions. It turns out that git controls the attributes of the files also, not just their contents. That means that if I set a file to have permission 664, and you have it set to 644, git sees that as a change and won't apply the update, even if the file contents hasn't changed at all. The easiest way around this is to deactivate the file permission/attribute control:
git config --global core.fileMode false
http://stackoverflow.com/questions/1580596/how-do-i-make-git-ignore-file-mode-chmod-changes
git status will show you a list of changed files, try that before and after the fileMode false command and you should see the difference.
Let me know how it goes.
Now, to answer you question. "git pull" = "git fetch" + "git merge", so it isn't the same. Let me try to explain that. When you download a copy of coreBOS with "git clone" you get all the code in the state it is at that moment and ALL the history of changes that it has gone through. That historical information is saved in the .git directory. Now suppose we keep developing and a week goes by. Now your code is not up to date with the latest changes, so you have to launch "git fetch", that will bring into the history all the changes since you downloaded the code (or launched your last "fetch"). The "git fetch" command only updates the history, it does not update your code. So you could study each of the changes before applying them to your code. Mostly, we all just apply them, which is done by executing the "git merge" command. "git merge" will look in the history and apply any changes that are there that haven't been applied to your code. So every time you want to update your code you have to launch "git fetch" and "git merge". This is so common, and we do it so often that they have added a short cut for us: "git pull" = "git fetch" + "git merge".
In the end you can actually forget about all that and just always do a "git pull", that is what you need.
One last comment. Note that git will update your code, but it has no idea about your database. If that new code needs a new field to do some magic, that field will NOT be created by the code update. In fact, that code will break because it will look for the field and it won't find it. This is where coreBOS updater comes in. coreBOS updater is capable of analyzing the state of your code and compare it with the state of the database and apply any changes that are missing. It sounds like magic,.... and it is :-)
Finally, the error you are running into is most probably all about file permissions. It turns out that git controls the attributes of the files also, not just their contents. That means that if I set a file to have permission 664, and you have it set to 644, git sees that as a change and won't apply the update, even if the file contents hasn't changed at all. The easiest way around this is to deactivate the file permission/attribute control:
git config --global core.fileMode false
http://stackoverflow.com/questions/1580596/how-do-i-make-git-ignore-file-mode-chmod-changes
git status will show you a list of changed files, try that before and after the fileMode false command and you should see the difference.
Let me know how it goes.
Joe
TSolucio
TSolucio