patch, 2 partsgit-submodule.sh: Support 'checkout' as a valid update command

> At the current state, the following use-case is not supported very
> well in git:
> - a maintainer adds a submodule, checking out a specific branch of
> the repository. He doesn't track the upstream submodule revision sha1;
> - a developer checkout the repository branch decided by the maintainer.
> Subsequent "merge" or "rebase" update operations don't detach the HEAD.
>
> To ease the above use-case this patch:
> - introduces a "submodule.<module>.attached" property that, when set
>   to "true", ensures that the "update" operation will result in
>   the HEAD attached to a branch;
> - introduces "--attach|--dettach" switches to the submodule "update"
>   command: they attach/detach the HEAD, overriding
>   "submodule.<module>.attached" property value;
> - introduces "--attached-update" switch to the "add" operation. It:
>     * sets "submodule.<module>.attached" to true;
>     * sets "submodule.<module>.ignore" to all.
>
> Using the '--attach' switch or operating in a repository with
> 'submodule.<name>.attached' set to 'true' during "update" will:
> - checkout a branch with an attached HEAD if the repository was just
> cloned;
> - perform a fast-forward only merge of changes if it's a 'checkout'
> update operation;
> - reattach the HEAD prior performing a 'merge', 'rebase' or '!command'
> update operation if the HEAD was found detached. Orphaned commits
> will also be merged back in the branch.
>
> '--attach' or 'submodule.<name>.attached' set to true also implies '--remote'.
>
> Using  the '--detach' switch or operating in a repository with
> 'submodule.<name>.attached' set to 'false' during "update" will:
> - checkout a detached HEAD if the repository was just cloned;
> - detach the HEAD prior performing a 'merge', 'rebase' or '!command'
> update operation if the HEAD was found attached.
>
> 'submodule.<name>.attached' works similarly to 'submodule.<name>.update'
> property: git copies the values found in ".gitmodules" in ".git/config" when
> performing an "init" command. "update" looks for values in ".git/config"
> only.
>
> '--attach' and '--detach' switches override an opposite behaviour
> of 'submodule.<name>.attached' properties.
>
> The patch is strongly additive and doesn't break any submodule specific
> test. It also adds some tests specific to the added feature.
> ---
>  Documentation/git-submodule.txt    |  48 +++++--
>  Documentation/gitmodules.txt       |  10 +-
>  git-submodule.sh                   | 154 +++++++++++++++++++--
>  t/t7410-submodule-attached-head.sh | 268 +++++++++++++++++++++++++++++++++++++
>  4 files changed, 457 insertions(+), 23 deletions(-)
>  create mode 100755 t/t7410-submodule-attached-head.sh
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index bfef8a0..b97eefb 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -10,13 +10,14 @@ SYNOPSIS
>  --------
>  [verse]
>  'git submodule' [--quiet] add [-b <branch>] [-f|--force] [--name <name>]
> -             [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]
> +             [--reference <repository>] [--attached-update] [--depth <depth>]
> +             [--] <repository> [<path>]
>  'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
>  'git submodule' [--quiet] init [--] [<path>...]
>  'git submodule' [--quiet] deinit [-f|--force] [--] <path>...
>  'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
> -             [-f|--force] [--rebase] [--reference <repository>] [--depth <depth>]
> -             [--merge] [--recursive] [--] [<path>...]
> +             [-f|--force] [--rebase] [--reference <repository>] [--attach | --detach]
> +             [--depth <depth>] [--merge] [--recursive] [--] [<path>...]
>  'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
>               [commit] [--] [<path>...]
>  'git submodule' [--quiet] foreach [--recursive] <command>
> @@ -107,6 +108,9 @@ is the superproject and submodule repositories will be kept
>  together in the same relative location, and only the
>  superproject's URL needs to be provided: git-submodule will correctly
>  locate the submodule using the relative URL in .gitmodules.
> ++
> +If `--attached-update` is specified, the property `submodule.<name>.attached`
> +will be set to `true` and `submodule.<name>.ignore` will be set to `all`.
>
>  status::
>         Show the status of the submodules. This will print the SHA-1 of the
> @@ -156,12 +160,15 @@ it contains local modifications.
>  update::
>         Update the registered submodules, i.e. clone missing submodules and
>         checkout the commit specified in the index of the containing repository.
> -       This will make the submodules HEAD be detached unless `--rebase` or
> -       `--merge` is specified or the key `submodule.$name.update` is set to
> -       `rebase`, `merge` or `none`. `none` can be overridden by specifying
> -       `--checkout`. Setting the key `submodule.$name.update` to `!command`
> -       will cause `command` to be run. `command` can be any arbitrary shell
> -       command that takes a single argument, namely the sha1 to update to.
> +       This will make the submodules HEAD be detached unless `--attach` is
> +       specified or `submodule.$name.attached` is set to `true`. The last setting
> +       can always be overridden specifying `--detach`. Update mode can be
> +       selected specifying `--checkout`, `--rebase` or `--merge` switches
> +       or setting the key `submodule.$name.update` to `checkout`, `rebase`,
> +       `merge` or `none`. `none` will cause the submodule to be skipped during
> +       the update. Setting the key `submodule.$name.update` to `!command` will
> +       cause `command` to be run. `command` can be any arbitrary shell command
> +       that takes a single argument, namely the sha1 to update to.
>  +
>  If the submodule is not yet initialized, and you just want to use the
>  setting as stored in .gitmodules, you can automatically initialize the
> @@ -270,6 +277,23 @@ OPTIONS
>         be overridden by setting the `submodule.<name>.branch` option in
>         either `.gitmodules` or `.git/config` (with `.git/config` taking
>         precedence).
> +
> +--attached-update::
> +       This option is only valid for the add command. Causes the add command
> +       also to set the property `submodule.<name>.attached` to `true` and
> +       the property `submodule.<name>.ignore` to `all`.
> +
> +--attach::
> +       This option is only valid for the update commands. Causes the result
> +       of an update operation to be an attached HEAD. In the update operation,
> +       the branch named by 'submodule.<name>.branch' is checked out as the new
> +       HEAD of the submodule repository. If 'submodule.<name>.branch' is not
> +       set, the 'master' branch is checked out as the new HEAD of the
> +       submodule. Note: `--attach` also implies `--remote`.
> +
> +--detach::
> +       This option is only valid for the update command. Forces the result
> +       of the update operation to be a detached HEAD in the submodule.
>  +
>  This works for any of the supported update procedures (`--checkout`,
>  `--rebase`, etc.).  The only change is the source of the target SHA-1.
> @@ -290,8 +314,7 @@ SHA-1.  If you don't want to fetch, you should use `submodule update
>  --merge::
>         This option is only valid for the update command.
>         Merge the commit recorded in the superproject into the current branch
> -       of the submodule. If this option is given, the submodule's HEAD will
> -       not be detached. If a merge failure prevents this process, you will
> +       of the submodule. If a merge failure prevents this process, you will
>         have to resolve the resulting conflicts within the submodule with the
>         usual conflict resolution tools.
>         If the key `submodule.$name.update` is set to `merge`, this option is
> @@ -300,8 +323,7 @@ SHA-1.  If you don't want to fetch, you should use `submodule update
>  --rebase::
>         This option is only valid for the update command.
>         Rebase the current branch onto the commit recorded in the
> -       superproject. If this option is given, the submodule's HEAD will not
> -       be detached. If a merge failure prevents this process, you will have
> +       superproject. If a merge failure prevents this process, you will have
>         to resolve these failures with linkgit:git-rebase[1].
>         If the key `submodule.$name.update` is set to `rebase`, this option is
>         implicit.
> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
> index f7be93f..9c436db 100644
> --- a/Documentation/gitmodules.txt
> +++ b/Documentation/gitmodules.txt
> @@ -38,7 +38,8 @@ submodule.<name>.url::
>  submodule.<name>.update::
>         Defines what to do when the submodule is updated by the superproject.
>         If 'checkout' (the default), the new commit specified in the
> -       superproject will be checked out in the submodule on a detached HEAD.
> +       superproject (or branch, with '--attach') will be checked out in
> +       the submodule.
>         If 'rebase', the current branch of the submodule will be rebased onto
>         the commit specified in the superproject. If 'merge', the commit
>         specified in the superproject will be merged into the current branch
> @@ -54,6 +55,13 @@ submodule.<name>.branch::
>         If the option is not specified, it defaults to 'master'.  See the
>         `--remote` documentation in linkgit:git-submodule[1] for details.
>
> +submodule.<name>.attached::
> +       Determine if the update operation will produce a detached HEAD or not.
> +       Valid values are `true` or `false`. If the property is set to `true`
> +       and `submodule.<name>.branch` is not set, the branch `master` will
> +       be checked out. If `submodule.<name>.branch` is set the branch
> +       specified will be checked out instead.
> +
>  submodule.<name>.fetchRecurseSubmodules::
>         This option can be used to control recursive fetching of this
>         submodule. If this option is also present in the submodules entry in
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 1d041a7..bc6df2b 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -5,11 +5,11 @@
>  # Copyright (c) 2007 Lars Hjemli
>
>  dashless=$(basename "$0" | sed -e 's/-/ /')
> -USAGE="[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
> +USAGE="[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--attached-update] [--] <repository> [<path>]
>     or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
>     or: $dashless [--quiet] init [--] [<path>...]
>     or: $dashless [--quiet] deinit [-f|--force] [--] <path>...
> -   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
> +   or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--attach | --detach] [--merge] [--recursive] [--] [<path>...]
>     or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
>     or: $dashless [--quiet] foreach [--recursive] <command>
>     or: $dashless [--quiet] sync [--recursive] [--] [<path>...]"
> @@ -36,6 +36,9 @@ update=
>  prefix=
>  custom_name=
>  depth=
> +attach=
> +detach=
> +attached_update=
>
>  # The function takes at most 2 arguments. The first argument is the
>  # URL that navigates to the submodule origin repo. When relative, this URL
> @@ -352,6 +355,9 @@ cmd_add()
>                         custom_name=$2
>                         shift
>                         ;;
> +               --attached-update)
> +                       attached_update=yes
> +                       ;;
>                 --depth)
>                         case "$2" in '') usage ;; esac
>                         depth="--depth=$2"
> @@ -491,6 +497,12 @@ Use -f if you really want to add it." >&2
>         then
>                 git config -f .gitmodules submodule."$sm_name".branch "$branch"
>         fi &&
> +       if test -n "$attached_update"
> +       then
> +               # We'll stay stick to the HEAD, no need to track revision sha1
> +               git config -f .gitmodules submodule."$sm_name".attached "true"
> +               git config -f .gitmodules submodule."$sm_name".ignore "all"
> +       fi &&
>         git add --force .gitmodules ||
>         die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
>  }
> @@ -632,6 +644,22 @@ cmd_init()
>                         git config submodule."$name".update "$upd" ||
>                         die "$(eval_gettext "Failed to register update mode for submodule path '\$displaypath'")"
>                 fi
> +
> +               # Copy "attached" setting when it is not set yet
> +               if attached="$(git config -f .gitmodules submodule."$name".attached)" &&
> +                  test -n "$attached" &&
> +                  test -z "$(git config submodule."$name".attached)"
> +               then
> +                       case "$attached" in
> +                       true | false)
> +                               ;; # Valid attach flag values
> +                       *)
> +                               echo >&2 "warning: invalid attach flag value for submodule '$name'"
> +                               ;;
> +                       esac
> +                       git config submodule."$name".attached "$attached" ||
> +                       die "$(eval_gettext "Failed to register attach option for submodule path '\$displaypath'")"
> +               fi
>         done
>  }
>
> @@ -750,6 +778,14 @@ cmd_update()
>                 --reference=*)
>                         reference="$1"
>                         ;;
> +               --attach)
> +                       if test -n "$detach" ; then usage ; fi
> +                       attach=1
> +                       ;;
> +               --detach)
> +                       if test -n "$attach" ; then usage ; fi
> +                       detach=1
> +                       ;;
>                 -m|--merge)
>                         update="merge"
>                         ;;
> @@ -800,6 +836,28 @@ cmd_update()
>                 name=$(module_name "$sm_path") || exit
>                 url=$(git config submodule."$name".url)
>                 branch=$(get_submodule_config "$name" branch master)
> +               attach_module=
> +               detach_module=
> +               if test -n "$attach" -o -n "$detach"
> +               then
> +                       attach_module=$attach
> +                       detach_module=$detach
> +               else
> +                       attached=$(git config submodule."$name".attached)
> +                       case "$attached" in
> +                       '')
> +                               ;; # Unset attach flag
> +                       true)
> +                               attach_module=1
> +                               ;;
> +                       false)
> +                               detach_module=1
> +                               ;;
> +                       *)
> +                               echo >&2 "warning: invalid attach flag value for submodule '$name'"
> +                               ;;
> +                       esac
> +               fi
>                 if ! test -z "$update"
>                 then
>                         update_module=$update
> @@ -848,7 +906,16 @@ Maybe you want to use 'update --init'?")"
>                         die "$(eval_gettext "Unable to find current revision in submodule path '\$displaypath'")"
>                 fi
>
> -               if test -n "$remote"
> +               head_rev_ref=$(clear_local_git_env; cd "$sm_path" && git rev-parse --abbrev-ref HEAD) ||
> +               die "$(eval_gettext "Unable to determine revision ref in submodule path '\$sm_path'")"
> +               head_detached=
> +               if test "$head_rev_ref" = "HEAD"
> +               then
> +                       # Determine if the HEAD is detached
> +                       head_detached="true"
> +               fi
> +
> +               if test -n "$remote" -o -n "$attach_module"
>                 then
>                         if test -z "$nofetch"
>                         then
> @@ -862,7 +929,8 @@ Maybe you want to use 'update --init'?")"
>                         die "$(eval_gettext "Unable to find current ${remote_name}/${branch} revision in submodule path '\$sm_path'")"
>                 fi
>
> -               if test "$subsha1" != "$sha1" -o -n "$force"
> +               if test "$subsha1" != "$sha1" || test -n "$attach_module" -a -n "$head_detached" ||
> +                       test -n "$detach_module" -a -z "$head_detached" || test -n "$force"
>                 then
>                         subforce=$force
>                         # If we don't already have a -f flag and the submodule has never been checked out
> @@ -882,40 +950,108 @@ Maybe you want to use 'update --init'?")"
>                         fi
>
>                         # Is this something we just cloned?
> +                       just_cloned=
>                         case ";$cloned_modules;" in
>                         *";$name;"*)
>                                 # then there is no local change to integrate
> -                               update_module= ;;
> +                               update_module="checkout"
> +                               just_cloned=yes
> +                               ;;
>                         esac
>
> +                       if test -z "$update_module"
> +                       then
> +                               # Fallback to checkout
> +                               update_module="checkout"
> +                       fi
> +
> +                       command_attach=:
> +                       suffix_attach=
> +                       if test "$update_module" != "checkout"
> +                       then
> +                               if test -n "$attach_module" -a -n "$head_detached"
> +                               then
> +                                       # We need to reattach to the branch
> +                                       command_attach="git checkout $subforce -q"
> +                                       suffix_attach=$branch
> +                               elif test -n "$detach_module" -a -z "$head_detached"
> +                               then
> +                                       # We need to detach from the branch
> +                                       command_attach="git checkout $subforce -q"
> +                                       suffix_attach=$sha1
> +                               fi
> +                       fi
> +
> +                       command_pre=:
> +                       suffix_pre=
> +                       command_post=:
> +                       suffix_pre=
> +                       suffix=
>                         must_die_on_failure=
> +                       custom_update=
>                         case "$update_module" in
>                         rebase)
>                                 command="git rebase"
> +                               suffix=$sha1
>                                 die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$displaypath'")"
>                                 say_msg="$(eval_gettext "Submodule path '\$displaypath': rebased into '\$sha1'")"
>                                 must_die_on_failure=yes
> +                               if test -n "$attach_module" -a -n "$head_detached" && test "$subsha1" != "$sha1"
> +                               then
> +                                       # After the rebase, we merge orphaned commits in the branch
> +                                       command_post="git merge"
> +                                       suffix_post=$subsha1
> +                               fi
>                                 ;;
>                         merge)
> +                               if test -n "$attach_module" -a -n "$head_detached" && test "$subsha1" != "$sha1"
> +                               then
> +                                       # Prior the rebase, we merge orphaned commits in in the branch
> +                                       command_pre="git merge"
> +                                       suffix_pre=$subsha1
> +                               fi
>                                 command="git merge"
> +                               suffix=$sha1
>                                 die_msg="$(eval_gettext "Unable to merge '\$sha1' in submodule path '\$displaypath'")"
>                                 say_msg="$(eval_gettext "Submodule path '\$displaypath': merged in '\$sha1'")"
>                                 must_die_on_failure=yes
>                                 ;;
> +                       checkout)
> +                               if test -n "$attach_module"
> +                               then
> +                                       command="git checkout $subforce -q"
> +                                       suffix=$branch
> +                                       die_msg="$(eval_gettext "Unable to checkout banch '\$branch' in submodule path '\$displaypath'")"
> +                                       say_msg="$(eval_gettext "Submodule path '\$displaypath': checked out branch '\$branch'")"
> +                                       if test -z "$just_cloned" -a && test "$subsha1" != "$sha1"
> +                                       then
> +                                               # Perform a fast-forward only merge of the origin
> +                                               command_post="git merge $subforce --ff-only"
> +                                               suffix_post="origin/$branch"
> +                                       fi
> +                               else
> +                                       command="git checkout $subforce -q"
> +                                       suffix=$sha1
> +                                       die_msg="$(eval_gettext "Unable to checkout '\$sha1' in submodule path '\$displaypath'")"
> +                                       say_msg="$(eval_gettext "Submodule path '\$displaypath': checked out '\$sha1'")"
> +                               fi
> +                               ;;
>                         !*)
>                                 command="${update_module#!}"
> +                               suffix=$sha1
>                                 die_msg="$(eval_gettext "Execution of '\$command \$sha1' failed in submodule  path '\$prefix\$sm_path'")"
>                                 say_msg="$(eval_gettext "Submodule path '\$prefix\$sm_path': '\$command \$sha1'")"
>                                 must_die_on_failure=yes
> +                               custom_update=yes
>                                 ;;
>                         *)
> -                               command="git checkout $subforce -q"
> -                               die_msg="$(eval_gettext "Unable to checkout '\$sha1' in submodule path '\$displaypath'")"
> -                               say_msg="$(eval_gettext "Submodule path '\$displaypath': checked out '\$sha1'")"
> +                               # Valid user configurable update modes are already filtered above
> +                               die "$(eval_gettext "Unexpected update mode in the current flow")"
>                                 ;;
>                         esac
>
> -                       if (clear_local_git_env; cd "$sm_path" && $command "$sha1")
> +                       if (clear_local_git_env; cd "$sm_path" && $command_attach "$suffix_attach" &&
> +                               $command_pre "$suffix_pre" && $command "$suffix" && $command_post "$suffix_pro")
>                         then
>                                 say "$say_msg"
>                         elif test -n "$must_die_on_failure"
> diff --git a/t/t7410-submodule-attached-head.sh b/t/t7410-submodule-attached-head.sh
> new file mode 100755
> index 0000000..04b3018
> --- /dev/null
> +++ b/t/t7410-submodule-attached-head.sh
> @@ -0,0 +1,268 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2014 Francesco Pretto
> +#
> +
> +test_description='Support for submodules with attached head
> +
> +This test verifies the sanity of the add and update git submodule commands with
> +or without the --attached-update, --attach, --detach switches or the
> +submoudule.<module>.attach property set
> +'
> +
> +TEST_NO_CREATE_REPO=true
> +. ./test-lib.sh
> +
> +submodurl1=$(pwd -P)/repo1
> +submodurl2=$(pwd -P)/repo2
> +repourl=$(pwd -P)/repo
> +
> +test_expect_success 'setup - create repository "repo1" to be used as submodule' '
> +       mkdir repo1 &&
> +       (
> +               cd repo1 &&
> +               git init &&
> +               git config receive.denyCurrentBranch ignore &&
> +               echo a >a &&
> +               git add a &&
> +               git commit -m "repo1 commit 1"
> +       )
> +'
> +
> +test_expect_success 'setup - reate repository "repo2" to be used as submodule' '
> +       mkdir repo2 &&
> +       (
> +               cd repo2 &&
> +               git init &&
> +               git config receive.denyCurrentBranch ignore &&
> +               echo a >a &&
> +               git add a &&
> +               git commit -m "repo2 commit 1"
> +       )
> +'
> +
> +test_expect_success 'setup - create repository "repo" to be added with sumodules' '
> +       mkdir repo &&
> +       (
> +               cd repo &&
> +               git init &&
> +               git config receive.denyCurrentBranch ignore &&
> +               echo a >a &&
> +               git add a &&
> +               git commit -m "repo commit 1"
> +       )
> +'
> +
> +test_expect_success 'setup - clone repository "repo" in "repoclone"' '
> +       git clone "$repourl" repoclone
> +'
> +
> +test_expect_success 'setup - add "mod1" as regular submodule of "repo"' '
> +       (
> +               cd repo &&
> +               git submodule add "$submodurl1" submod1
> +       )
> +'
> +
> +test_expect_success 'setup - add "mod2" as update attached HEAD submodule of "repo"' '
> +       (
> +               cd repo &&
> +               git submodule add --attached-update "$submodurl2" submod2
> +       )
> +'
> +
> +test_expect_success 'setup - commit submodules in repo' '
> +       (
> +               cd repo &&
> +               git add . &&
> +               git commit -m "Added submodules"
> +       )
> +'
> +
> +test_expect_success 'init submodules in cloned repo' '
> +       (
> +               cd repoclone &&
> +               git pull &&
> +               git submodule init
> +       )
> +'
> +
> +test_expect_success 'update submodules in cloned repo' '
> +       (
> +               cd repoclone &&
> +               git submodule update
> +       )
> +'
> +
> +test_expect_success 'assert submod1 HEAD is detached in cloned repo' '
> +       (
> +               cd repoclone/submod1 &&
> +               test "$(git rev-parse --abbrev-ref HEAD)" = "HEAD"
> +       )
> +'
> +
> +test_expect_success 'assert submod2 HEAD is attached in cloned repo' '
> +       (
> +               cd repoclone/submod2 &&
> +               test "$(git rev-parse --abbrev-ref HEAD)" != "HEAD"
> +       )
> +'
> +
> +test_expect_success 'update submodules with --attach in cloned repo' '
> +       (
> +               cd repoclone &&
> +               git submodule update --attach
> +       )
> +'
> +
> +test_expect_success 'assert submod1 HEAD is attached in cloned repo' '
> +       (
> +               cd repoclone/submod1 &&
> +               test "$(git rev-parse --abbrev-ref HEAD)" != "HEAD"
> +       )
> +'
> +
> +test_expect_success 'update submodules with --detach in cloned repo' '
> +       (
> +               cd repoclone &&
> +               git submodule update --detach
> +       )
> +'
> +
> +test_expect_success 'assert submod1 HEAD is detached in cloned repo' '
> +       (
> +               cd repoclone/submod1 &&
> +               test "$(git rev-parse --abbrev-ref HEAD)" = "HEAD"
> +       )
> +'
> +
> +test_expect_success 'assert submod2 HEAD is detached in cloned repo' '
> +       (
> +               cd repoclone/submod2 &&
> +               test "$(git rev-parse --abbrev-ref HEAD)" = "HEAD"
> +       )
> +'
> +
> +test_expect_success 'update submodules in cloned repo (will restore HEAD states)' '
> +       (
> +               cd repoclone &&
> +               git submodule update
> +       )
> +'
> +
> +test_expect_success 'assert submod1 HEAD is detached in cloned repo' '
> +       (
> +               cd repoclone/submod1 &&
> +               test "$(git rev-parse --abbrev-ref HEAD)" = "HEAD"
> +       )
> +'
> +
> +test_expect_success 'assert submod2 HEAD is attached in cloned repo' '
> +       (
> +               cd repoclone/submod2 &&
> +               test "$(git rev-parse --abbrev-ref HEAD)" != "HEAD"
> +       )
> +'
> +
> +test_expect_success 'setup - add update operation to submodules' '
> +       (
> +               cd repo &&
> +               git config  -f .gitmodules submodule.submod1.update merge &&
> +               git config  -f .gitmodules submodule.submod2.update rebase &&
> +               git add . &&
> +               git commit -m "updated submodules"
> +       )
> +'
> +
> +test_expect_success 'setup - update cloned repo and reinitialize submodules' '
> +       (
> +               cd repoclone &&
> +               git pull &&
> +               git submodule init
> +       )
> +'
> +
> +test_expect_success 'add some content to repo2' '
> +       (
> +               cd repo2 &&
> +               echo b >b &&
> +               git add b &&
> +               git commit -m "repo2 commit 2"
> +       )
> +'
> +
> +test_expect_success 'update sumodules in cloned repo and verify that submod2 matches repo2' '
> +       (
> +               cd repoclone &&
> +               git submodule update &&
> +               test -e submod2/b
> +       )
> +'
> +
> +test_expect_success 'prepend some content to repo1/a' '
> +       (
> +               cd repo1 &&
> +               echo -e "b\na" >a &&
> +               git add a &&
> +               git commit -m "repo1 commit 2"
> +       )
> +'
> +
> +test_expect_success 'append some content in repoclone/submod1 and commit' '
> +       (
> +               cd repoclone/submod1 &&
> +               echo c >>a &&
> +               git add a &&
> +               git commit -m "submod1 commit 1"
> +       )
> +'
> +
> +test_expect_success 'update repoclone submodules with --attach' '
> +       (
> +               cd repoclone &&
> +               git submodule update --attach
> +       )
> +'
> +
> +test_expect_success 'verify repoclone submod1 merge with reattached orphaned commits was correct' '
> +       (
> +               cd repoclone/submod1 &&
> +               test "$(<a)" = "$'b\na\nc'"
> +       )
> +'
> +
> +test_expect_success 'setup - set operation checkout to submodule sumod1 in repo' '
> +       (
> +               cd repo &&
> +               git config  -f .gitmodules submodule.submod1.update checkout &&
> +               git add . &&
> +               git commit -m "updated submodules"
> +       )
> +'
> +
> +test_expect_success 'setup - update cloned repo and reinitialize submodules' '
> +       (
> +               cd repoclone &&
> +               git pull &&
> +               git submodule init
> +       )
> +'
> +
> +test_expect_success 'add some content to repo1' '
> +       (
> +               cd repo1 &&
> +               echo b >b &&
> +               git add b &&
> +               git commit -m "repo1 commit 3"
> +       )
> +'
> +
> +test_expect_success 'update submodule submod2 (merge ff-only) and verify it matches repo2' '
> +       (
> +               cd repoclone &&
> +               git submodule update &&
> +               test -e submod2/b
> +       )
> +'
> +
> +test_done
> --
> 1.8.5.2.230.g032cd47.dirty
>

