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:
```
#!/bin/bash
branches=`git branch --points-at "$1"`
if [ ! $branches ] ; then
git checkout "$1"
echo "do normal checkout"
else
points_to_master=
other_branch=
for b in $branches ; do
if [ "$b" = "master" ] ; then
points_to_master="true"
else
other_branch="$b"
fi
done
if [ points_to_master ] ; then
git checkout master
else
git checkout "$other_branch"
fi
fi
```
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 <jacob.keller@xxxxxxxxx> wrote:
>
> On Fri, Aug 26, 2016 at 8:12 AM, Hedges Alexander
> <ahedges@xxxxxxxxxxxxxxx> wrote:
>>> On 25 Aug 2016, at 19:45, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
>>> [1] https://github.com/jlehmann/git-submod-enhancements
>>> 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