On Wed, 25 May 2016 11:06:26 -0700 (PDT) Derell Licht <derell.li...@gmail.com> wrote:
[...] > I'm actually trying to solve a somewhat different issue, but cannot > figure out what is going wrong. > > I'm converting some projects at my company, from Subversion to Git. > Mostly all has been going well. > I used "git svn clone etc..." to generate a local "remote" repository > on my machine (which will later get pushed to our network server). > I then created a working directory and am cloning > projects/repositories one at a time into my working directory and > setting them up. One of the things that I want to do is created a > develop branch for each project, and do development on develop rather > than master. > > This is all working fine for the basic projects, but I'm having > troubles with submodules. The steps I follow are: > 1. git clone base project, checkout 'develop' branch, push to origin > 2. git clone submodule, checkout 'develop' branch, push to origin > 3. git submodule add -b develop origin/submodule submodule > 4. git commit, push > > Then I go back and check out my back project in a new directory, > using > --recursive, to see if everything is fine... > Well, main project is fine, but the submodules all show "detached > head", rather than showing develop branch as current branch. This is how submodules behave. And again, this is explained in the book [2]; to cite it: | So far, when we’ve run the git submodule update command to fetch | changes from the submodule repositories, Git would get the changes | and update the files in the subdirectory but will leave the | sub-repository in what’s called a “detached HEAD” state. This means | that there is no local working branch (like “master”, for example) | tracking changes. The basic idea is that submodules in Git (at least by default) work like Subversion externals which specify exact revisions (!). This is because the most often used pattern when working with submodules is to "pin" their revisions to particular states of the repository which depends on them. This is quite logical: if you depend on a library which is in flux, most of the time you want your project to depend on some know-good state of that library and that's why your project refers to specific commits of the submodules it uses. When you check out a specific commit you get to that "detached HEAD" state. When Git checks out a submodule, the same thing happens. > Further, if I view the project in SourceTree, it doesn't even let me > check out 'develop', though it shows it present on origin. > I am very confused by all this... On this, I know nothing as I've no idea what is SourceTree. Two questions: are you talking about the "develop" branch in a submodule or in a main repository? Does checking out work with plain Git? All in all, I think you should learn about some basics of what you trying to handle. You seem to not really have read much on submodules before embarking on a complicated task of converting a complex repository from a foreign SCM to Git. 2. https://git-scm.com/book/en/v2/Git-Tools-Submodules#working-on-a-submodule-agtpSas8C3 -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