> At the current state, the following use-case is not supported very
> well in git:
> - a maintainer adds a submodule, checking out a specific branch of
> the repository. He doesn't track the upstream submodule revision sha1;
> - a developer checkout the repository branch decided by the maintainer.
> Subsequent "merge" or "rebase" update operations don't detach the HEAD.

> The following questions directly pop into my mind:
>
>  - What means the maintainer does not track the submodules sha1? Does
>    that mean the superproject always refers to submodule commits using
>    branches?

> 2014/1/5 Heiko Voigt <hvoigt@hvoigt.net>:
> > The following questions directly pop into my mind:
> >
> >  - What means the maintainer does not track the submodules sha1? Does
> >    that mean the superproject always refers to submodule commits using
> >    branches?
> 
> It means he doesn't need to control other developers commit to be
> checked out so he sets "submodule.<name>.ignore" to "all". In this way
> he and the developers can work actively in their submodule copy.

> >  - What happens if you want to go back to an earlier revision? Lets say
> >    a tagged release? How is ensured that you get the correct revision in
> >    the submodules?
> 
> "submodule.<name>.branch" is one setting that is not copied in
> ".git/config" by "git submodule init". "git submodule update" will use
> the setting in ".gitmodules" if not overridden voluntarily by the
> developer in ".git/config". The maintainer can change that setting in
> ".gitmodules" and commit the change. Modifies will be propagated by
> the next "git pull && git submodule update" of the developer in the
> superproject.

