2014/1/8 W. Trevor King <wk...@tremily.us>: > Note that I've moved away from “submodule.<name>.branch > set means attached” towards “we should set per-superproject-branch > submodule.<name>.local-branch explicitly” [1]. >
Honestly, I'm having an hard time to follow this thread. Also, you didn't update the patch. If you were endorsed by someone (Junio, Heiko, ...) for the "submodule.<name>.local-branch" feature please show me where. I somehow understand the point of the "submodule.<name>.local-branch" property, but I can't "see" the the workflow. Please, show me some hypothetical scripting example with as much complete as possible workflow (creation, developer update, mantainers creates feature branch, developer update, developer attach to another branch). Also, consider I proposed to support the attached HEAD path to reduce complexity and support a simpler use case for git submodules. I would be disappointed if the complexity is reduced in a way and augmented in another. > On Wed, Jan 08, 2014 at 01:17:49AM +0100, Francesco Pretto wrote: >> # Attach the submodule HEAD to <branch>. >> # Also set ".git/config" 'submodule.<module>.branch' to <branch> >> $ git submodule head -b <branch> --attach <module> > [...] > I also prefer 'checkout' to 'head', because 'checkout' > already exists in non-submodule Git for switching between local > branches. > I can agree with similarity to other git commands, but 'checkout' does not give me the idea of something that writes to ".git/config" or ".gitmodules". >> # Attach the submodule HEAD to 'submodule.<module>.branch'. >> # If it does not exists defaults to <remote>/master >> $ git submodule head --attach <module> > > Defaulting to the configured local branch is fine, but I think it > should default to 'master' if no local branch is configured. This > should not have anything to do with remote-tracking branches (that's > what 'submodule update' already handles). I don't understand why > remote-tracking-branch integration keeps getting mixed up with > local-branch checkout. > Yep, it should default to "master", my fault. >> # Unset ".git/config" 'submodule.<module>.branch' >> # Also attach or detach the HEAD according to what is in ".gitmodules": >> # with Trevor's patch 'submodule.<module>.branch' set means attached, >> # unset means detached >> $ git submodule head --reset <module> > > To me this reads “always detach HEAD” (because it unsets > submodule.<name>.branch, and submodule.<name>.branch unset means > detached). I disagree: this would remove only the value in ".git/config". If the value is till present in ".gitmodules", as I wrote above, the behavior of what is in the index should be respected as for the other properties. Also it gives a nice meaning to a switch like --reset : return to how it was before. >> NOTE: feature branch part! >> >> # Set ".gitmodules" 'submodule.<module>.branch' to <branch> >> $ git submodule head -b <branch> --attach --index <module> >> >> # Unset ".gitmodules" 'submodule.<module>.branch' >> $ git submodule head --reset --index <module> >> --------------------------------------------------------------------- > > These are just manipulating .gitmodules. I think we also need > per-superproject-branch configs under the superproject's .git/ for > developer overrides. > I disagree: in my idea the --index switch is a maintainer only command to modify the behavior of the developers and touch only indexed files (.gitmodules, or create a new submodule branch). It expressly don't touch .git/config. -- 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
