dbaelde
commented
10 years ago After looking into init in Makefile.git, I have a few questions and suggestions.
The update --recursive has no effect since the submodule's submodules are not initialized. I suggest we use git submodule "update --init --recursive" instead of the three instructions "init"; "submodule update (useless --recursive"; "foreach submodule, init"; "submodule update --recursive" again.
I (still) do not understand the use of fetch in the (freshly cloned) liquidsoap-full repo, and in the freshly cloned submodules.
I tested the single command above (update --init --recursive) and as far as I can tell it gives me a working repo tree. However it will not be up-to-date: we should run make update after make init (even in its current version, so we should change either the doc or the init target).
Concerning make update, the first line surprises me: "checkout master" for liquidsoap-full is useless after the first clone, and insufficient for later updates, where a pull is needed.
By the way it's very annoying to have generated files such as src/outputs/harbor_output.ml in the repo, since they are easily modified (if one has a different version of camlp4) which prevents to checkout and change branch (git warns you about local changes that would be lost). I'm in favor of removing them, and asking cutting edge users to install camlp4 like us.
Hi,
It seems that git is changing its default policy wrt branch tracking. It is something that I found tricky in the past, hopefully it'll become simpler. For now we have to do something with Makefile.git: --set-upstream is deprecated but --set-upstream-to does not work on older versions of git. I know the set-upstream was helping us, but I don't remember when and how exactly, so I'm reluctant to remove this altogether.
By the way, my (recent) git asked me to choose on a policy for pushing and I went for the new default, which seems best to avoid bad surprises (here's the resulting line in my ~/.gitrc):