> >  - In which situations does the developer or maintainer switch between
> >    your attached/detached mode?
> 
> The developer/maintainer does so optionally and voluntarily and it
> effects only its private working tree.

> >  - What is the "repository branch" which is given to the developer by
> >    the maintainer used for? Who creates this branch and who merges into
> >    it?
> 
> The branch of course must exist prior submodule adding. In this
> use-case it does not really matter who creates it and who merges into
> it. Everyone with the right to merge into it has to work in the
> submodule seamlessly, as it was working on separate clone of the same
> repository used as the submodule.

> >  - What are these subsequent "merge" or "rebase" update operations? Do
> >    you mean everyone has submodule.name.update configured to merge or
> >    rebase?
> >
> 
> subsequent "merge" or "rebase" update operations are just the ones
> after the initial clone/checkout, nothing particular.

> On Sun, Jan 05, 2014 at 10:46:11PM +0100, Francesco Pretto wrote:
>> It means he doesn't need to control other developers commit to be
>> checked out so he sets "submodule.<name>.ignore" to "all". In this way
>> he and the developers can work actively in their submodule copy.
>
> So practically speaking: You mean that the value of
> submodule.<name>.ignore is set to "all" in the master branch of the
> superproject? From your other email referring to svn:externals I figure
> that.
>

