2014/1/7 Junio C Hamano <gits...@pobox.com>: > 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? >
Yep, you got it 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
