Francesco Pretto <cez...@gmail.com> writes: > My bottom line: > - For what I understand, detached HEAD it's a way to say "hey, you > have to stay on this commit. Also don't even think you can push to the > upstream branch". This sometimes can't be spurious, as in the use case > I wrote above: access control on the remote repositories should be > enough. I think maintainers should have the option to make developers > to clone a repository starting with an attached HEAD on the branch > suggested in submodule.$name.branch; > - "git submodule update" is missing a property to do automatically > "--remote". I think in the use case I wrote it's really handy to have > a "git submodule update" to act like this.
The short version I read in the message is that your workflow, in which partipants want to work on a branch, gets frustrating with the current system only because the default update/initial cloning detaches HEAD and will stay in that state until the user gets out of the detached state manually. Once that initial detachment is fixed, there is no more major issue, as update will stay on that branch. Am I reading you correctly? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