> The workflow could always be changed to allow recording revisions. Which
> is why you use git in the first place right? If you discard revisions
> for submodules tracking down regression bugs can become a big problem or
> completely impossible. Try using git bisect on such a history.
>

>> "submodule.<name>.branch" is one setting that is not copied in
>> ".git/config" by "git submodule init". "git submodule update" will use
>> the setting in ".gitmodules" if not overridden voluntarily by the
>> developer in ".git/config". The maintainer can change that setting in
>> ".gitmodules" and commit the change. Modifies will be propagated by
>> the next "git pull && git submodule update" of the developer in the
>> superproject.
>
> I do not understand how does that ensure you get the correct submodule
> revision when checking out a tagged release? To get a precise revision
> the superproject needs to track a sha1 of a submodule commit. I do not
> see how that has anything to do with submodule.<name>.branch?
>

>> >  - In which situations does the developer or maintainer switch between
>> >    your attached/detached mode?
>>
>> The developer/maintainer does so optionally and voluntarily and it
>> effects only its private working tree.
>
> This does not answer my question. I would like to find out the reason
> why one would do the switch.
>

>> The branch of course must exist prior submodule adding. In this
>> use-case it does not really matter who creates it and who merges into
>> it. Everyone with the right to merge into it has to work in the
>> submodule seamlessly, as it was working on separate clone of the same
>> repository used as the submodule.
> o
> Here is the same. I am searching for a description like:
>
> If the developer works on a feature that needs a submodule change he:
>   - creates a submodule branch
>   - configures that submodule branch in the superproject:
>         git config -f .gitmodules submodule.common.branch dev/some-feature
>         git commit -am "TEMP: track submodule common on branch"
>  - and pushes out his superproject branch
>
> The submodule branch is then posted for review and continued to work on.
>
> Once everyone involved is happy with the submodule change the branch in
> there gets merged to master.
>
> Now the branch in the superproject is modified to drop the change in
> .gitmodules and the sha1 reference in the superproject is updated to the
> current master of the superproject.
>
> The superproject branch is posted for review.
>
> ...
>
> Could you describe something like this for your workflow? A complete
> change lifecycle when a developer works, as you call it, "actively" in a
> submodule?
>

>> Maybe who coded submodules at first was thinking that the best way to
>> contribute to a project is to checkout that repository, and not work
>> in the submodule. As said, this works well when the submodule
>> repository is a full project, and not a bunch of shared code.
>
>Why not work in the submodule? See explanation above.
>

>> >  - What are these subsequent "merge" or "rebase" update operations? Do
>> >    you mean everyone has submodule.name.update configured to merge or
>> >    rebase?
>> >
>>
>> subsequent "merge" or "rebase" update operations are just the ones
>> after the initial clone/checkout, nothing particular.
>
> To clarify you are talking about issuing "git merge" or "git rebase"
> commands in the superproject?
>

> I am not so sure. svn:externals was IMO a hack in SVN to bind projects
> together. It does not record the revision and so has nothing to do
> with version control. If you simply want to always checkout the
> development tip of some project you could do something like this:
>
>        git submodule foreach 'git fetch && git checkout origin/master'

> The demand for this 'missing feature' which we call the 'floating
> submodules' model has been around for some time but until now we could
> convince people that its not a feature but you are actually loosing
> history information.
>

> 2014/1/6 Heiko Voigt <hvoigt@hvoigt.net>:
>> Could you describe something like this for your workflow? A complete
>> change lifecycle when a developer works, as you call it, "actively" in a
>> submodule?
>>
>
> I'm really sorry, I thought this was already clear from the first
> patch iteration. I will go more in depth:

>              +-----------+
>              |  master   | <--
> +-------+    +-----------+    | Merges to/from master
> | CEDET |                     | done only by CEDET developers
> +-------+                     | 
>              +-----------+    |
>              |  stable   | <--  <--------
>              +-----------+               |
>                                          |
>                                          |
>                                          | Any Emacs developer
>                                          | can push and commit
>                                          | submodule
> +--------+    +----------------------+   |
> | Emacs  | -- | lisp/cedet submodule | <-
> +--------+    +----------------------+

> AFAICS the main problem with this approach is that one always has to
> think of committing the new SHA1 of the submodule.
> …
> However, as Heiko notes, the history must be preserved to be able to
> go back to earlier revisions, so there must be some kind of commit
> for the submodule when 'stable' changes; maybe that could be
> automated somehow?

