Since I don’t want to change any history in the subproject, to me the most 
expected behavior would be:

git submodule update —-recursive

with submodule.*.update set to the command:


branches=`git branch --points-at "$1"`

if [ ! $branches ] ; then
    git checkout "$1"
    echo "do normal checkout"
    for b in $branches ; do
        if [ "$b" = "master" ] ; then
    if [ points_to_master ] ; then
        git checkout master
        git checkout "$other_branch"

Now, this is not perfect and I’m sure I’ll refine it whenever I find it doesn’t
suit my needs, but I’m sure you can see the intentions here. I’m also not quite
sure whether to prioritize tags over branches or the other way around.

Thanks for the suggestion. I hope this or a similar behavior could sometime
become the default in git. Until the suggested quick fix will do for me.

Best Regards,
Alexander Hedges

> On 29 Aug 2016, at 04:17, Jacob Keller <> wrote:
> On Fri, Aug 26, 2016 at 8:12 AM, Hedges  Alexander
> <> wrote:
>>> On 25 Aug 2016, at 19:45, Stefan Beller <> wrote:
>>> [1]
>>> which has some attempts for checkout including the submodules.
>>> I also tried writing some patches which integrate checking out submodules
>>> via checkout as well. A quicker `solution` would be a config option that
>>> just runs `git submodule update` after each checkout/pull etc.
>> I see. The quick fix is almost what I’m looking for, except that it leaves
>> the repo in a detached head state. Could the submodule update be made
>> automatically and intelligently pick the branch?
> You probably want "git submodule update --rebase" or "git submodule
> update --merge" See git help submodule under the update section, or
> even a custom command variant where you can write your own bit of
> shell that does what your project expects.
> Thanks,
> Jake

Reply via email to