I've matured this opinion about "local-branch" some days ago, but I
couldn't join the discussion because I was extremely busy. Hope it's
is still current (and correct).
2014/1/9 W. Trevor King <wking@xxxxxxxxxx>
>
> @@ -339,7 +339,19 @@ module_clone()
> echo "gitdir: $rel/$a" >"$sm_path/.git"
>
> rel=$(echo $a | sed -e 's|[^/][^/]*|..|g')
> - (clear_local_git_env; cd "$sm_path" && GIT_WORK_TREE=. git config core.worktree "$rel/$b")
> + superproject_branch=$(get_current_branch)
> + default_local_branch=$(get_submodule_config "$sm_name" local-branch)
> + (
> + clear_local_git_env
> + cd "$sm_path" &&
> + GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
> + local_branch=$(get_local_branch "${superproject_branch}" "${default_local_branch}") &&
> + # ash fails to wordsplit ${branch:+-b "$branch"...}
> + case "$branch" in
> + '') git checkout -f -q -B "$local_branch" ;;
> + ?*) git checkout -f -q -B "$local_branch" "origin/$branch" ;;
> + esac
> + ) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
> }
>
also
2014/1/8 W. Trevor King <wking@xxxxxxxxxx>:
> To elaborate the idea I sketched out here [2], say
> you want:
>
> Superproject branch Submodule branch Upstream branch
> =================== ================ ===============
> master master master
> super-feature master master
> my-feature my-feature master
> other-feature other-feature other-feature
>
> That's only going to work with per-superproject-branch configs for
> both the local and remote branches. Using the same name for both
> local and remote branches does not work.
>
> Let me motivate each of the combinations in the above table:
>
> * master, master, master: The stable trunk.
> * super-feature, master, master: A superproject feature that works
> with the stock submodule.
> * my-feature, my-feature, master: A superproject feature that needs an
> improved submodule, but wants to integrate upstream master changes
> during development.
> * other-feature, other-feature, other-feature: A superproject feature
> that needs an improved submodule, and wants to integrate
> other-feature changes that are also being developed upstream
The "local-branch" feature means to my brain the following: I,
maintainer, decide for you, developer, what name should be the branch
you are checking out. While, in general, it makes sense for a
developer to switch to a differently named "feature branch" that can
pull the original remote branch if he's actively developing (on any
repository, not only a submodule), this leads me to the following
questions: would it be good to introduce such enforcement? Do we allow
something similar on regular repositories? In short I believe this
workflow may reflect a personal attitude. In that case I'm unsure if
git should ease it so specifically.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html