> Maintainer of "project1" also prepares a branch
> "project1-staging-featureA" on "common" and set ".gitmodules" of
> "project1" to point to "project1-staging-featureA". Developers of
> featureA would like to do this:
> 
> $ git pull
> $ git checkout staging-featureA
> $ git submodule update      # clones an attached HEAD of common on the branch
>                             # 'submodule.common.project1.staging-featureA'
> $ .... start coding in common seamlessly as they where in project1 ....

> Also developers do frequently rebase:
> $ git pull --rebase
> $ git submodule update
> 
> Or maybe a shortcut of this: "git submodule update" should be given
> the possibility to go "--remote" by default.

> >> Maybe who coded submodules at first was thinking that the best
> >> way to contribute to a project is to checkout that repository,
> >> and not work in the submodule. As said, this works well when the
> >> submodule repository is a full project, and not a bunch of shared
> >> code.
> >
> >Why not work in the submodule? See explanation above.
> 
> Because, as said above, the submodule is not independent. It does
> not have proper code that test it and the best test case is using
> the submodule in the scope of the superproject.

> 2014/1/6 Heiko Voigt <hvoigt@hvoigt.net>:
> > I am not so sure. svn:externals was IMO a hack in SVN to bind projects
> > together. It does not record the revision and so has nothing to do
> > with version control. If you simply want to always checkout the
> > development tip of some project you could do something like this:
> >
> >        git submodule foreach 'git fetch && git checkout origin/master'
> 
> This can be very unconvenient if the reccomended *starting* branch to
> where attach the HEAD is not "master":
> git submodule foreach 'branch="$(git config -f $toplevel/.gitmodules
> submodule.$name.branch)"; git checkout origin/$branch

> 2014/1/7 W. Trevor King <wking@tremily.us>:
> >
> > I'd be happy to hear ideas about superproject-branch-specific local
> > overrides to a hypothetical submodule.<name>.local-branch, in the
> > event that a developer doesn't like a default set in .gitmodules.  If
> > I could think of a way to do that, we could avoid this heuristic
> > approach, and make the local submodule.<name>.local-branch
> > vs. remote-tracking submodule.<name>.branch distinction more obvious.
> 
> Uh, I think you got it wrong in the other thread:

> * Auto checkout of the preferred branch
>   * Can do this at clone-update time with my patch.
>   * For later submodule branch switches, maybe we want:
> 
>       git submodule checkout [-b <branch>] [<paths>…]
> 
>     Then if a user blows off their detached HEAD, at least they'll
>     feel a bit sheepish afterwards.

> There are three branches that submodule folks usually care about:
> 
> 1. The linked $sha1 in the superproject (set explicitly for every
>    superproject commit, and thus for every superproject branch).
> 2. The remote-tracking submodule.<name>.branch that lives in the
>    upstream submodule.<name>.url repository.
> 3. The submodule's locally checked out branch, which we currently let
>    the developer setup by hand, which is used integrated with one of
>    the other two branches during non-checkout updates.
> 
> Git is currently a bit weak on conveniently handling type-3 branches.
> “Just use what the developer has setup” works well for many basic
> workflows, but falls short for:
> 
> * Cloning-updates, where we currently always setup a detached HEAD.
> * Workflows where the preferred type-3 branch depends on the
>   superproject branch.
> 
> The former is easy to fix [1] if you accept submodule.<name>.branch as
> a guess, but this conflates the type-2 and type-3 branches.
> 
> For the latter, you'd want something like:
> 
> On Mon, Jan 06, 2014 at 08:10:04PM -0800, W. Trevor King wrote:
> > * Auto checkout of the preferred branch
> >   * Can do this at clone-update time with my patch.
> >   * For later submodule branch switches, maybe we want:
> > 
> >       git submodule checkout [-b <branch>] [<paths>…]
> > 
> >     Then if a user blows off their detached HEAD, at least they'll
> >     feel a bit sheepish afterwards.
> 
> which would likely need some of Jens' new core checkout handling [2].
> 
> [1]: Using something along the lines of my
>      http://article.gmane.org/gmane.comp.version-control.git/239967
> [2]: http://article.gmane.org/gmane.comp.version-control.git/240117

> 2014/1/8 W. Trevor King <wking@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.

> 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).

> > 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".

> >> # 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.

>     #git checkout --recurse-submodules master
>     ( # 'git checkout --recurse-submodules' doesn't exist yet [2,3].
>       # Even with that patch, 'git checkout' won't respect
>       # submodule.<name>.local-branch without further work.
>       git checkout master &&
>       cd submod &&
>       git checkout master  # don't pull in our my-feature work
>     )
>     git submodule update --remote &&
>     git commit -am 'Catch submod up with Subproject v2' &&
>     # update the my-feature branch
>     git checkout my-feature
>     ( # 'git checkout' doesn't mess with submodules
>       cd submod &&
>       git checkout my-feature
>     )

>
> @@ -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'")"
>  }
>

>  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

> In another branch of the submodule thread Francesco kicked off, I
> mentioned that we could store the preferred local submodule branch on
> a per-superbranch level if we used the
> .git/modules/<submodule-name>/config for local overrides [1].  Here's
> a patch series that greatly extends my v2 "submodule: Respect
> requested branch on all clones" series [2] to also support automatic,
> recursive submodule checkouts, as I outlined here [3].
> 
> [1]: http://article.gmane.org/gmane.comp.version-control.git/240240
> [2]: http://article.gmane.org/gmane.comp.version-control.git/239967
> [3]: http://article.gmane.org/gmane.comp.version-control.git/240192

