On Blender wiki it says to update one’s local repository with the commands :
git pull --rebase
git submodule foreach --recursive git pull --rebase origin master
This however only updates the current checkout branch - if it has tracking information. I actually think I want this behavior because I want to control what specific branches get updated and rebased - plus I don’t want to redownload origin master for each branch. So what I would like to do is
--rebase certain of my local branches using my local master branch as the base. What I think should be done is:
git rebase master
git submodule foreach --recursive git rebase master
Is the above the right way to rebase my local branches upon my local master(it seems to work) ?
Warning: I am very noobish when it comes to git, so what I may suggest here could be wrong. But until you get a better answer the following may help
It seems to me that your scenario fits the second answer here
git checkout local_branch
git rebase master
git checkout master
git merge local_branch
although this may work too
git checkout master
git rebase local_branch
Frankly I am perplexed by rebase and git in general because I develop my own project in my own local branch, using git pull origin master or make update which does a git pull --rebase has resulted in tons upon tons of conflicts, none of which had to do anything with my code , mainly because my source code is in separate files.
What have saved me is GitLens , this is a extension for Visual Studio Code IDE, it basically allows me to compare my branch with origin master and in case of crazy conflicts to pin point exactly what I need to merge and why. It helps me to make sure my code is up to date compare to origin master and I have not done something really stupid. It also can show in the code editor merge conflicts and allow me to choose which to accept for merging. Its a very convenient and powerful tool for git. Cannot recommend it enough. Thus I personally use only git pull and I keep my code in my own local branch not touching ever the other branches including master. I also the hate command line (even though I started with command line coding ages ago ) so using GitLens GUI is a big relief
PS: From the little I understand git rebase looks to me a recipe for a disaster because it messes with git history , unlike merge, even Linus (creator of Linux and Git) advises extreme caution. So I will never rebase my own code even though my repo is for my eyes only. I prefer to keep my history simple and predictable.
Shouldn’t the sub-git repositories get updated too? Don’t I have to use
git submodule foreach --recursive git rebase master to update them?
Also, that was a very nice link for rebasing. Very informative. Thanks.
yes its similar story for the submodules, the difference is that active development happens mainly on the master branch of blender.git , when your focus is the actual Blender source code. Technically speaking for example addon contrib are not part of the Blender source because they are not distributed with the release. Merging a main repo branch generally speaking should not affect the sub modules, I will dare an assumption here that most branches depend on submodules’ master branches anyway.
But yeah its better be safe than sorry. One thing to note however is that technically even though they are called “Submodules” their history is independent to what is stored in the history of the main repo, again from the little I understand is the history of the local branch will associate a commit of the respective id of the latest commit of each submodule. Similarly to a Desktop shortcut. So the histories are independent but linked.
Thus I do not think it makes sense to rebase a branch of a submodule to the branch of your the main repo because they are two different things and their code suppose to be separate that’s the whole point of being submodules afterall. A submodule is regular git repo, so there is no extra surprises there.
Once again I have not messed much with submodules so I will have refer you again to git documentation.
In my case I decided not to mess with the submodules at all and instead my addons are in the subfolder of the folder I have the C code (my project is a mix of C code and an addon , plus extra python library modules) , I have made my own build script to copy those files to my release/debug build folder (together or separately from the build command, in my case that makes sense because I have a special build system that minimizes the need to rebuild Blender when I change my code) . This way I have to worry about one history alone, that of my branch. Generally I tried not mess with existing repos/ branches to minimise the possibility of conflicts, but alas, I am not that lucky and definetly not that experienced :D. I also like that my entire project is one folder instead of all over the place with of course sub folders to keep things organised and clean. Of course in my case I am lucky that the nature of my projects allows me to avoid modifying existing blender source code files to a large degree.
I drop my case as an example if you are in a similar situation where you develop a project that is a mix of C and Python.