> Am 09.01.2014 20:55, schrieb W. Trevor King:
> > On Thu, Jan 09, 2014 at 08:23:07PM +0100, Jens Lehmann wrote:
> >> Am 09.01.2014 18:32, schrieb W. Trevor King:
> >>>> when superproject branches are merged (with and without conflicts),
> >>>
> >>> I don't think this currently does anything to the submodule itself,
> >>> and that makes sense to me (use 'submodule update' or my 'submodule
> >>> checkout' if you want such effects).  We should keep the current logic
> >>> for updating the gitlinked $sha.  In the case that the
> >>> .gitmodule-configured local-branches disagree, we should give the
> >>> usual conflict warning (and <<<===>>> markup) and let the user resolve
> >>> the conflict in the usual way.
> >>
> >> For me it makes lots of sense that in recursive checkout mode the
> >> merged submodules are already checked out (if possible) right after
> >> a superproject merge, making another "submodule update" unnecessary
> >> (the whole point of recursive update is to make "submodule update"
> >> obsolete, except for "--remote").
> > 
> > If you force the user to have the configured local-branch checked out
> > before a non-checkout operations with checkout side-effects (as we
> > currently do for other kinds of dirty trees), I think you'll avoid
> > most (all?) of the branch-clobbering problems.
> 
> I'm thinking that a local branch works in two directions: It should
> make it easy to follow an upstream branch and also make changes to it
> (and publish those) if necessary. But neither local nor upstream
> changes take precedence, so the user should either use "merge" or
> "rebase" as update strategy or be asked to resolve the conflict
> manually when "checkout" is configured and the branches diverged.
> Does that make sense?

> Gitlinked commit hash
> ---------------------
> 
> The submodule model revolves around links to commits (“gitlinks”):
> 
>   $ git ls-tree HEAD
>   100644 blob 189fc359d3dc1ed5019b9834b93f0dfb49c5851f    .gitmodules
>   160000 commit fbfa124c29362f180026bf0074630e8bd0ff4550  submod
> 
> These are effectively switchable trees.  The tree referenced by commit
> fbfa124 is 492781c:
> 
>   $ (cd submod/ && git cat-file commit fbfa124)
>   tree 492781c581d4dec380a61ef5ec69a104de448a74
>   …
> 
> If you init the submodule, subsequent checkouts will check out that
> tree, just like 'git checkout' would do if you'd had a superproject
> tree like:
> 
>   $ git ls-tree HEAD
>   100644 blob 189fc359d3dc1ed5019b9834b93f0dfb49c5851f    .gitmodules
>   040000 tree 492781c581d4dec380a61ef5ec69a104de448a74    submod
> 
> For folks who treat the submodule as a black box (and do no local
> development), switchable trees are all they care about.  They can
> easily checkout (or not, with deinit), the submodule tree at a
> gitlinked hash, and everything is nice and reproducible.  The fact
> that 'submod' is stored as a commit object and not a tree, is just a
> convenient marker for optional init/deinit/remote-update-integration
> functionality.

> Additional metadata, the initial checkout, and syncing down
> -----------------------------------------------------------
> 
> However, folks who do local submodule development will care about
> which submodule commit is responsible for that tree, because that's
> going to be the base of their local development.  They also care about
> additional out-of-tree information, including the branch that commit
> is on.  For already-initialized submodules, there are existing places
> in the submodule config to store this configuration:
> 
> 1. HEAD for the checked-out branch,
> 2. branch.<name>.remote → remote.<name>.url for the upstream
>    subproject URL,
> 4. branch.<name>.rebase (or pull.rebase) to prefer rebase over merge
>    for integration,
> 5. …
> 
> You need somewhere in-tree to store this destined-to-be-out-of-tree
> information, so that superproject developers that have not yet
> initialized the submodule will know what values are suggested by the
> superproject maintainers.  That's where .gitmodules comes in, because
> storing all of this fairly static, locally overridable information in
> the gitlink itself would be nonsensical (said Linus in 2007 [1]).
> When you checkout a submodule for the first time, Git should take the
> default information from .gitmodules and file it away in the
> submodule's appropriate out-of-tree config locations.

>  The out-of-tree
> data listed above should be stored in:
> 
> 1. submodule.<name>.local-branch
> 2. submodule.<name>.url
> 4. submodule.<name>.update
> 5. …
> 
> Once you have an in-tree way to specify defaults for this out-of-tree
> information, you're going to have developers like me that just want to
> stick with the defaults, following them through changes.  That means
> you'd like to have the “copy .gitmodules defaults into your
> submodule's config” functionality that usually happens on the initial
> submodule checkout happen on *every superproject-initiated checkout*.

> In fact, I think life is easier for everyone if this is the default,
> and we add a new option (submodule.<name>.sync = false) that says
> “don't overwrite optional settings in my submodule's out-of-tree
> config on checkout” for for folks who want to opt out.  Don't worry,
> this is not going to clobber people, because we'll be syncing the
> other way too.

> Syncing up
> ----------
> 
> In the previous section I explained how data should flow from
> .gitmodules into out-of-tree configs.  What about the other direction?
> We currently let folks handle this by hand, but I'd prefer a tighter
> integration between the submodule config and the superproject tree to
> avoid losing work.  That means changes to tracked submodule status
> (checked-out hash, checked-out branch, upstream URL, upstream branch,
> default integration strategy, …) should trigger dirty-tree status just
> like uncommitted changes to in-tree files.  'git add' (or stash) on
> the dirty submodule would store changed commit hashes in the index,
> pull changed out-of-tree configs back into the in-tree .gitmodules,
> and add the new .gitmodules to the index.  If the working .gitmodules
> was already dirty (vs. the index), the add/stash should die without
> making any changes.  If the user has disabled syncing between
> .gitmodules and the submodule's out-of-tree configs, then don't worry
> about optional settings.  Always sync the required settings, which at
> this point would just be submodule.<name>.local-branch.

> Purely local metadata
> ---------------------
> 
> Some metadata does not make sense in the superproject tree.  For
> example, whether a submodule is interesting enough to checkout
> (init/deinit) or whether you want to auto-sync optional metadata
> .gitmodules defaults.  This metadata should live in the superproject's
> out-of-tree config, and should not be stored in the in-tree
> .gitmodules.

>  Since you *will* want to share the upstream URL, I
> proposed using an explicit submodule.<name>.active setting to store
> the “do I care” information [2], instead of overloading
> submodule.<name>.url (I'd auto-sync the .gitmodule's
> submodule.<name>.url with the subproject's remote.origin.url unless
> the user opted out of .gitmodules syncing).

> Subsequent checkouts
> --------------------
> 
> Now that we have strict linking between the submodule state (both
> in-tree and out-of-tree configs) and the superproject tree (gitlink
> and .gitmodules), changing between superproject branches is really
> easy:
> 
> 1. Make sure the working tree is not dirty.  If it is, ask the user to
>    either add-and-commit or stash, and then die to let them do so.

> 2. Checkout the new superproject branch.
> 
>    2.1. For each old submodule that doesn't exist in the new branch,
>         blow away the submodule directory (assuming a new-style
>         .git/modules/… layout, and not an old-style submod/.git/…
>         layout).

>    2.2. For each gitlinked submodule that didn't exist in the old
>         branch, setup the submodule as if you were doing the initial
>         cloning checkout (forcing a new local-branch to point at the
>         gitlinked commit).  If you find local out-of-tree
>         *superproject* configs that conflict with the .gitmodules
>         values, prefer the superproject configs.

>  Clobber submodule
>         configs and local branches at will (modulo
>         submodule.<name>.sync), because any submodule configs that the
>         user wanted to keep should have been added to the superproject
>         branch earlier (or stashed).

> Integrating other branches
> --------------------------
> 
> Merges and rebases can alter the submodule's in-tree configs (and
> create and remove submodules).  The existing logic for merging
> .gitmodules and gitlinks works well, so stick with that.  In the event
> that there are unresolvable conflicts, bail out and let the user
> resolve the conflicts and use 'git commit' to finish checking out the
> resolved state.

> Issues
> ------
> 
> I like the current submodule integration configuration:
> 
> * submodule.<name>.branch (specify the remote branch to integrate, but
>   I'd prefer submodule.<name>.integration-ref for clarity).
> * submodule.<name>.update (specify how to integrate it, but I'd prefer
>   submodule.<name>.integration-mode for clarity).

> more than the current core integration configuration:
> 
> * branch.<name>.merge (with branch.<name>.remote, the branch to remote
>   branch to integrate via merging).
> * branch.<name>.rebase (override branch.<name>.merge to integrate via
>   rebasing).
> 
> These seem to mix the orthogonal concepts of integration target and
> integration mode, and the divergence from the .gitmodules
> representation makes syncing awkward.

> Summary
> -------
> 
> New .gitmodules options:
> 
> * submodule.<name>.local-branch, store the submodule's HEAD, must stay
>   in sync for checkouts.

> * submodule.<name>.sync, for whether you want to automatically sync
>   the submodule's out-of-tree configs up to .gitmodules before
>   checkout operations, and sync back from .gitmodules (possibly
>   altered on the new branch) into the submodule's out-of-tree configs
>   during checkout.

> With this tighter binding, submodule information is either tracked in
> the superproject, or explicitly not touched by the superproject.  That
> makes it much harder to break things or clobber a user's work, and
> also much easier to keep submodules up to date with superproject
> changes.  Users shouldn't have to explicitly manage their submodules
> to carry out routine core tasks like checking out other branches.

> I think the ideal submodule-specific interface would be just:
> 
> * git submodule [--quiet] add [-b <branch>] [-f|--force] [--name <name>]
>                 [--reference <repository>] [--] <repository> [<path>]
> * git submodule [--quiet] init [--] [<path>...]
> * git submodule [--quiet] deinit [-f|--force] [--] <path>...
> * git submodule [--quiet] foreach [--recursive] <command>

> The current 'git submodule update --remote' would just be:
> 
>   $ git submodule foreach 'git pull'
> 
> because all of the local-branch checkouts would have already been
> handled.

> You get all the per-submodule configuration (for triangular workflows,
> etc.) for free, with no submodule-specific confusion.
> 
> So, is this:
> 
> * Interesting enough to be worth pursuing?
> * Simple enough to be easily understood?

> I'd be happy to mock this up in shell, but only if anyone else would
> be interested enough to review the implementation ;).  Then I'll look
> into integrating the preferred model (this tightly bound proposal, or
> v3's looser bindings, or <your idea here>) in C, building on Jens and
> Jonathan's work.

> Am 12.01.2014 02:08, schrieb W. Trevor King:
> > For folks who treat the submodule as a black box (and do no local
> > development), switchable trees are all they care about.  They can
> > easily checkout (or not, with deinit), the submodule tree at a
> > gitlinked hash, and everything is nice and reproducible.  The fact
> > that 'submod' is stored as a commit object and not a tree, is just
> > a convenient marker for optional
> > init/deinit/remote-update-integration functionality.
> 
> But there are users (like me) who do not treat submodules as
> black boxes and nonetheless do development in them with update
> set to checkout (after creating a feature branch of course ;-).

> > When you checkout a submodule for the first time, Git should take
> > the default information from .gitmodules and file it away in the
> > submodule's appropriate out-of-tree config locations.
> 
> I disagree, that only makes sense for the URL setting (and this
> currently only happens with the update setting, which I intend to
> change). Everything else should be taken from .gitmodules unless
> the user wants to override it. The only setting I'm not so sure
> about is the local branch setting, as that might have to propagate
> into the submodule.

> > In fact, I think life is easier for everyone if this is the
> > default, and we add a new option (submodule.<name>.sync = false)
> > that says “don't overwrite optional settings in my submodule's
> > out-of-tree config on checkout” for for folks who want to opt out.
> > Don't worry, this is not going to clobber people, because we'll be
> > syncing the other way too.
> 
> Yet another flag to make peoples life easier? I don't think so ;-)

> > Purely local metadata
> > ---------------------
> > 
> > Some metadata does not make sense in the superproject tree.  For
> > example, whether a submodule is interesting enough to checkout
> > (init/deinit) or whether you want to auto-sync optional metadata
> > .gitmodules defaults.  This metadata should live in the
> > superproject's out-of-tree config, and should not be stored in the
> > in-tree .gitmodules.
> 
> Not always. It makes a lot of sense to let upstream mark a
> submodule as "too big and you won't need it anyway" in the
> .gitmodules file.

> > Since you *will* want to share the upstream URL, I proposed using
> > an explicit submodule.<name>.active setting to store the “do I
> > care” information [2], instead of overloading submodule.<name>.url
> > (I'd auto-sync the .gitmodule's submodule.<name>.url with the
> > subproject's remote.origin.url unless the user opted out of
> > .gitmodules syncing).
> 
> That is wrong as it would break horribly when you check out an old
> commit with a now dead submodule URL and that gets automatically
> synced.

> > Subsequent checkouts
> > --------------------
> > 
> > Now that we have strict linking between the submodule state (both
> > in-tree and out-of-tree configs) and the superproject tree (gitlink
> > and .gitmodules), changing between superproject branches is really
> > easy:
> > 
> > 1. Make sure the working tree is not dirty.  If it is, ask the user to
> >    either add-and-commit or stash, and then die to let them do so.
> 
> This condition is too hard, relax that to "a trivial merge can
> switch from current state to target state" and make it behave just
> like branch switching in the superproject. After all submodules
> should behave as much as possible like content of the superproject.

> >  Clobber submodule
> >         configs and local branches at will (modulo
> >         submodule.<name>.sync), because any submodule configs that
> >         the user wanted to keep should have been added to the
> >         superproject branch earlier (or stashed).
> 
> I don't think I like this part, but I admit I do not fully
> understand what you mean here. Clobbering stuff the user did doesn't
> sound very nice.

> > Summary
> > -------
> > 
> > New .gitmodules options:
> > 
> > * submodule.<name>.local-branch, store the submodule's HEAD, must
> >   stay in sync for checkouts.
> 
> I'm still not convinced that the current branch setting couldn't be
> extended to carry that information, but no objections against
> configuring such a branch. But what do you mean with "must stay in
> sync for checkouts"?

> > New .git/config options:
> > 
> > * submodule.<name>.active, for init/deinit.
> 
> I understand an option for automatic init (autoinit), but not for
> automatic deinit. Is the latter really useful?

> > I see no reason to add --recurse-submodule flags to 'git checkout'
> > (and merge, …).  Anything that happens post-clone should recurse
> > through submodules automatically, and use the
> > submodule.<name>.active setting to decide when recursion is
> > desired.
> 
> Backwards compatibility and testing. Let's first implement that and
> provide a config option to enable it for real world testing, and
> then let's discuss changing the default later.

> > The current 'git submodule update --remote' would just be:
> > 
> >   $ git submodule foreach 'git pull'
> > 
> > because all of the local-branch checkouts would have already been
> > handled.
> 
> Nope, that does different things to submodules where "branch" isn't
> configured, right?

> >  Similarly, a global push would be just:
> > 
> >   $ git submodule foreach 'git push'
> 
> What's wrong with:
> 
> $ git push --recurse-submodules=on-demand
> 
> And it'll push the superproject at the same time. Extra points for
> already being implemented ;-)

> > I'd be happy to mock this up in shell, but only if anyone else
> > would be interested enough to review the implementation ;).  Then
> > I'll look into integrating the preferred model (this tightly bound
> > proposal, or v3's looser bindings, or <your idea here>) in C,
> > building on Jens and Jonathan's work.
> 
> The update modes (cleaning removed submodules and creating new ones)
> are better handled in my recursive checkout series. But I believe we
> can at least prototype the branch handling in shell.

> Additional metadata, the initial checkout, and syncing down
> -----------------------------------------------------------
>
> However, folks who do local submodule development will care about
> which submodule commit is responsible for that tree, because that's
> going to be the base of their local development.  They also care about
> additional out-of-tree information, including the branch that commit
> is on.

>  For already-initialized submodules, there are existing places
> in the submodule config to store this configuration:
>
> 1. HEAD for the checked-out branch,
> 2. branch.<name>.remote → remote.<name>.url for the upstream
>    subproject URL,
> 4. branch.<name>.rebase (or pull.rebase) to prefer rebase over merge
>    for integration,
> 5. …

> Syncing up
> ----------
>
> In the previous section I explained how data should flow from
> .gitmodules into out-of-tree configs.

> ...  Since you *will* want to share the upstream URL, I
> proposed using an explicit submodule.<name>.active setting to store
> the “do I care” information [2], instead of overloading
> submodule.<name>.url (I'd auto-sync the .gitmodule's
> submodule.<name>.url with the subproject's remote.origin.url unless
> the user opted out of .gitmodules syncing).

> 2. Checkout the new superproject branch.
>
>    2.1. For each old submodule that doesn't exist in the new branch,
>         blow away the submodule directory (assuming a new-style
>         .git/modules/… layout, and not an old-style submod/.git/…
>         layout).

>    2.2. For each gitlinked submodule that didn't exist in the old
>         branch, setup the submodule as if you were doing the initial
>         cloning checkout (forcing a new local-branch to point at the
>         gitlinked commit).  If you find local out-of-tree
>         *superproject* configs that conflict with the .gitmodules
>         values, prefer the superproject configs.  Clobber submodule
>         configs and local branches at will (modulo
>         submodule.<name>.sync), because any submodule configs that the
>         user wanted to keep should have been added to the superproject
>         branch earlier (or stashed).

> "W. Trevor King" <wking@tremily.us> writes:
> 
> > Additional metadata, the initial checkout, and syncing down
> > -----------------------------------------------------------
> >
> > However, folks who do local submodule development will care about
> > which submodule commit is responsible for that tree, because
> > that's going to be the base of their local development.  They also
> > care about additional out-of-tree information, including the
> > branch that commit is on.
> 
> Well, please step back a bit.
> 
> They do not have to care about what local branch they use to build
> follow-up work based on that commit.

> I have a feeling that this is not specific for submodules---if you
> did this:
> 
> 	git init here
>         cd here
>         git fetch $there master
>         git reset --hard FETCH_HEAD
> 
> and are given the resulting working tree to start hacking on, you
> would not know where the history came from, or where your result
> wants to go.  
> 
> So "the branch that commit is on" is a wrong thing to focus on.
> "The branch the history built on top of the commit wants to go" may
> be closer and these two are different.

> >  For already-initialized submodules, there are existing places
> > in the submodule config to store this configuration:
> >
> > 1. HEAD for the checked-out branch,
> > 2. branch.<name>.remote → remote.<name>.url for the upstream
> >    subproject URL,
> > 4. branch.<name>.rebase (or pull.rebase) to prefer rebase over merge
> >    for integration,
> > 5. …
> 
> What happened to 3 ;-)?

> > Syncing up
> > ----------
> >
> > In the previous section I explained how data should flow from
> > .gitmodules into out-of-tree configs.
> 
> s/should/you think should/, I think, but another way may be not to
> copy and read from there, which may be a lot simpler.  Then upon
> switching branches of top-level superproject (which would update
> .gitmodules to the version on the new branch), you may get different
> settings automatically.

> > ...  Since you *will* want to share the upstream URL, I proposed
> > using an explicit submodule.<name>.active setting to store the “do
> > I care” information [2], instead of overloading
> > submodule.<name>.url (I'd auto-sync the .gitmodule's
> > submodule.<name>.url with the subproject's remote.origin.url
> > unless the user opted out of .gitmodules syncing).
> 
> It may not be a good idea to blindly update to whatever happens to
> be in .gitmodules, especially once submodule.*.url is initialized.

> Imagine that your embedded appliance project used to use a submodule
> from git://k.org/linux-2.6 as its kernel component and now the
> upstream of it is instead called just git://k.org/linux; the URL
> specified by submodule.kernel.url in .gitmodules for the entry
> submodule.kernel.path=kernel would have changed from the former to
> the latter sometime in the superproject's history.  Switching back
> to an old version in the superproject to fix an old bug in the
> maintenance track of the superproject would still want to push
> associated fixes to the kernel to k.org/linux, not linux-2.6, the
> latter of which may now be defunct [*1*].

> Here's an attempted summary of our desires, and my ideal route
> forward:
> 
> * Preferred local submodule branches for each superproject branch.
>   * Not currently supported by Git.
>   * Requires some sort of per-superproject-branch .git/config.
>   * Fall back to the remote-tracking submodule.<name>.branch?
> 
> * Auto checkout of the preferred branch
>   * Can do this at clone-update time with my patch.
>   * For later submodule branch switches, maybe we want:
> 
>       git submodule checkout [-b <branch>] [<paths>…]
> 
>     Then if a user blows off their detached HEAD, at least they'll
>     feel a bit sheepish afterwards.

> On Mon, Jan 06, 2014 at 08:10:04PM -0800, W. Trevor King wrote:
> > Here's an attempted summary of our desires, and my ideal route
> > forward:
> > 
> > * Preferred local submodule branches for each superproject branch.
> >   * Not currently supported by Git.
> >   * Requires some sort of per-superproject-branch .git/config.
> >   * Fall back to the remote-tracking submodule.<name>.branch?
> > 
> > * Auto checkout of the preferred branch
> >   * Can do this at clone-update time with my patch.
> >   * For later submodule branch switches, maybe we want:
> > 
> >       git submodule checkout [-b <branch>] [<paths>…]
> > 
> >     Then if a user blows off their detached HEAD, at least they'll
> >     feel a bit sheepish afterwards.
> 
> Well, for development on a detached HEAD in a submodule we are currently
> not very careful anyway. A simple
> 
> 	git submodule update
> 
> will already blow away any detached HEAD work.

>>> >  - In which situations does the developer or maintainer switch between
>>> >    your attached/detached mode?
>>>
>>> The developer/maintainer does so optionally and voluntarily and it
>>> effects only its private working tree.
>>
>> This does not answer my question. I would like to find out the reason
>> why one would do the switch.
>
> The developer does it voluntarily, at his responsibility, because he
> may decide to partecipate more actively to the development of the
> submodule and still want to use a simple "git submodule update" to
> updates his submodules, overriding its configuration as it can be done
> for other properties like, for example, "branch".

> Francesco Pretto <ceztko@gmail.com> writes:
>> The developer does it voluntarily, at his responsibility, because he
>> may decide to partecipate more actively to the development of the
>> submodule and still want to use a simple "git submodule update" to
>> updates his submodules, overriding its configuration as it can be done
>> for other properties like, for example, "branch".
>
> It is still unclear to me why we need attached/detached mode for
> that.  The developer may want to do an exploratory development,
> whose result is unknown to deserve to be committed on the specified
> branch at the beginning, and choose to build on a detached HEAD,
> which is a perfectly normal thing to do.  But the standard way to do
> so, whether the developer is working in the top-level superproject
> or in a submodule, would be to just do:
>
>         cd $there && git checkout HEAD^0
>
> or use whatever commit the state to be detached is at instead of
> "HEAD" in the above example, no?
>

> 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.

> Francesco Pretto <ceztko@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?
>

> 2014/1/5 Heiko Voigt <hvoigt@hvoigt.net>:
> > Could you please extend the description of your use-case so we can
> > understand your goal better?
> >
> 
> Maybe I found better words to explain you my goal: the current git
> submodule use-case threats the submodule as a project independent
> dependency. My use case threats the submodule as part of the
> superproject repository. It could be easier to say that in this way
> submodules would behave very similarly to "svn:externals", something
> that is actually missing in git. My goal is obtain this without
> altering git behavior for the existing use case.

> >  - In which situations does the developer or maintainer switch between
> >    your attached/detached mode?
> 
> As I told you in the other answer this is voluntary done by the
> developer, as he prefers.

> I came to the conclusion that the
> "--attach|--detach" switches for the "update" command are not that
> useful and can be removed. It's still possible to obtain the switch
> between detached/attached very easily in this way:
> 
> # Attach submodule
> $ git config submodule.<name>.attached "true"
> $ git submodule update
> 
> # Detach submodule
> $ git config submodule.<name>.attached "false"
> $ git submodule update
> 
> # Unset property in both ".gitmodules" and ".git/config" means -> do nothing
> $ git config --unset submodule.<name>.attached
> $ git submodule update
> 
> Also my "submodule.<name>.attached" property at the moment behaves
> like "submodule.<name>.update": it is copied in ".git/config" by "git
> submodule init". This is probably a mistake: the overridden value
> should be stored in ".git/config" only at the developer will, so the
> maintainer has still a chance to modify it in ".gitmodules" and
> propagate the behavior.
> 
> I would send an updated patch but at this point I prefer to wait for a
> full review.

> According to "Documentation/gitmodules.txt", 'checkout' is a valid
> 'submodule.<name>.update' command. Also "git-submodule.sh" refers to
> it and processes it correctly. Reflect commit 'ac1fbb' to support this
> syntax and also validates property values during 'update' command,
> issuing a warning if the value found is unknwon.

> ---
>  git-submodule.sh | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 2677f2e..1d041a7 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -622,7 +622,7 @@ cmd_init()
>  		   test -z "$(git config submodule."$name".update)"
>  		then
>  			case "$upd" in
> -			rebase | merge | none)
> +			checkout | rebase | merge | none)
>  				;; # known modes of updating
>  			*)
>  				echo >&2 "warning: unknown update mode '$upd' suggested for submodule '$name'"
> @@ -805,6 +805,18 @@ cmd_update()
>  			update_module=$update
>  		else
>  			update_module=$(git config submodule."$name".update)
> +			case "$update_module" in
> +			'')
> +				;; # Unset update mode
> +			checkout | rebase | merge | none)
> +				;; # Known update modes
> +			!*)
> +				;; # Custom update command
> +			*)
> +				update_module=
> +				echo >&2 "warning: invalid update mode for submodule '$name'"

> +			case "$update_module" in
> +			'')
> +				;; # Unset update mode
> +			checkout | rebase | merge | none)
> +				;; # Known update modes
> +			!*)
> +				;; # Custom update command
> +			*)
> +				update_module=
> +				echo >&2 "warning: invalid update mode for submodule '$name'"
> +				;;
> +			esac

> On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
>> +			case "$update_module" in
>> +			'')
>> +				;; # Unset update mode
>> +			checkout | rebase | merge | none)
>> +				;; # Known update modes
>> +			!*)
>> +				;; # Custom update command
>> +			*)
>> +				update_module=
>> +				echo >&2 "warning: invalid update mode for submodule '$name'"
>> +				;;
>> +			esac
>
> I'd prefer `die "…"` to `echo >&2 "…"`.  It's hard to know if mapping
> the user's preferred (unknown) update mechanism to 'checkout' is
> serious or not.
>
> This commit also makes me think that --rebase, --merge, and --checkout
> should be replaced with a single --update={rebase|merge|checkout|!…}
> option, but that's probably food for another commit (and a long
> finger-breaking deprecation period).

> "W. Trevor King" <wking@tremily.us> writes:
>
>> On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
>>> +			case "$update_module" in
>>> +			'')
>>> +				;; # Unset update mode
>>> +			checkout | rebase | merge | none)
>>> +				;; # Known update modes
>>> +			!*)
>>> +				;; # Custom update command
>>> +			*)
>>> +				update_module=
>>> +				echo >&2 "warning: invalid update mode for submodule '$name'"
>>> +				;;
>>> +			esac
>>
>> I'd prefer `die "…"` to `echo >&2 "…"`.  It's hard to know if mapping
>> the user's preferred (unknown) update mechanism to 'checkout' is
>> serious or not.
>>
>> This commit also makes me think that --rebase, --merge, and --checkout
>> should be replaced with a single --update={rebase|merge|checkout|!…}
>> option, but that's probably food for another commit (and a long
>> finger-breaking deprecation period).
>
> All of the above points sound sensible to me.

> Junio C Hamano <gitster@pobox.com> writes:
>
>> "W. Trevor King" <wking@tremily.us> writes:
>>
>>> On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
>>>> +                   case "$update_module" in
>>>> +                   '')
>>>> +                           ;; # Unset update mode
>>>> +                   checkout | rebase | merge | none)
>>>> +                           ;; # Known update modes
>>>> +                   !*)
>>>> +                           ;; # Custom update command
>>>> +                   *)
>>>> +                           update_module=
>>>> +                           echo >&2 "warning: invalid update mode for submodule '$name'"
>>>> +                           ;;
>>>> +                   esac
>>>
>>> I'd prefer `die "…"` to `echo >&2 "…"`.  It's hard to know if mapping
>>> the user's preferred (unknown) update mechanism to 'checkout' is
>>> serious or not.
>>>
>>> This commit also makes me think that --rebase, --merge, and --checkout
>>> should be replaced with a single --update={rebase|merge|checkout|!…}
>>> option, but that's probably food for another commit (and a long
>>> finger-breaking deprecation period).
>>
>> All of the above points sound sensible to me.
>
> I'll tentatively queue this on 'pu' (with the suggested "die"
> update), with some rewording of the log message.  The patch needs to
> be signed-off, though.
>
> Thanks.