* [PATCH/RFC] Introduce git submodule add|update --attach
@ 2013-12-30 1:49 Francesco Pretto
2013-12-31 20:05 ` Phil Hord
2014-01-02 20:07 ` Junio C Hamano
0 siblings, 2 replies; 144+ messages in thread
From: Francesco Pretto @ 2013-12-30 1:49 UTC (permalink / raw)
To: git; +Cc: Francesco Pretto
Hello everybody,
by default "git submodule" performs its add or update operations on a detached
HEAD. This works well when using an existing full-fledged/indipendent project as
the submodule, as there's less frequent need to update it or commit back
changes. When the submodule is actually a large portion of shareable code
between different projects, and the superproject needs to track very closely
the evolution of the submodule (or the other way around), I feel more confortable
to reattach the HEAD of the submodule with an existing branch. This can be as
simple as having a superproject "project1" in branch "master" with a submodule
"common" attached to the branch "master-project1" or, in a more development
workflow, "project1" in branch "featureA" with the same submodule "common"
attached to a similarly named branch "featureA". Doing this in git requires me
the following:
# Maintainer
$ git submodule add --branch "master-project1" <repository> common
$ git commit -m "Added submodule"
$ git config -f .gitmodules submodule.common.ignore all
$ git push
$ cd <path>
$ git checkout "master-project1"
# Developer
$ git pull
$ git submodule init
$ git submodule update --remote
$ cd <path>
$ branch="$(git config -f ..\.gitmodules submodule.common.branch)"; git checkout $branch
While the burden for the repository maitainer/administrator is acceptable, in
the developer point of view there are two problems:
1) Checking out an attached HEAD of a specified branch as when using "--remote"
is not really simple as it could be and could require lauching of scrips or
reading some repository specific documentation. Also in Windows platform the
syntax for inline shell evaluation of commands is less known between users;
2) There's no way to store a similar default behaviour in the repository except
by using scripts. Also recently submodule.<modulename>.update custom !commands
in no more supported when stored in .gitmodules [1].
The attached patch tries to solve these problems by introducing an "--attach"
switch to the "add" and "update" submodule commands and a "--detach" switch just
for the "update" command. It also add the support for an 'submodule.<name>.attach'
property when updating. Using the "--attach" switch when adding a submodule does:
- create the submodule checking out an attached HEAD;
- set the 'submodule.<name>.attach' property to 'true';
- set the 'submodule.<name>.ignore' property to 'all' (this is useful as
attaching to the branch doesn't require tracking of revision sha1).
The rationale of setting 'attach' and 'ignore' properties when adding a
submodule with the "--attach" switch is to give a convenient default behaviour.
No other properties are set: the repository responsible will still be required
to configure a different 'submodule.<name>.update' behaviour separetely, if he
wants that.
When updating, using the '--attach' switch or operating in a repository with
'submodule.<name>.attach' set to 'true' 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,
keeping the HEAD attached;
- reattach the HEAD prior performing a 'merge', 'rebase' or '!command' update
operation if the HEAD was found detached.
'--attach' or 'submodule.<name>.attach' set to true also implies '--remote', as
it's needed the origin HEAD sha1 to verify the current HEAD state.
A '--detach' switch is also available. Using the '--detach' switch or
operating in a repository with 'submodule.<name>.attach' set to 'false' during
update will:
- checkout a detached HEAD if the repository was just cloned (same behaviour as
before);
- detach the HEAD prior performing a 'merge', 'rebase' or '!command' update
operation if the HEAD was found attached.
'submodule.<name>.attach' works the same way as 'submodule.<name>.update'
property: git copies the values found in ".gitmodules" in ".git/config" when
performing an "init" command. "update" looks for the values in ".git/config"
only.
'--attach' and '--detach' switches override an opposite behaviour of 'submodule.<name>.attach'
properties.
The patch is small (touches only git-submodule.sh) and 100% additive with
respect to currently documented behaviour: when using "add" and "update"
commands without the introduced switches and properties, git shall operate as
before. As a bonus (but this was done to ease conditionals and keep the code
clean) it also clarifies and validates the content of 'submodule.<name>.update'
during 'update' command, warning the user if it's not one of the supported
values 'checkout', 'merge', 'rebase' and 'none'. Please note that 'checkout'
update command was documented in upstream "Documentation/gitmodules.txt" [2] as
a valid 'submodule.<name>.update' value and code in upstream "git-submodule.sh"
implicitly assumes it as recognized value. "Documentation/git-submodule.txt"
doesn't mention it properly and I guess this is the reason why it wasn't
considered for the validation in [1] patch.
Using this patch, the previous workflow becomes:
# Maintainer
$ git submodule add --branch "master-project1" --attach <repository> <path>
$ git commit -m "Added submodule"
$ git push
# Developer
$ git pull
$ git submodule init
$ git submodule update
Is there interest in supporting this workflow and seeing this patch applied?
Thanks,
Francesco
[1] http://marc.info/?l=git&m=138610752125816&w=2
[2] Documentation/gitmodules.txt: "If 'checkout' (the default)..."
Signed-off-by: Francesco Pretto <ceztko@gmail.com>
---
Documentation/git-submodule.txt | 37 ++++++---
Documentation/gitmodules.txt | 11 ++-
git-submodule.sh | 172 +++++++++++++++++++++++++++++++++++++---
3 files changed, 197 insertions(+), 23 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index bfef8a0..452376d 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>] [--attach] [--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,10 @@ 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 `--attach` is specified, the submodule will be registered to be
+checked out with an an attached HEAD. Also `submodule.<name>.attach` 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 +161,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.attach` 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 +278,17 @@ OPTIONS
be overridden by setting the `submodule.<name>.branch` option in
either `.gitmodules` or `.git/config` (with `.git/config` taking
precedence).
+
+--attach::
+ This option is only valid for the add and update commands. Cause the
+ result of an add or update operation to be an attached HEAD. In the
+ update command , if `submodule.<name>.branch` is not set, it will
+ default to `master`. Note: for the update command `--attach` also
+ implies `--remote`.
+
+--detach::
+ This option is only valid for the update command. Cause the result
+ of the update operation to be forcedly a detached HEAD.
+
This works for any of the supported update procedures (`--checkout`,
`--rebase`, etc.). The only change is the source of the target SHA-1.
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index f7be93f..e6c3360 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -37,8 +37,10 @@ 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.
+ If 'checkout' (the default), the new commit (or the branch, when using
+ the '--attach' switch or the 'submodule.<name>.attach' property is set
+ to 'true' during an update operation) specified in the superproject 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 +56,11 @@ 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>.attach::
+ 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`, it will default to `master`
+
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 2677f2e..3951fa2 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>] [--attach] [--] <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,7 @@ update=
prefix=
custom_name=
depth=
+attach=
# 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 +353,9 @@ cmd_add()
custom_name=$2
shift
;;
+ --attach)
+ attach="true"
+ ;;
--depth)
case "$2" in '') usage ;; esac
depth="--depth=$2"
@@ -475,8 +479,17 @@ Use -f if you really want to add it." >&2
cd "$sm_path" &&
# ash fails to wordsplit ${branch:+-b "$branch"...}
case "$branch" in
- '') git checkout -f -q ;;
- ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
+ '')
+ git checkout -f -q
+ ;;
+ ?*)
+ if test -n "$attach"
+ then
+ git checkout -f -q "$branch"
+ else
+ git checkout -f -q -B "$branch" "origin/$branch"
+ fi
+ ;;
esac
) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
fi
@@ -491,6 +504,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 "$attach"
+ then
+ # We'll stay stick to the HEAD, no need to track revision sha1
+ git config -f .gitmodules submodule."$sm_name".attach "true"
+ git config -f .gitmodules submodule."$sm_name".ignore "all"
+ fi &&
git add --force .gitmodules ||
die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
}
@@ -622,7 +641,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'"
@@ -632,6 +651,23 @@ cmd_init()
git config submodule."$name".update "$upd" ||
die "$(eval_gettext "Failed to register update mode for submodule path '\$displaypath'")"
fi
+
+ # Copy "attach" setting when it is not set yet
+ if attached="$(git config -f .gitmodules submodule."$name".attach)" &&
+ test -n "$attached" &&
+ test -z "$(git config submodule."$name".attach)"
+ then
+ case "$attached" in
+ true | false)
+ ;; # Valid attach flag values
+ *)
+ echo >&2 "warning: invalid attach flag value for submodule '$name'"
+ upd=none
+ ;;
+ esac
+ git config submodule."$name".attach "$attached" ||
+ die "$(eval_gettext "Failed to register attached option for submodule path '\$displaypath'")"
+ fi
done
}
@@ -750,6 +786,14 @@ cmd_update()
--reference=*)
reference="$1"
;;
+ --attach)
+ if test "$attach" = "false" ; then usage ; fi
+ attach="true"
+ ;;
+ --detach)
+ if test "$attach" = "true" ; then usage ; fi
+ attach="false"
+ ;;
-m|--merge)
update="merge"
;;
@@ -800,11 +844,44 @@ cmd_update()
name=$(module_name "$sm_path") || exit
url=$(git config submodule."$name".url)
branch=$(get_submodule_config "$name" branch master)
+ if test -n "$attach"
+ then
+ attach_module=$attach
+ else
+ attach_module=$(git config submodule."$name".attach)
+ case "$attach_module" in
+ '')
+ ;; # Unset attach flag
+ true|false)
+ ;; # Valid attach flag values
+ *)
+ echo >&2 "warning: invalid attach flag value for submodule '$name'"
+ attach_module=
+ ;;
+ esac
+ fi
+ if test "$attach_module" = "false"
+ then
+ # Normalize attach 'false' flag value
+ attach_module=
+ fi
if ! test -z "$update"
then
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'"
+ ;;
+ esac
fi
displaypath=$(relative_path "$prefix$sm_path")
@@ -836,7 +913,7 @@ Maybe you want to use 'update --init'?")"
die "$(eval_gettext "Unable to find current revision in submodule path '\$displaypath'")"
fi
- if test -n "$remote"
+ if test -n "$remote" -o -n "$attach_module"
then
if test -z "$nofetch"
then
@@ -850,7 +927,16 @@ 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"
+ 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'")"
+ if test "$head_rev_ref" = "HEAD"
+ then
+ # Determine if the HEAD is detached
+ head_detached="true"
+ fi
+
+ if test "$subsha1" != "$sha1" || test -n "$attach_module" -a -n "$head_detached" ||
+ test -z "$attach_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
@@ -870,40 +956,102 @@ 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_pre=:
+ suffix_pre=
+ if test "$update_module" = "checkout"
+ then
+ if test -n "$attach_module" -a -z "$just_cloned"
+ then
+ # We need to attach to the HEAD/switch the branch prior
+ # performing any fast-forward update
+ command_pre="git checkout $subforce -q"
+ suffix_pre=$branch
+ fi
+ else
+ if test -n "$attach_module" -a -n "$head_detached"
+ then
+ # We need to reattach to the head
+ command_pre="git checkout $subforce -q"
+ suffix_pre=$branch
+ elif test -z "$attach_module" -a -z "$head_detached"
+ then
+ # We need to detach from the head
+ command_pre="git checkout $subforce -q"
+ suffix_pre=$sha1
+ fi
+ fi
+
must_die_on_failure=
+ custom_update=
+ suffix=
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
;;
merge)
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
+ if test -n "$just_cloned"
+ then
+ command="git checkout $subforce -q"
+ suffix=$branch
+ else
+ # Perform a fast-forward only merge of the origin
+ command="git merge $subforce --ff-only"
+ suffix="origin/$branch"
+ fi
+ die_msg="$(eval_gettext "Unable to checkout banch '\$branch' in submodule path '\$displaypath'")"
+ say_msg="$(eval_gettext "Submodule path '\$displaypath': checked out branch '\$branch'")"
+ 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_pre "$suffix_pre" &&
+ $command "$suffix")
then
say "$say_msg"
elif test -n "$must_die_on_failure"
--
1.8.5.2.227.g53f3478.dirty
^ permalink raw reply related [flat|nested] 144+ messages in thread
* Re: [PATCH/RFC] Introduce git submodule add|update --attach
2013-12-30 1:49 [PATCH/RFC] Introduce git submodule add|update --attach Francesco Pretto
@ 2013-12-31 20:05 ` Phil Hord
2014-01-02 18:48 ` Francesco Pretto
2014-01-02 20:07 ` Junio C Hamano
1 sibling, 1 reply; 144+ messages in thread
From: Phil Hord @ 2013-12-31 20:05 UTC (permalink / raw)
To: Francesco Pretto; +Cc: git
On Sun, Dec 29, 2013 at 8:49 PM, Francesco Pretto <ceztko@gmail.com> wrote:
>
> by default "git submodule" performs its add or update operations on a detached
> HEAD. This works well when using an existing full-fledged/indipendent project as
> the submodule, as there's less frequent need to update it or commit back
> changes. When the submodule is actually a large portion of shareable code
> between different projects, and the superproject needs to track very closely
> the evolution of the submodule (or the other way around), I feel more confortable
> to reattach the HEAD of the submodule with an existing branch. This can be as
> simple as having a superproject "project1" in branch "master" with a submodule
> "common" attached to the branch "master-project1" or, in a more development
> workflow, "project1" in branch "featureA" with the same submodule "common"
> attached to a similarly named branch "featureA". Doing this in git requires me
> the following:
>
> # Maintainer
> $ git submodule add --branch "master-project1" <repository> common
> $ git commit -m "Added submodule"
> $ git config -f .gitmodules submodule.common.ignore all
> $ git push
> $ cd <path>
> $ git checkout "master-project1"
>
> # Developer
> $ git pull
> $ git submodule init
> $ git submodule update --remote
> $ cd <path>
> $ branch="$(git config -f ..\.gitmodules submodule.common.branch)"; git checkout $branch
>
> While the burden for the repository maitainer/administrator is acceptable, in
> the developer point of view there are two problems:
> 1) Checking out an attached HEAD of a specified branch as when using "--remote"
> is not really simple as it could be and could require lauching of scrips or
> reading some repository specific documentation. Also in Windows platform the
> syntax for inline shell evaluation of commands is less known between users;
> 2) There's no way to store a similar default behaviour in the repository except
> by using scripts. Also recently submodule.<modulename>.update custom !commands
> in no more supported when stored in .gitmodules [1].
>
> The attached patch tries to solve these problems by introducing an "--attach"
> switch to the "add" and "update" submodule commands and a "--detach" switch just
> for the "update" command. It also add the support for an 'submodule.<name>.attach'
> property when updating. Using the "--attach" switch when adding a submodule does:
> - create the submodule checking out an attached HEAD;
> - set the 'submodule.<name>.attach' property to 'true';
> - set the 'submodule.<name>.ignore' property to 'all' (this is useful as
> attaching to the branch doesn't require tracking of revision sha1).
>
> The rationale of setting 'attach' and 'ignore' properties when adding a
> submodule with the "--attach" switch is to give a convenient default behaviour.
> No other properties are set: the repository responsible will still be required
> to configure a different 'submodule.<name>.update' behaviour separetely, if he
> wants that.
>
> When updating, using the '--attach' switch or operating in a repository with
> 'submodule.<name>.attach' set to 'true' 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,
> keeping the HEAD attached;
> - reattach the HEAD prior performing a 'merge', 'rebase' or '!command' update
> operation if the HEAD was found detached.
I need to understand this "reattach the HEAD" case better. Can you
give some examples of the expected behavior when merge, rebase or
!command is encountered?
> '--attach' or 'submodule.<name>.attach' set to true also implies '--remote', as
> it's needed the origin HEAD sha1 to verify the current HEAD state.
>
> A '--detach' switch is also available. Using the '--detach' switch or
> operating in a repository with 'submodule.<name>.attach' set to 'false' during
> update will:
> - checkout a detached HEAD if the repository was just cloned (same behaviour as
> before);
> - detach the HEAD prior performing a 'merge', 'rebase' or '!command' update
> operation if the HEAD was found attached.
>
> 'submodule.<name>.attach' works the same way as 'submodule.<name>.update'
> property: git copies the values found in ".gitmodules" in ".git/config" when
> performing an "init" command. "update" looks for the values in ".git/config"
> only.
>
> '--attach' and '--detach' switches override an opposite behaviour of 'submodule.<name>.attach'
> properties.
>
> The patch is small (touches only git-submodule.sh) and 100% additive with
> respect to currently documented behaviour: when using "add" and "update"
> commands without the introduced switches and properties, git shall operate as
> before. As a bonus (but this was done to ease conditionals and keep the code
> clean) it also clarifies and validates the content of 'submodule.<name>.update'
> during 'update' command, warning the user if it's not one of the supported
> values 'checkout', 'merge', 'rebase' and 'none'. Please note that 'checkout'
> update command was documented in upstream "Documentation/gitmodules.txt" [2] as
> a valid 'submodule.<name>.update' value and code in upstream "git-submodule.sh"
> implicitly assumes it as recognized value. "Documentation/git-submodule.txt"
> doesn't mention it properly and I guess this is the reason why it wasn't
> considered for the validation in [1] patch.
>
> Using this patch, the previous workflow becomes:
>
> # Maintainer
> $ git submodule add --branch "master-project1" --attach <repository> <path>
> $ git commit -m "Added submodule"
> $ git push
>
> # Developer
> $ git pull
> $ git submodule init
> $ git submodule update
>
> Is there interest in supporting this workflow and seeing this patch applied?
>
> Thanks,
> Francesco
>
> [1] http://marc.info/?l=git&m=138610752125816&w=2
> [2] Documentation/gitmodules.txt: "If 'checkout' (the default)..."
>
> Signed-off-by: Francesco Pretto <ceztko@gmail.com>
> ---
> Documentation/git-submodule.txt | 37 ++++++---
> Documentation/gitmodules.txt | 11 ++-
> git-submodule.sh | 172 +++++++++++++++++++++++++++++++++++++---
> 3 files changed, 197 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index bfef8a0..452376d 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>] [--attach] [--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,10 @@ 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 `--attach` is specified, the submodule will be registered to be
> +checked out with an an attached HEAD. Also `submodule.<name>.attach` 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 +161,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.attach` 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 +278,17 @@ OPTIONS
> be overridden by setting the `submodule.<name>.branch` option in
> either `.gitmodules` or `.git/config` (with `.git/config` taking
> precedence).
> +
> +--attach::
> + This option is only valid for the add and update commands. Cause the
Grammar: 'Causes the result'
> + result of an add or update operation to be an attached HEAD. In the
> + update command , if `submodule.<name>.branch` is not set, it will
typo: space before comma.
Also, the pronoun "it" here is unclear to me. Does this convey the
correct meaning?
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.
> + default to `master`. Note: for the update command `--attach` also
> + implies `--remote`.
> +
> +--detach::
> + This option is only valid for the update command. Cause the result
Grammar: 'Causes the result'
> + of the update operation to be forcedly a detached HEAD.
"Forcedly" is a bit strong, maybe, slightly misplaced, and not a word,
besides. How's this, instead:
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.
> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
> index f7be93f..e6c3360 100644
> --- a/Documentation/gitmodules.txt
> +++ b/Documentation/gitmodules.txt
> @@ -37,8 +37,10 @@ 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.
> + If 'checkout' (the default), the new commit (or the branch, when using
> + the '--attach' switch or the 'submodule.<name>.attach' property is set
> + to 'true' during an update operation) specified in the superproject will
> + be checked out in the submodule.
IMHO, this wording is overcomplicated by this change. How about:
If 'checkout' (the default), the new commit specified in the 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
Does the 'merge', 'rebase' and '!command' description need to be
updated, too? Here and above it seems to still suggest the old
behavior is kept when --attach is used.
> @@ -54,6 +56,11 @@ 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>.attach::
> + 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`, it will default to `master`
I think you mean "...and 'submodule.<name>.branch' is not set, it
will...", right?
Some explanation of what happens when it _is_ set would be useful
here, too, I think. But maybe I do not understand the nuances yet.
> +
> 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 2677f2e..3951fa2 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>] [--attach] [--] <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,7 @@ update=
> prefix=
> custom_name=
> depth=
> +attach=
>
> # 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 +353,9 @@ cmd_add()
> custom_name=$2
> shift
> ;;
> + --attach)
> + attach="true"
> + ;;
> --depth)
> case "$2" in '') usage ;; esac
> depth="--depth=$2"
> @@ -475,8 +479,17 @@ Use -f if you really want to add it." >&2
> cd "$sm_path" &&
> # ash fails to wordsplit ${branch:+-b "$branch"...}
> case "$branch" in
> - '') git checkout -f -q ;;
> - ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
> + '')
> + git checkout -f -q
> + ;;
Is this whitespace change intentional and necessary?
> + ?*)
> + if test -n "$attach"
> + then
> + git checkout -f -q "$branch"
> + else
> + git checkout -f -q -B "$branch" "origin/$branch"
> + fi
> + ;;
> esac
> ) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
> fi
> @@ -491,6 +504,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 "$attach"
> + then
> + # We'll stay stick to the HEAD, no need to track revision sha1
> + git config -f .gitmodules submodule."$sm_name".attach "true"
> + git config -f .gitmodules submodule."$sm_name".ignore "all"
> + fi &&
> git add --force .gitmodules ||
> die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
> }
> @@ -622,7 +641,7 @@ cmd_init()
> test -z "$(git config submodule."$name".update)"
> then
> case "$upd" in
> - rebase | merge | none)
> + checkout | rebase | merge | none)
This belongs in a commit of its own.
> ;; # known modes of updating
> *)
> echo >&2 "warning: unknown update mode '$upd' suggested for submodule '$name'"
> @@ -632,6 +651,23 @@ cmd_init()
> git config submodule."$name".update "$upd" ||
> die "$(eval_gettext "Failed to register update mode for submodule path '\$displaypath'")"
> fi
> +
> + # Copy "attach" setting when it is not set yet
> + if attached="$(git config -f .gitmodules submodule."$name".attach)" &&
> + test -n "$attached" &&
> + test -z "$(git config submodule."$name".attach)"
> + then
> + case "$attached" in
> + true | false)
> + ;; # Valid attach flag values
> + *)
> + echo >&2 "warning: invalid attach flag value for submodule '$name'"
> + upd=none
> + ;;
> + esac
> + git config submodule."$name".attach "$attached" ||
> + die "$(eval_gettext "Failed to register attached option for submodule path '\$displaypath'")"
> + fi
> done
> }
>
> @@ -750,6 +786,14 @@ cmd_update()
> --reference=*)
> reference="$1"
> ;;
> + --attach)
> + if test "$attach" = "false" ; then usage ; fi
> + attach="true"
> + ;;
> + --detach)
> + if test "$attach" = "true" ; then usage ; fi
> + attach="false"
> + ;;
> -m|--merge)
> update="merge"
> ;;
> @@ -800,11 +844,44 @@ cmd_update()
> name=$(module_name "$sm_path") || exit
> url=$(git config submodule."$name".url)
> branch=$(get_submodule_config "$name" branch master)
> + if test -n "$attach"
> + then
> + attach_module=$attach
> + else
> + attach_module=$(git config submodule."$name".attach)
> + case "$attach_module" in
> + '')
> + ;; # Unset attach flag
> + true|false)
> + ;; # Valid attach flag values
> + *)
> + echo >&2 "warning: invalid attach flag value for submodule '$name'"
> + attach_module=
> + ;;
> + esac
> + fi
> + if test "$attach_module" = "false"
> + then
> + # Normalize attach 'false' flag value
> + attach_module=
> + fi
> if ! test -z "$update"
> then
> 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'"
> + ;;
> + esac
Probably belongs to the same "other" commit mentioned before.
> fi
>
> displaypath=$(relative_path "$prefix$sm_path")
> @@ -836,7 +913,7 @@ Maybe you want to use 'update --init'?")"
> die "$(eval_gettext "Unable to find current revision in submodule path '\$displaypath'")"
> fi
>
> - if test -n "$remote"
> + if test -n "$remote" -o -n "$attach_module"
> then
> if test -z "$nofetch"
> then
> @@ -850,7 +927,16 @@ 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"
> + 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'")"
> + if test "$head_rev_ref" = "HEAD"
> + then
> + # Determine if the HEAD is detached
> + head_detached="true"
> + fi
> +
> + if test "$subsha1" != "$sha1" || test -n "$attach_module" -a -n "$head_detached" ||
> + test -z "$attach_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
> @@ -870,40 +956,102 @@ 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_pre=:
> + suffix_pre=
> + if test "$update_module" = "checkout"
> + then
> + if test -n "$attach_module" -a -z "$just_cloned"
> + then
> + # We need to attach to the HEAD/switch the branch prior
> + # performing any fast-forward update
> + command_pre="git checkout $subforce -q"
> + suffix_pre=$branch
> + fi
> + else
> + if test -n "$attach_module" -a -n "$head_detached"
> + then
> + # We need to reattach to the head
> + command_pre="git checkout $subforce -q"
> + suffix_pre=$branch
> + elif test -z "$attach_module" -a -z "$head_detached"
> + then
> + # We need to detach from the head
> + command_pre="git checkout $subforce -q"
> + suffix_pre=$sha1
> + fi
> + fi
> +
> must_die_on_failure=
> + custom_update=
> + suffix=
> 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
> ;;
> merge)
> 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
> + if test -n "$just_cloned"
> + then
> + command="git checkout $subforce -q"
> + suffix=$branch
> + else
> + # Perform a fast-forward only merge of the origin
> + command="git merge $subforce --ff-only"
> + suffix="origin/$branch"
> + fi
> + die_msg="$(eval_gettext "Unable to checkout banch '\$branch' in submodule path '\$displaypath'")"
> + say_msg="$(eval_gettext "Submodule path '\$displaypath': checked out branch '\$branch'")"
> + 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_pre "$suffix_pre" &&
> + $command "$suffix")
> then
> say "$say_msg"
> elif test -n "$must_die_on_failure"
I didn't have time to parse out all these conditional completion
commands in this review, but the feature seems sane to me, as I
understand it.
Phil
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH/RFC] Introduce git submodule add|update --attach
2013-12-31 20:05 ` Phil Hord
@ 2014-01-02 18:48 ` Francesco Pretto
2014-01-13 17:31 ` Junio C Hamano
0 siblings, 1 reply; 144+ messages in thread
From: Francesco Pretto @ 2014-01-02 18:48 UTC (permalink / raw)
To: Phil Hord; +Cc: git
Thanks for the comments, my replies below. Before, a couple of general
questions:
- I'm also writing some tests, should I commit them together with the
feature patch?
- to determine the attached/detached state I did this:
head_detached=
if test "$(rev-parse --abbrev-ref HEAD)" = "HEAD"
then
head_detached="true"
fi
Is this correct?
2013/12/31 Phil Hord <phil.hord@gmail.com>
>
> On Sun, Dec 29, 2013 at 8:49 PM, Francesco Pretto <ceztko@gmail.com> wrote:
> [...]
> >
> > When updating, using the '--attach' switch or operating in a repository with
> > 'submodule.<name>.attach' set to 'true' 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,
> > keeping the HEAD attached;
> > - reattach the HEAD prior performing a 'merge', 'rebase' or '!command' update
> > operation if the HEAD was found detached.
>
> I need to understand this "reattach the HEAD" case better. Can you
> give some examples of the expected behavior when merge, rebase or
> !command is encountered?
>
Thanks for pointing this out, actually my patch was a bit lacking at
this. Reattaching the HEAD prior to merge, rebase or "!command" would
have caused just a *silent* "git checkout "<branch>", possibly leaving
orphaned commits forgotten.
My plans for the patch are now to implement this safer and, IMO,
intuitive behavior: let set say we have a submodule "mod" with the
HEAD detached at orphaned commit <orphaned-sha1>. Let say
"origin/<branch>" is at commit <origin-sha1>. Let say I set
"submodule.mod.attach" to "true" or I run "git submodule update" with
the "--attach" switch. The expected behavior for submodule "mod" would
be (pseudocode):
git checkout <branch>
if "merge" and "head_detached" then
git merge <orphaned-sha1>
case:
"merge":
git merge <origin-sha1>
"rebase":
git rebase <origin-sha1>
"!<command>":
<command> <origin-sha1>
if "rebase" and "head_detached" then
git merge <orphaned-sha1>
So, in both "merge|rebase" cases we merge back orphaned commits with a
"git merge", but the effect will be a merge or a rebase depending of
the ordering of the main "update" operation. We can't assume a merge
or rebase operation in the case of !command so we let the
responsibility of merging back orphaned commits to the user.
Sounds good?
>
> > +
> > +--attach::
> > + This option is only valid for the add and update commands. Cause the
>
> Grammar: 'Causes the result'
>
Ok.
>
> > + result of an add or update operation to be an attached HEAD. In the
> > + update command , if `submodule.<name>.branch` is not set, it will
>
> typo: space before comma.
>
Ok.
>
> Also, the pronoun "it" here is unclear to me. Does this convey the
> correct meaning?
>
> 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.
>
Sounds good to me.
>
> > + default to `master`. Note: for the update command `--attach` also
> > + implies `--remote`.
> > +
> > +--detach::
> > + This option is only valid for the update command. Cause the result
>
> Grammar: 'Causes the result'
>
Ok.
>
> > + of the update operation to be forcedly a detached HEAD.
>
> "Forcedly" is a bit strong, maybe, slightly misplaced, and not a word,
> besides. How's this, instead:
>
> Forces the result of the update operation to be a detached HEAD in
> the submodule.
Sounds good to me.
>
> > 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.
> > + If 'checkout' (the default), the new commit (or the branch, when using
> > + the '--attach' switch or the 'submodule.<name>.attach' property is set
> > + to 'true' during an update operation) specified in the superproject will
> > + be checked out in the submodule.
>
> IMHO, this wording is overcomplicated by this change. How about:
>
> If 'checkout' (the default), the new commit specified in the superproject
> (or branch, with '--attach') will be checked out in the submodule.
>
Sounds good to me.
>
> > 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
>
> Does the 'merge', 'rebase' and '!command' description need to be
> updated, too? Here and above it seems to still suggest the old
> behavior is kept when --attach is used.
>
You are right, I'll improve those. Also I think the documentation was
a bit innacurate because, with the current git features state, it's
possible merge changes keeping the HEAD detached, and that's what
happen.
>
> > @@ -54,6 +56,11 @@ 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>.attach::
> > + 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`, it will default to `master`
>
> I think you mean "...and 'submodule.<name>.branch' is not set, it
> will...", right?
Correct. I'll fix it.
>
> Some explanation of what happens when it _is_ set would be useful
> here, too, I think. But maybe I do not understand the nuances yet.
>
I think you're right. I'll improve it.
>
> > @@ -475,8 +479,17 @@ Use -f if you really want to add it." >&2
> > cd "$sm_path" &&
> > # ash fails to wordsplit ${branch:+-b "$branch"...}
> > case "$branch" in
> > - '') git checkout -f -q ;;
> > - ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
> > + '')
> > + git checkout -f -q
> > + ;;
>
> Is this whitespace change intentional and necessary?
>
It's unnecessary but it was intentional. In the file there are mixed
indentation styles for cases but when there are multiple statements
clauses the more frequent style is to span single statement clauses to
multi-line too. I touched the clause below to become muti-statenent so
here we are. Please tell me if it's more correct to not touch that
line.
>
> > }
> > @@ -622,7 +641,7 @@ cmd_init()
> > test -z "$(git config submodule."$name".update)"
> > then
> > case "$upd" in
> > - rebase | merge | none)
> > + checkout | rebase | merge | none)
>
> This belongs in a commit of its own.
>
Agreed. I'll do it.
>
> > ;; # known modes of updating
> > *)
> > echo >&2 "warning: unknown update mode '$upd' suggested for submodule '$name'"
> > @@ -632,6 +651,23 @@ cmd_init()
> > git config submodule."$name".update "$upd" ||
> > die "$(eval_gettext "Failed to register update mode for submodule path '\$displaypath'")"
> > fi
> > +
> > + # Copy "attach" setting when it is not set yet
> > + if attached="$(git config -f .gitmodules submodule."$name".attach)" &&
> > + test -n "$attached" &&
> > + test -z "$(git config submodule."$name".attach)"
> > + then
> > + case "$attached" in
> > + true | false)
> > + ;; # Valid attach flag values
> > + *)
> > + echo >&2 "warning: invalid attach flag value for submodule '$name'"
> > + upd=none
> > + ;;
> > + esac
> > + git config submodule."$name".attach "$attached" ||
> > + die "$(eval_gettext "Failed to register attached option for submodule path '\$displaypath'")"
> > + fi
> > done
> > }
> >
> > @@ -750,6 +786,14 @@ cmd_update()
> > --reference=*)
> > reference="$1"
> > ;;
> > + --attach)
> > + if test "$attach" = "false" ; then usage ; fi
> > + attach="true"
> > + ;;
> > + --detach)
> > + if test "$attach" = "true" ; then usage ; fi
> > + attach="false"
> > + ;;
> > -m|--merge)
> > update="merge"
> > ;;
> > @@ -800,11 +844,44 @@ cmd_update()
> > name=$(module_name "$sm_path") || exit
> > url=$(git config submodule."$name".url)
> > branch=$(get_submodule_config "$name" branch master)
> > + if test -n "$attach"
> > + then
> > + attach_module=$attach
> > + else
> > + attach_module=$(git config submodule."$name".attach)
> > + case "$attach_module" in
> > + '')
> > + ;; # Unset attach flag
> > + true|false)
> > + ;; # Valid attach flag values
> > + *)
> > + echo >&2 "warning: invalid attach flag value for submodule '$name'"
> > + attach_module=
> > + ;;
> > + esac
> > + fi
> > + if test "$attach_module" = "false"
> > + then
> > + # Normalize attach 'false' flag value
> > + attach_module=
> > + fi
> > if ! test -z "$update"
> > then
> > 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'"
> > + ;;
> > + esac
>
> Probably belongs to the same "other" commit mentioned before.
>
Agreed. Please confirm that you meant only the
submodule."$module".update part here as you quoted also a lof of code
that does belongs to the main "--attach" functionality.
>
> I didn't have time to parse out all these conditional completion
> commands in this review, but the feature seems sane to me, as I
> understand it.
>
Good. After a response I should be able to produce an improved patch.
Thanks,
Francesco
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH/RFC] Introduce git submodule add|update --attach
2013-12-30 1:49 [PATCH/RFC] Introduce git submodule add|update --attach Francesco Pretto
2013-12-31 20:05 ` Phil Hord
@ 2014-01-02 20:07 ` Junio C Hamano
2014-01-02 23:42 ` Francesco Pretto
1 sibling, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-02 20:07 UTC (permalink / raw)
To: Francesco Pretto; +Cc: git, Jens Lehmann, Heiko Voigt
Francesco Pretto <ceztko@gmail.com> writes:
> by default "git submodule" performs its add or update operations on a detached
> HEAD. This works well when using an existing full-fledged/indipendent project as
> the submodule, as there's less frequent need to update it or commit back
> changes. When the submodule is actually a large portion of shareable code
> between different projects, and the superproject needs to track very closely
> the evolution of the submodule (or the other way around), I feel more confortable
> to reattach the HEAD of the submodule with an existing branch.
I may be missing some fundamental assumption in your mind when you
did this change, but in a workflow where somebody wants submodule
checkout to be on branches (as opposed to detached), wouldn't it
make more sense not to detach in the first place, rather than
introducing yet another option to "re-attach"? The documentation of
"submodule update" seems to say that its "merge" and "rebase" modes
do not detach in the first place (and it alludes to "--checkout" but
it is unclear what it does purely from the documentation, as "git
submodule --help" does not even list it as one of the options).
And if there is a good reason why detaching to update and then
(perhaps after verifying the result or cleaning it up? I dunno what
the expected use case is, so I am purely guessing) attaching the
result to a specific branch in separate steps, does it make sense to
give "--attach" option to "update" in the first place? That makes
the whole thing into a single step, not giving the user a chance to
do anything in between, which I am guessing is the whole point of
your not using the existing "do not detach, work on a branch" modes.
Puzzled...
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH/RFC] Introduce git submodule add|update --attach
2014-01-02 20:07 ` Junio C Hamano
@ 2014-01-02 23:42 ` Francesco Pretto
2014-01-03 0:26 ` Francesco Pretto
2014-01-03 8:49 ` Francesco Pretto
0 siblings, 2 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-02 23:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann, Heiko Voigt
2014/1/2 Junio C Hamano <gitster@pobox.com>:
> Francesco Pretto <ceztko@gmail.com> writes:
>
>> by default "git submodule" performs its add or update operations on a detached
>> HEAD. This works well when using an existing full-fledged/indipendent project as
>> the submodule, as there's less frequent need to update it or commit back
>> changes. When the submodule is actually a large portion of shareable code
>> between different projects, and the superproject needs to track very closely
>> the evolution of the submodule (or the other way around), I feel more confortable
>> to reattach the HEAD of the submodule with an existing branch.
>
> I may be missing some fundamental assumption in your mind when you
> did this change, but in a workflow where somebody wants submodule
> checkout to be on branches (as opposed to detached), wouldn't it
> make more sense not to detach in the first place, rather than
> introducing yet another option to "re-attach"? The documentation of
> "submodule update" seems to say that its "merge" and "rebase" modes
> do not detach in the first place (and it alludes to "--checkout" but
> it is unclear what it does purely from the documentation, as "git
> submodule --help" does not even list it as one of the options).
>
Thanks for commenting: because of more checking I just spotted some
unuseful code in my patch in cmd_add() function. In short: it seems to
me "git submodule update" doesn't allow to work with attached an HEAD
(unless it is *manually* attached, as I regularly do). My feeling is
the documentation of "merge", "rebase" update commands is inaccurate
and doesn't really reflect what happen when adding a submodule with
"add" or cloning it for the first time with "update". You can look at
the following conditionals in the current code in git-submodule.sh:
## cmd_add()
case "$branch" in
'') git checkout -f -q ;;
?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
esac
## cmd_update()
# Is this something we just cloned?
case ";$cloned_modules;" in
*";$name;"*)
# then there is no local change to integrate
update_module= ;;
esac
This means that the "add" command will always checkout an *attached*
HEAD but at the first clone of a different user the checkout will
resolve in "git checkout <sha1>", always producing a *detached* HEAD
and resulting in inconsistent HEAD state between who added the
submodule with "add" and who cloned it with "update". Subsequent
"merge" or "rebase" operations won't change this fact, the HEAD will
remain detached. The following test case confirms this, unless I did
something wrong:
-----------------------------------------------------------------
parentdir=$(pwd -P)
submodurl1=$(pwd -P)/repo1
submodurl2=$(pwd -P)/repo2
repourl=$(pwd -P)/repo
# Create repo to be added with submodules
cd $parentdir
mkdir repo
cd repo
git init
git config receive.denyCurrentBranch ignore
echo a >a
git add a
git commit -m "repo commit 1"
# Create repo repo1 to be used as submodule
cd $parentdir
mkdir repo1
cd repo1
git init
git config receive.denyCurrentBranch ignore
echo a >a
git add a
git commit -m "repo1 commit 1"
# Create repo repo2 to be used as submodule
cd $parentdir
mkdir repo2
cd repo2
git init
git config receive.denyCurrentBranch ignore
echo a >a
git add a
git commit -m "repo2 commit 1"
# Clone repo to test "git submodule update"
cd $parentdir
git clone "$repourl" repoclone
#
## Adding submodule with update "rebase", not specifying a <branch>
#
cd $parentdir/repo
git submodule add "$submodurl1" submod1
git config -f .gitmodules submodule.submod1.ignore all
git config -f .gitmodules submodule.submod1.update rebase
git commit -m "Added submodule"
###### repo/submod1 has an attached HEAD ######
cd $parentdir/repoclone
git pull
git submodule init
git submodule update
###### repoclone/submod1 has a detached HEAD --> note the inconsistency ######
#
## Adding submodule with update "rebase", specifying a <branch>
#
cd $parentdir/repo
git submodule add --branch master "$submodurl2" submod2
git config -f .gitmodules submodule.submod2.ignore all
git config -f .gitmodules submodule.submod2.update rebase
git add .
git commit -m "Added submodule"
###### repo/submod2 has a attached HEAD ######
cd $parentdir/repoclone
git pull
git submodule init
git submodule update --remote
###### repoclone/submod2 has a detached HEAD --> note the inconsistency ######
#
## Adding something to submod2 and test update "rebase" on repoclone
#
cd $parentdir/repo1
echo b >b
git add b
git commit -m "repo1 commit 2"
cd $parentdir/repoclone
git submodule update --remote
###### repoclone/submod1 has still a detached HEAD ######
-----------------------------------------------------------------
> And if there is a good reason why detaching to update and then
> (perhaps after verifying the result or cleaning it up? I dunno what
> the expected use case is, so I am purely guessing) attaching the
> result to a specific branch in separate steps, does it make sense to
> give "--attach" option to "update" in the first place? That makes
> the whole thing into a single step, not giving the user a chance to
> do anything in between, which I am guessing is the whole point of
> your not using the existing "do not detach, work on a branch" modes.
>
1) The "--attach" option in the "add" git submodule command is my
contribution to have the "attached" behavior by default for cloning
users, because it's not possible to obtain it by just setting the
update command to "merge" or "rebase";
2) The "--attach" and "--detach" switches for the "update" command are
needed just to override in the command line the setting of
"submodule.<module>.attach" (or its absence of value). Of course not
many users will need to use these switche. The others will just use
the provided "submodule.<module>.attach" value and issue "git update"
(or "git init", when needed to update properties).
Concluding, my point is that at the current state submodules in git
seem to be flawed because of the inconsistent HEAD state between "add"
and "update" users. With my patch applied the attached HEAD behavior
would be fully supported. At some point "git submodule add" (without
the "--attached" switch) could be also modified to produce a detached
HEAD by default, removing any remaining inconsistency.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH/RFC] Introduce git submodule add|update --attach
2014-01-02 23:42 ` Francesco Pretto
@ 2014-01-03 0:26 ` Francesco Pretto
2014-01-03 8:49 ` Francesco Pretto
1 sibling, 0 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-03 0:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann, Heiko Voigt
2014/1/3 Francesco Pretto <ceztko@gmail.com>:
> Concluding, my point is that at the current state submodules in git
> seem to be flawed because of the inconsistent HEAD state between "add"
> and "update" users. With my patch applied the attached HEAD behavior
> would be fully supported. At some point "git submodule add" (without
> the "--attached" switch) could be also modified to produce a detached
> HEAD by default, removing any remaining inconsistency.
>
Also consider that ultimately my desired behavior for submodules is
the following:
1) I'd like cloning users to have an attached HEAD by default when
doing "git submodule update";
2) when using an attached HEAD, I'd like "git submodule update" to
also imply "--remote".
An alternative approach would be, for example, make "git submodule
update" honor the current documentation about the behavior of "merge"
and "rebase" update operations, if confirmed to be wrong, really
keeping the HEAD attached. That would be a breaking change, but at
least it would reflect currently documented behavior. I prefer my
original approach, because it adds more feasibility and it's not
breaking in the short time, but I'm open to that and other solutions.
Please let me know, what do you think about it.
Thank you,
Francesco
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH/RFC] Introduce git submodule add|update --attach
2014-01-02 23:42 ` Francesco Pretto
2014-01-03 0:26 ` Francesco Pretto
@ 2014-01-03 8:49 ` Francesco Pretto
2014-01-03 18:06 ` [PATCH] submodule: Respect reqested branch on all clones W. Trevor King
2014-01-05 2:50 ` [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command Francesco Pretto
1 sibling, 2 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-03 8:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann, Heiko Voigt
2014/1/3 Francesco Pretto <ceztko@gmail.com>:
> Concluding, my point is that at the current state submodules in git
> seem to be flawed because of the inconsistent HEAD state between "add"
> and "update" users. With my patch applied the attached HEAD behavior
> would be fully supported. At some point "git submodule add" (without
> the "--attached" switch) could be also modified to produce a detached
> HEAD by default, removing any remaining inconsistency.
Junio, please let me amend this affirmation as it's inaccurate.
According to the current *upstream* features this should the supported
use case for submodules:
- there's a maintainer "add" user that adds the submodule. He will
need to track the upstream submodule revision sha1, so he will clone
the repository with an *attached* HEAD;
- there's a developer "update" use that just clone the submodule
repository and track the sha1 decided by the maintainer "add" user. He
won't need to track upstream submodule revision sha1 so cloning the
repository with a *detached* HEAD. Subsequent "merge" or "rebase"
update operations will keep the HEAD detached.
We should *not* modify/break this default workflow in any way.
The current documentation seems to be misleading when saying that
"This [the update command] will make the submodules HEAD be detached
**unless** --rebase or --merge is specified", as it seems to imply
that the update operation will result in a repository with the HEAD
attached. The repository will be indeed updated merging changes, but
the HEAD will stay detached.
Now, the use case I would like git to support is this:
- there's a maintainer "add" user that adds the submodule. He won't
track the upstream submodule revision sha1, so
"submodule.<module>.ignore" will be set to "all". He will still clone
the repository with an *attached* HEAD;
- there's a developer "update" user. He will clone the submodule
repository with an *attached* HEAD. Subsequent "merge" or "rebase"
update operations will keep the HEAD attached.
To fully support this workflow in my patch I want to:
- introduce a "submodule.<module>.attach" property so "update" users
will clone the submodule repository with an attached HEAD;
- introduce "--attach|--dettach" switches to "update" commmant to
eventually override "submodule.<module>.attach" property value in the
command line;
- introduce "--attach" (but better rename it to "--keep-attached" or
something else) switch to the "add" operation. This "--keep-attached"
will:
* set "submodule.<module>.attach" to true;
* set "submodule.<module>.ignore" to all.
Being the workflow complementary, and the behavior fully optional, I
think the proposed feature should be solid. Give me some time to
produce an improved patch and let see if I can convince you.
Regards,
Francesco
^ permalink raw reply [flat|nested] 144+ messages in thread
* [PATCH] submodule: Respect reqested branch on all clones
2014-01-03 8:49 ` Francesco Pretto
@ 2014-01-03 18:06 ` W. Trevor King
2014-01-04 22:09 ` Heiko Voigt
2014-01-05 3:53 ` Francesco Pretto
2014-01-05 2:50 ` [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command Francesco Pretto
1 sibling, 2 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-03 18:06 UTC (permalink / raw)
To: Git
Cc: Francesco Pretto, Junio C Hamano, Jens Lehmann, Heiko Voigt,
W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
The previous code only checked out the requested branch in cmd_add.
This commit moves the branch-checkout logic into module_clone, where
it can be shared by cmd_add and cmd_update. I also update the initial
checkout command to use 'rebase' to preserve branches setup during
module_clone.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
On Fri, Jan 03, 2014 at 09:49:01AM +0100, Francesco Pretto wrote:
> - there's a developer "update" user. He will clone the submodule
> repository with an *attached* HEAD. Subsequent "merge" or "rebase"
> update operations will keep the HEAD attached.
'merge' and 'rebase' updates don't change the HEAD attachment.
Branches stay branches and detached HEADs stay detached. If you've
moved away from the 'checkout' update mechanism, the only thing you
still need is a way to get an initial checkout on a branch. This
should do it (I can add tests if folks like the general approach).
git-submodule.sh | 30 +++++++++++++++++-------------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 2979197..e2e5a6c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -253,6 +253,7 @@ module_clone()
url=$3
reference="$4"
depth="$5"
+ branch="$6"
quiet=
if test -n "$GIT_QUIET"
then
@@ -306,7 +307,14 @@ 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")
+ (
+ clear_local_git_env
+ cd "$sm_path" &&
+ GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
+ if test -n "$branch"; then
+ git checkout -f -q -B "$branch" "origin/$branch" && echo "checked out $branch"
+ fi
+ ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
}
isnumber()
@@ -469,16 +477,7 @@ Use -f if you really want to add it." >&2
echo "$(eval_gettext "Reactivating local git directory for submodule '\$sm_name'.")"
fi
fi
- module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" || exit
- (
- clear_local_git_env
- cd "$sm_path" &&
- # ash fails to wordsplit ${branch:+-b "$branch"...}
- case "$branch" in
- '') git checkout -f -q ;;
- ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
- esac
- ) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
+ module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" "$branch" || exit
fi
git config submodule."$sm_name".url "$realrepo"
@@ -815,7 +814,7 @@ Maybe you want to use 'update --init'?")"
if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
then
- module_clone "$sm_path" "$name" "$url" "$reference" "$depth" || exit
+ module_clone "$sm_path" "$name" "$url" "$reference" "$depth" "$branch" || exit
cloned_modules="$cloned_modules;$name"
subsha1=
else
@@ -861,7 +860,12 @@ Maybe you want to use 'update --init'?")"
case ";$cloned_modules;" in
*";$name;"*)
# then there is no local change to integrate
- update_module= ;;
+ if test -n "$branch"; then
+ update_module="!git reset --hard -q"
+ else
+ update_module=
+ fi
+ ;;
esac
must_die_on_failure=
--
1.8.5.2.gaa5d535.dirty
^ permalink raw reply related [flat|nested] 144+ messages in thread
* Re: [PATCH] submodule: Respect reqested branch on all clones
2014-01-03 18:06 ` [PATCH] submodule: Respect reqested branch on all clones W. Trevor King
@ 2014-01-04 22:09 ` Heiko Voigt
2014-01-04 22:54 ` W. Trevor King
2014-01-05 3:53 ` Francesco Pretto
1 sibling, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-04 22:09 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
Hi,
On Fri, Jan 03, 2014 at 10:06:11AM -0800, W. Trevor King wrote:
> From: "W. Trevor King" <wking@tremily.us>
>
> The previous code only checked out the requested branch in cmd_add.
> This commit moves the branch-checkout logic into module_clone, where
> it can be shared by cmd_add and cmd_update. I also update the initial
> checkout command to use 'rebase' to preserve branches setup during
> module_clone.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
>
> On Fri, Jan 03, 2014 at 09:49:01AM +0100, Francesco Pretto wrote:
> > - there's a developer "update" user. He will clone the submodule
> > repository with an *attached* HEAD. Subsequent "merge" or "rebase"
> > update operations will keep the HEAD attached.
>
> 'merge' and 'rebase' updates don't change the HEAD attachment.
> Branches stay branches and detached HEADs stay detached. If you've
> moved away from the 'checkout' update mechanism, the only thing you
> still need is a way to get an initial checkout on a branch. This
> should do it (I can add tests if folks like the general approach).
>
> git-submodule.sh | 30 +++++++++++++++++-------------
> 1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 2979197..e2e5a6c 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -253,6 +253,7 @@ module_clone()
> url=$3
> reference="$4"
> depth="$5"
> + branch="$6"
> quiet=
> if test -n "$GIT_QUIET"
> then
> @@ -306,7 +307,14 @@ 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")
Why should this line be removed? Is it not needed for correct
worktree <-> repo linking of submodules?
> + (
> + clear_local_git_env
> + cd "$sm_path" &&
> + GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
> + if test -n "$branch"; then
> + git checkout -f -q -B "$branch" "origin/$branch" && echo "checked out $branch"
> + fi
> + ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
> }
>
> isnumber()
> @@ -469,16 +477,7 @@ Use -f if you really want to add it." >&2
> echo "$(eval_gettext "Reactivating local git directory for submodule '\$sm_name'.")"
> fi
> fi
> - module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" || exit
> - (
> - clear_local_git_env
> - cd "$sm_path" &&
> - # ash fails to wordsplit ${branch:+-b "$branch"...}
> - case "$branch" in
> - '') git checkout -f -q ;;
> - ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
> - esac
> - ) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
> + module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" "$branch" || exit
> fi
> git config submodule."$sm_name".url "$realrepo"
>
> @@ -815,7 +814,7 @@ Maybe you want to use 'update --init'?")"
>
> if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
> then
> - module_clone "$sm_path" "$name" "$url" "$reference" "$depth" || exit
> + module_clone "$sm_path" "$name" "$url" "$reference" "$depth" "$branch" || exit
> cloned_modules="$cloned_modules;$name"
> subsha1=
> else
> @@ -861,7 +860,12 @@ Maybe you want to use 'update --init'?")"
> case ";$cloned_modules;" in
> *";$name;"*)
> # then there is no local change to integrate
> - update_module= ;;
> + if test -n "$branch"; then
> + update_module="!git reset --hard -q"
Does that not put the user in danger of loosing changes?
I am wondering if we should maybe take a little different approach:
If submodule.<name>.branch is configured:
git submodule update
will checkout the configured branch instead of the sha1? Maybe something like
this (untested):
diff --git a/git-submodule.sh b/git-submodule.sh
index 2677f2e..eca519a 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -903,7 +903,13 @@ Maybe you want to use 'update --init'?")"
;;
esac
- if (clear_local_git_env; cd "$sm_path" && $command "$sha1")
+ revision="$sha1"
+ if test -n "$branch"
+ then
+ revision="$branch"
+ fi
+
+ if (clear_local_git_env; cd "$sm_path" && $command "$revision")
then
say "$say_msg"
elif test -n "$must_die_on_failure"
Then we do not need to write a command configuration into the local repository
configuration. If I understand the OP intention correctly, that should solve the
use-case.
Cheers Heiko
^ permalink raw reply related [flat|nested] 144+ messages in thread
* Re: [PATCH] submodule: Respect reqested branch on all clones
2014-01-04 22:09 ` Heiko Voigt
@ 2014-01-04 22:54 ` W. Trevor King
2014-01-05 0:39 ` Heiko Voigt
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-04 22:54 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
[-- Attachment #1: Type: text/plain, Size: 2293 bytes --]
On Sat, Jan 04, 2014 at 11:09:15PM +0100, Heiko Voigt wrote:
> On Fri, Jan 03, 2014 at 10:06:11AM -0800, W. Trevor King wrote:
> > @@ -306,7 +307,14 @@ 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")
>
> Why should this line be removed? Is it not needed for correct
> worktree <-> repo linking of submodules?
>
> > + (
> > + clear_local_git_env
> > + cd "$sm_path" &&
> > + GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
> > + if test -n "$branch"; then
> > + git checkout -f -q -B "$branch" "origin/$branch" && echo "checked out $branch"
> > + fi
> > + ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
> > }
It's not removed, just merged with the branch manipulation that also
happens in a clean local environment in $sm_path. Spawning two
sequential subshells with the same setup seemed like overkill.
> > @@ -861,7 +860,12 @@ Maybe you want to use 'update --init'?")"
> > case ";$cloned_modules;" in
> > *";$name;"*)
> > # then there is no local change to integrate
> > - update_module= ;;
> > + if test -n "$branch"; then
> > + update_module="!git reset --hard -q"
>
> Does that not put the user in danger of loosing changes?
No, because this is only happens for just-cloned modules. The user
hasn't had time to make local changes yet.
> If submodule.<name>.branch is configured:
>
> git submodule update
>
> will checkout the configured branch instead of the sha1?
The use case described by Francesco, a submodule maintainer Alice sets
up the submodule, which downstream developer Bob want to checkout to a
branch. I think that matching the exact commit specified by Alice in
Bob's checkout is important, even if the upstream developer Charlie
has advanced the referenced branch in the meantime. Shifting the
referenced submodule commit should be an explicit decision made by
Alice, not a clone-time accident for Bob.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [PATCH] submodule: Respect reqested branch on all clones
2014-01-04 22:54 ` W. Trevor King
@ 2014-01-05 0:39 ` Heiko Voigt
2014-01-05 1:08 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-05 0:39 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
On Sat, Jan 04, 2014 at 02:54:01PM -0800, W. Trevor King wrote:
> On Sat, Jan 04, 2014 at 11:09:15PM +0100, Heiko Voigt wrote:
> > On Fri, Jan 03, 2014 at 10:06:11AM -0800, W. Trevor King wrote:
> > > @@ -306,7 +307,14 @@ 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")
> >
> > Why should this line be removed? Is it not needed for correct
> > worktree <-> repo linking of submodules?
> >
> > > + (
> > > + clear_local_git_env
> > > + cd "$sm_path" &&
> > > + GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
> > > + if test -n "$branch"; then
> > > + git checkout -f -q -B "$branch" "origin/$branch" && echo "checked out $branch"
> > > + fi
> > > + ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
> > > }
>
> It's not removed, just merged with the branch manipulation that also
> happens in a clean local environment in $sm_path. Spawning two
> sequential subshells with the same setup seemed like overkill.
Ah ok, thanks. For some reason I overlooked that.
> > > @@ -861,7 +860,12 @@ Maybe you want to use 'update --init'?")"
> > > case ";$cloned_modules;" in
> > > *";$name;"*)
> > > # then there is no local change to integrate
> > > - update_module= ;;
> > > + if test -n "$branch"; then
> > > + update_module="!git reset --hard -q"
> >
> > Does that not put the user in danger of loosing changes?
>
> No, because this is only happens for just-cloned modules. The user
> hasn't had time to make local changes yet.
Ah ok I see. But why the reset then? Doesn't the earlier git checkout in your
patch take care of checking out the branch and thus update to the right
revision?
> > If submodule.<name>.branch is configured:
> >
> > git submodule update
> >
> > will checkout the configured branch instead of the sha1?
>
> The use case described by Francesco, a submodule maintainer Alice sets
> up the submodule, which downstream developer Bob want to checkout to a
> branch. I think that matching the exact commit specified by Alice in
> Bob's checkout is important, even if the upstream developer Charlie
> has advanced the referenced branch in the meantime. Shifting the
> referenced submodule commit should be an explicit decision made by
> Alice, not a clone-time accident for Bob.
But from what I understand of this part of Francesco's use-case description:
> # Developer
> $ git pull
> $ git submodule init
> $ git submodule update --remote
> $ cd <path>
> $ branch="$(git config -f ..\.gitmodules submodule.common.branch)"; git checkout $branch
Is that he wants to allow the developer to switch to following a branch instead
of an exact sha1 while some extension in the common module is still under
development. That makes it easier to develop in parallel in the submodule and
the superproject because you do not need to update the sha1 all the time.
E.g. its likely that changes have to be reviewed and cleaned up in the
submodule first until they can be merged to the master branch there. During
this time the developer follows the branch.
Once the submodule review is finished the superproject branch can switch back
to the exact model again (because the submodule will not change anymore) and
finish its implementation there.
Matching the exact commit and checking out the branch only if it points to that
exact commit does not really help the developer in this use-case. But I am only
guessing from my experience with development of features in submodule.
Cheers Heiko
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH] submodule: Respect reqested branch on all clones
2014-01-05 0:39 ` Heiko Voigt
@ 2014-01-05 1:08 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-05 1:08 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
[-- Attachment #1: Type: text/plain, Size: 4045 bytes --]
On Sun, Jan 05, 2014 at 01:39:22AM +0100, Heiko Voigt wrote:
> On Sat, Jan 04, 2014 at 02:54:01PM -0800, W. Trevor King wrote:
> > On Sat, Jan 04, 2014 at 11:09:15PM +0100, Heiko Voigt wrote:
> > > On Fri, Jan 03, 2014 at 10:06:11AM -0800, W. Trevor King wrote:
> > > > @@ -861,7 +860,12 @@ Maybe you want to use 'update --init'?")"
> > > > case ";$cloned_modules;" in
> > > > *";$name;"*)
> > > > # then there is no local change to integrate
> > > > - update_module= ;;
> > > > + if test -n "$branch"; then
> > > > + update_module="!git reset --hard -q"
> > >
> > > Does that not put the user in danger of loosing changes?
> >
> > No, because this is only happens for just-cloned modules. The user
> > hasn't had time to make local changes yet.
>
> Ah ok I see. But why the reset then? Doesn't the earlier git
> checkout in your patch take care of checking out the branch and thus
> update to the right revision?
The reset avoids a detached HEAD. With an empty $update_module, the
following case block will setup:
command="git checkout $subforce -q"
which is later called with:
$command "$sha1"
That's going to give you a detached HEAD. The new code sets up:
command="git reset --hard -q"
which will keep you on the branch checked out in module_clone().
> > > If submodule.<name>.branch is configured:
> > >
> > > git submodule update
> > >
> > > will checkout the configured branch instead of the sha1?
> >
> > The use case described by Francesco, a submodule maintainer Alice
> > sets up the submodule, which downstream developer Bob want to
> > checkout to a branch. I think that matching the exact commit
> > specified by Alice in Bob's checkout is important, even if the
> > upstream developer Charlie has advanced the referenced branch in
> > the meantime. Shifting the referenced submodule commit should be
> > an explicit decision made by Alice, not a clone-time accident for
> > Bob.
>
> But from what I understand of this part of Francesco's use-case
> description:
>
> > # Developer
> > $ git pull
> > $ git submodule init
> > $ git submodule update --remote
> > $ cd <path>
> > $ branch="$(git config -f ..\.gitmodules submodule.common.branch)"; git checkout $branch
>
> Is that he wants to allow the developer to switch to following a
> branch instead of an exact sha1 while some extension in the common
> module is still under development. That makes it easier to develop
> in parallel in the submodule and the superproject because you do not
> need to update the sha1 all the time.
I'll wait for Francesco to clarify his use case. All my patch does is
replace the manual:
$ cd <path>
$ branch="$(git config -f ..\.gitmodules submodule.common.branch)"; git checkout $branch
with an automatic (on update):
$ branch="$(git config -f .gitmodules submodule.${name}.branch)";
$ cd "$path"
$ git checkout -f -q -B "$branch" "origin/$branch"
$ git reset --hard -q "$sha"
when submodule.<name>.branch is configured. Whether that last bit is
desirable or not is debatable. If you *do* want to float the
submodule past the commit blessed by Alice, it's easy to add a manual:
$ git submodule update --remote --rebase "$path"
If we drop the trailing reset (to float the checkout), it's harder to
rewind to the commit blessed by Alice, because distinguising between:
a) locally added stuff that we want to merge/rebase onto Alice's $sha,
and
b) advancements from the automatic float that we *don't* want to
merge/rebase onto Alice's $sha.
is difficult/impossible. If you use the --checkout strategy (there
are no local commits), you can use:
$ git submodule update --checkout "$path"
but you'd still need to update the branch references to point to the
that particular commit.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command
@ 2014-01-05 2:50 ` Francesco Pretto
2014-01-05 2:50 ` [PATCH 2/2] Introduce git submodule attached update Francesco Pretto
` (2 more replies)
0 siblings, 3 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-05 2:50 UTC (permalink / raw)
To: git; +Cc: Francesco Pretto
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'"
+ ;;
+ esac
fi
displaypath=$(relative_path "$prefix$sm_path")
--
1.8.5.2.230.g032cd47.dirty
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH 2/2] Introduce git submodule attached update
2014-01-05 2:50 ` [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command Francesco Pretto
@ 2014-01-05 2:50 ` Francesco Pretto
2014-01-05 19:55 ` Francesco Pretto
2014-01-05 20:33 ` Heiko Voigt
2014-01-05 20:20 ` [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command Heiko Voigt
2014-01-05 20:44 ` W. Trevor King
2 siblings, 2 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-05 2:50 UTC (permalink / raw)
To: git; +Cc: Francesco Pretto
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
^ permalink raw reply related [flat|nested] 144+ messages in thread
* Re: [PATCH] submodule: Respect reqested branch on all clones
2014-01-03 18:06 ` [PATCH] submodule: Respect reqested branch on all clones W. Trevor King
2014-01-04 22:09 ` Heiko Voigt
@ 2014-01-05 3:53 ` Francesco Pretto
2014-01-05 16:17 ` [RFC v2] submodule: Respect requested " W. Trevor King
1 sibling, 1 reply; 144+ messages in thread
From: Francesco Pretto @ 2014-01-05 3:53 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Junio C Hamano, Jens Lehmann, Heiko Voigt
Thanks for adding your contribute. My comments below:
2014/1/3 W. Trevor King <wking@tremily.us>:
>
> The previous code only checked out the requested branch in cmd_add.
> This commit moves the branch-checkout logic into module_clone, where
> it can be shared by cmd_add and cmd_update. I also update the initial
> checkout command to use 'rebase' to preserve branches setup during
> module_clone.
> [...]
> @@ -306,7 +307,14 @@ 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")
> + (
> + clear_local_git_env
> + cd "$sm_path" &&
> + GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
> + if test -n "$branch"; then
> + git checkout -f -q -B "$branch" "origin/$branch" && echo "checked out $branch"
> + fi
> + ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
> }
If I understand it correctly, looking at your intervention in
module_clone and cmd_update, when "submodule.<module>.branch" is set
during "update" the resulting first clone will always be a branch
checkout (cause $branch is filled with "branch" property). I believe
this will break a lot of tests, as the the documentation says that in
this configuration the HEAD should be detached. Also it could break
some users that rely on the current behavior.
^ permalink raw reply [flat|nested] 144+ messages in thread
* [RFC v2] submodule: Respect requested branch on all clones
2014-01-05 3:53 ` Francesco Pretto
@ 2014-01-05 16:17 ` W. Trevor King
2014-01-05 19:48 ` Heiko Voigt
` (2 more replies)
0 siblings, 3 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-05 16:17 UTC (permalink / raw)
To: Git
Cc: Francesco Pretto, Junio C Hamano, Jens Lehmann, Heiko Voigt,
W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
The previous code only checked out the requested branch in cmd_add.
This commit moves the branch-checkout logic into module_clone, where
it can be shared by cmd_add and cmd_update. I also update the initial
checkout command to use 'rebase' to preserve branches setup during
module_clone.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Changes since v1:
* Fix a 'reqested' -> 'requested' typo in the subject/summary.
* Restore a post-clone 'git checkout -f -q' for the empty-branch case
in module_clone().
* Distinguish between $branch (which defaults to 'master') and a new
$config_branch (which defaults to empty) in cmd_update
After these fixes, all the existing submodule tests pass. If we want
to merge this, we'd still want new tests that demonstrate the new
functionality.
On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote:
> If I understand it correctly, looking at your intervention in
> module_clone and cmd_update, when "submodule.<module>.branch" is set
> during "update" the resulting first clone will always be a branch
> checkout (cause $branch is filled with "branch" property).
That's correct.
> I believe this will break a lot of tests,
Thanks for prompting me to run the tests. This v2 now passes all of
the current submodule tests, and the functionality actually matches my
earlier descriptions of it ;).
> as the the documentation says that in this configuration the HEAD
> should be detached.
The current Documentation/git-submodule.txt has:
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`.
It's not clear if this refers to the initial-clone update, future
post-clone updates, or both. Ideally, the behavior should be the
same, but in the initial-clone case we don't have an existing
checked-out branch to work with.
> Also it could break some users that rely on the current behavior.
The current code always has a detached HEAD after an initial-clone
update, regardless of submodule.<name>.update, which doesn't match
those docs either. Adding a check to only checkout
submodule.<name>.branch if submodule.<name>.update was 'rebase',
'merge', or 'none' would be easy, but I don't think that makes much
sense. I can't see any reason for folks who specify
submodule.<name>.branch to prefer a detached HEAD over a local branch
matching the remote branch's name. If they prefer checkout updates,
the first such update will return them to a detached HEAD. If they
prefer merge/rebase updates, future updates will keep them on the same
branch. All my commit does is setup that initial branch for folks who
get the submodule via 'update', in the same way it's currently setup
for folks who get the submodule via 'add'.
Cheers,
Trevor
git-submodule.sh | 34 ++++++++++++++++++++--------------
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 2979197..167d4fa 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -253,6 +253,7 @@ module_clone()
url=$3
reference="$4"
depth="$5"
+ branch="$6"
quiet=
if test -n "$GIT_QUIET"
then
@@ -306,7 +307,15 @@ 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")
+ (
+ clear_local_git_env
+ cd "$sm_path" &&
+ GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
+ case "$branch" in
+ '') git checkout -f -q ;;
+ ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
+ esac
+ ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
}
isnumber()
@@ -469,16 +478,7 @@ Use -f if you really want to add it." >&2
echo "$(eval_gettext "Reactivating local git directory for submodule '\$sm_name'.")"
fi
fi
- module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" || exit
- (
- clear_local_git_env
- cd "$sm_path" &&
- # ash fails to wordsplit ${branch:+-b "$branch"...}
- case "$branch" in
- '') git checkout -f -q ;;
- ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
- esac
- ) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
+ module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" "$branch" || exit
fi
git config submodule."$sm_name".url "$realrepo"
@@ -787,7 +787,8 @@ cmd_update()
fi
name=$(module_name "$sm_path") || exit
url=$(git config submodule."$name".url)
- branch=$(get_submodule_config "$name" branch master)
+ config_branch=$(get_submodule_config "$name" branch)
+ branch="${config_branch:-master}"
if ! test -z "$update"
then
update_module=$update
@@ -815,7 +816,7 @@ Maybe you want to use 'update --init'?")"
if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
then
- module_clone "$sm_path" "$name" "$url" "$reference" "$depth" || exit
+ module_clone "$sm_path" "$name" "$url" "$reference" "$depth" "$config_branch" || exit
cloned_modules="$cloned_modules;$name"
subsha1=
else
@@ -861,7 +862,12 @@ Maybe you want to use 'update --init'?")"
case ";$cloned_modules;" in
*";$name;"*)
# then there is no local change to integrate
- update_module= ;;
+ if test -n "$config_branch"; then
+ update_module="!git reset --hard -q"
+ else
+ update_module=
+ fi
+ ;;
esac
must_die_on_failure=
--
1.8.4.100.gd81c160.dirty
^ permalink raw reply related [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-05 16:17 ` [RFC v2] submodule: Respect requested " W. Trevor King
@ 2014-01-05 19:48 ` Heiko Voigt
2014-01-05 21:24 ` W. Trevor King
2014-01-05 21:27 ` Francesco Pretto
2014-01-07 18:15 ` Junio C Hamano
2 siblings, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-05 19:48 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
On Sun, Jan 05, 2014 at 08:17:00AM -0800, W. Trevor King wrote:
> From: "W. Trevor King" <wking@tremily.us>
>
> The previous code only checked out the requested branch in cmd_add.
> This commit moves the branch-checkout logic into module_clone, where
> it can be shared by cmd_add and cmd_update. I also update the initial
> checkout command to use 'rebase' to preserve branches setup during
> module_clone.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Changes since v1:
> * Fix a 'reqested' -> 'requested' typo in the subject/summary.
> * Restore a post-clone 'git checkout -f -q' for the empty-branch case
> in module_clone().
> * Distinguish between $branch (which defaults to 'master') and a new
> $config_branch (which defaults to empty) in cmd_update
>
> After these fixes, all the existing submodule tests pass. If we want
> to merge this, we'd still want new tests that demonstrate the new
> functionality.
I think this patch is going in the right direction. Making add() and
update() do the same is the right thing to do.
I would still like a complete description of Francesco's use case
though. Francesco: Could you give us a short description about what
exactly is your use-case? And please ignore all technical details how we
are going to implement this. I would like to know how, in an ideal
world, you would expect git to behave. Do you really only care about
git submodule add
and the *initial*
git submodule update
?
What happens if a developer already has the submodule and wants to work
on a feature?
> On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote:
> > If I understand it correctly, looking at your intervention in
> > module_clone and cmd_update, when "submodule.<module>.branch" is set
> > during "update" the resulting first clone will always be a branch
> > checkout (cause $branch is filled with "branch" property).
>
> That's correct.
>
> > I believe this will break a lot of tests,
>
> Thanks for prompting me to run the tests. This v2 now passes all of
> the current submodule tests, and the functionality actually matches my
> earlier descriptions of it ;).
>
> > as the the documentation says that in this configuration the HEAD
> > should be detached.
>
> The current Documentation/git-submodule.txt has:
>
> 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`.
>
> It's not clear if this refers to the initial-clone update, future
> post-clone updates, or both. Ideally, the behavior should be the
> same, but in the initial-clone case we don't have an existing
> checked-out branch to work with.
I do not think that its actually important to end up with a detached
HEAD. The documentation just states it because in most cases there is no
other option. But I do not think anything will break if a branch points
to the exact sha1 we would checkout and we checkout the branch instead.
> > Also it could break some users that rely on the current behavior.
>
> The current code always has a detached HEAD after an initial-clone
> update, regardless of submodule.<name>.update, which doesn't match
> those docs either. Adding a check to only checkout
> submodule.<name>.branch if submodule.<name>.update was 'rebase',
> 'merge', or 'none' would be easy, but I don't think that makes much
> sense. I can't see any reason for folks who specify
> submodule.<name>.branch to prefer a detached HEAD over a local branch
> matching the remote branch's name. If they prefer checkout updates,
> the first such update will return them to a detached HEAD. If they
> prefer merge/rebase updates, future updates will keep them on the same
> branch. All my commit does is setup that initial branch for folks who
> get the submodule via 'update', in the same way it's currently setup
> for folks who get the submodule via 'add'.
I like your goal of putting this logic into one place. But a few things
still could be improved IMO.
> git-submodule.sh | 34 ++++++++++++++++++++--------------
> 1 file changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 2979197..167d4fa 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -253,6 +253,7 @@ module_clone()
> url=$3
> reference="$4"
> depth="$5"
> + branch="$6"
> quiet=
> if test -n "$GIT_QUIET"
> then
> @@ -306,7 +307,15 @@ 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")
> + (
> + clear_local_git_env
> + cd "$sm_path" &&
> + GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
> + case "$branch" in
> + '') git checkout -f -q ;;
> + ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
> + esac
> + ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
> }
>
> isnumber()
> @@ -469,16 +478,7 @@ Use -f if you really want to add it." >&2
> echo "$(eval_gettext "Reactivating local git directory for submodule '\$sm_name'.")"
> fi
> fi
> - module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" || exit
> - (
> - clear_local_git_env
> - cd "$sm_path" &&
> - # ash fails to wordsplit ${branch:+-b "$branch"...}
> - case "$branch" in
> - '') git checkout -f -q ;;
> - ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
> - esac
> - ) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
> + module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" "$branch" || exit
> fi
> git config submodule."$sm_name".url "$realrepo"
>
> @@ -787,7 +787,8 @@ cmd_update()
> fi
> name=$(module_name "$sm_path") || exit
> url=$(git config submodule."$name".url)
> - branch=$(get_submodule_config "$name" branch master)
> + config_branch=$(get_submodule_config "$name" branch)
> + branch="${config_branch:-master}"
> if ! test -z "$update"
> then
> update_module=$update
> @@ -815,7 +816,7 @@ Maybe you want to use 'update --init'?")"
>
> if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
> then
> - module_clone "$sm_path" "$name" "$url" "$reference" "$depth" || exit
> + module_clone "$sm_path" "$name" "$url" "$reference" "$depth" "$config_branch" || exit
In the simple case (update=checkout, no branch specified) with the new
checkout branch stuff in module_clone() this code here ends up calling
checkout twice. First for master and then here later with the sha1.
This feels a little bit double. I would prefer if we skip the checkout
in module_clone() if its not necessary.
How about we move the whole "what to checkout"-decision into one place
instead of having it in update() and moving it from add() into
module_clone() ?
Previously there was not much in add() regarding checkout but since it
seems to grow (and now parts need to be shared between add() and
update()). I would like it if we could move that code into one central
location.
> cloned_modules="$cloned_modules;$name"
> subsha1=
> else
> @@ -861,7 +862,12 @@ Maybe you want to use 'update --init'?")"
> case ";$cloned_modules;" in
> *";$name;"*)
> # then there is no local change to integrate
> - update_module= ;;
> + if test -n "$config_branch"; then
> + update_module="!git reset --hard -q"
If we get here the checkout has already been done. Shouldn't this rather
specify a noop. I.E. like
update_module="!true"
?
Cheers Heiko
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-05 2:50 ` [PATCH 2/2] Introduce git submodule attached update Francesco Pretto
@ 2014-01-05 19:55 ` Francesco Pretto
2014-01-05 20:33 ` Heiko Voigt
1 sibling, 0 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-05 19:55 UTC (permalink / raw)
To: git
Cc: Francesco Pretto, Jens Lehmann, Heiko Voigt, W. Trevor King,
Junio C Hamano
(Hmmpth, forgot signoff...)
To whom it may interest, added some CC.
2014/1/5 Francesco Pretto <ceztko@gmail.com>:
> 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
>
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command
2014-01-05 2:50 ` [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command Francesco Pretto
2014-01-05 2:50 ` [PATCH 2/2] Introduce git submodule attached update Francesco Pretto
@ 2014-01-05 20:20 ` Heiko Voigt
2014-01-05 20:44 ` W. Trevor King
2 siblings, 0 replies; 144+ messages in thread
From: Heiko Voigt @ 2014-01-05 20:20 UTC (permalink / raw)
To: Francesco Pretto; +Cc: git
On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
> 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.
s/unknwon/unknown/
> ---
> 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'"
How about additionally telling the user the current value that is wrong
like this:
echo >&2 "warning: invalid update mode '$update_module' for submodule '$name'"
?
But apart from those minor nits the patch looks good to me.
Cheers Heiko
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-05 2:50 ` [PATCH 2/2] Introduce git submodule attached update Francesco Pretto
2014-01-05 19:55 ` Francesco Pretto
@ 2014-01-05 20:33 ` Heiko Voigt
2014-01-05 21:46 ` Francesco Pretto
2014-01-05 23:22 ` Francesco Pretto
1 sibling, 2 replies; 144+ messages in thread
From: Heiko Voigt @ 2014-01-05 20:33 UTC (permalink / raw)
To: Francesco Pretto; +Cc: git, Jens Lehmann
On Sun, Jan 05, 2014 at 03:50:49AM +0100, Francesco Pretto wrote:
> 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.
Could you please extend the description of your use-case so we can
understand your goal better?
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?
- 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?
- In which situations does the developer or maintainer switch between
your attached/detached mode?
- 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?
- What are these subsequent "merge" or "rebase" update operations? Do
you mean everyone has submodule.name.update configured to merge or
rebase?
Still puzzled.
Cheers Heiko
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command
2014-01-05 2:50 ` [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command Francesco Pretto
2014-01-05 2:50 ` [PATCH 2/2] Introduce git submodule attached update Francesco Pretto
2014-01-05 20:20 ` [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command Heiko Voigt
@ 2014-01-05 20:44 ` W. Trevor King
2014-01-06 16:20 ` Junio C Hamano
2 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-05 20:44 UTC (permalink / raw)
To: Francesco Pretto; +Cc: git, Heiko Voigt
[-- Attachment #1: Type: text/plain, Size: 971 bytes --]
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).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-05 19:48 ` Heiko Voigt
@ 2014-01-05 21:24 ` W. Trevor King
2014-01-05 22:57 ` Heiko Voigt
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-05 21:24 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
[-- Attachment #1: Type: text/plain, Size: 4112 bytes --]
On Sun, Jan 05, 2014 at 08:48:50PM +0100, Heiko Voigt wrote:
> On Sun, Jan 05, 2014 at 08:17:00AM -0800, W. Trevor King wrote:
> > It's not clear if this refers to the initial-clone update, future
> > post-clone updates, or both. Ideally, the behavior should be the
> > same, but in the initial-clone case we don't have an existing
> > checked-out branch to work with.
>
> I do not think that its actually important to end up with a detached
> HEAD. The documentation just states it because in most cases there
> is no other option. But I do not think anything will break if a
> branch points to the exact sha1 we would checkout and we checkout
> the branch instead.
There's no "if the remote-tracking branch points to the exact sha1"
logic in my patch. If submodule.<name>.branch is set, it *always*
creates a new local branch of that name pointing to the exact sha1.
If submodule.<name>.branch is not set, we still create a detached-HEAD
checkout of the exact sha1. Thinking through this more, perhaps the
logic should be:
* If submodule.<name>.update (defaulting to checkout) is checkout,
create a detached HEAD.
* Otherwise, create a new branch submodule.<name>.branch (defaulting
to master).
The motivation is that if submodule.<name>.update is checkout, the
user is unlikely to be developing locally in the submodule, as
subsequent updates would clobber their local commits. Having a
detached HEAD is a helpful "don't develop here" reminder ;). If
submodule.<name>.update is set, the user is likely to be developing
locally, and will probably want a local branch already checked out to
facilitate that.
> > - module_clone "$sm_path" "$name" "$url" "$reference" "$depth" || exit
> > + module_clone "$sm_path" "$name" "$url" "$reference" "$depth" "$config_branch" || exit
>
> In the simple case (update=checkout, no branch specified) with the
> new checkout branch stuff in module_clone() this code here ends up
> calling checkout twice. First for master and then here later with
> the sha1. This feels a little bit double.
There is no guarantee that the remote master and the exact sha1 point
at the same commit. Ideally we'd just clone the exact sha1 in this
case.
> I would prefer if we skip the checkout in module_clone() if its not
> necessary.
When I tried to drop the '' case here:
> > @@ -306,7 +307,15 @@ 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")
> > + (
> > + clear_local_git_env
> > + cd "$sm_path" &&
> > + GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
> > + case "$branch" in
> > + '') git checkout -f -q ;;
> > + ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
> > + esac
> > + ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
> > }
I got test-suite errors that I didn't get to the bottom of. However…
> How about we move the whole "what to checkout"-decision into one place
> instead of having it in update() and moving it from add() into
> module_clone() ?
…this sounds like a good idea to me. However, it would be a more
intrusive change, and there may be conflicts with Francesco's proposed
attach/detach functionality. I'll wait until we have a clearer idea
of where that is headed before I attempt a more complete
consolidation.
> > - update_module= ;;
> > + if test -n "$config_branch"; then
> > + update_module="!git reset --hard -q"
>
> If we get here the checkout has already been done. Shouldn't this
> rather specify a noop. I.E. like
>
> update_module="!true"
We are on a local branch at this point, but not neccessarily pointing
at the gitlinked sha1. The reset here ensures that the new local
branch does indeed point at the gitlinked sha1.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-05 16:17 ` [RFC v2] submodule: Respect requested " W. Trevor King
2014-01-05 19:48 ` Heiko Voigt
@ 2014-01-05 21:27 ` Francesco Pretto
2014-01-05 21:47 ` W. Trevor King
2014-01-06 14:47 ` Heiko Voigt
2014-01-07 18:15 ` Junio C Hamano
2 siblings, 2 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-05 21:27 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Junio C Hamano, Jens Lehmann, Heiko Voigt
2014/1/5 W. Trevor King <wking@tremily.us>:
> On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote:
>> Also it could break some users that rely on the current behavior.
>
> The current code always has a detached HEAD after an initial-clone
> update, regardless of submodule.<name>.update, which doesn't match
> those docs either.
I perfectly agree with you that the documentation is a bit
contradictory with regard to "update" command and detached HEAD.
That's why it's so hard to add a feature and keep the same spirit of
those that coded submodules at first. Also, I think that submodules
didn't get much feedback with regards to these pitfalls because many
people try to setup them, they see that "update" detaches the HEAD and
they think "hmmm, maybe submodules are not what I was looking for".
> Adding a check to only checkout
> submodule.<name>.branch if submodule.<name>.update was 'rebase',
> 'merge', or 'none' would be easy, but I don't think that makes much
> sense. I can't see any reason for folks who specify
> submodule.<name>.branch to prefer a detached HEAD over a local branch
> matching the remote branch's name.
I think the reason is that it still matches the original use case of
submodules devs:
- the maintainer decides the specific commit developers should have;
- developers checkout that commit and don't pull (you can't do "git
pull" in a detached HEAD);
- they optionally get the upstream commit from the specified
"submodule.<name>.branch" with "--remote". They are still in a
detached HEAD and can't do "git pull".
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.
> If they prefer checkout updates,
> the first such update will return them to a detached HEAD. If they
> prefer merge/rebase updates, future updates will keep them on the same
> branch. All my commit does is setup that initial branch for folks who
> get the submodule via 'update', in the same way it's currently setup
> for folks who get the submodule via 'add'.
>
My patch is in the same spirit but wants to obtain the same by being
100% additive and by not altering existing behavior in any way. Also
it covers:
- an "autoremote" behavior when the user wants an attached HEAD: with
your patch "--remote" is still needed to really update the branch with
"git submodule update":
- voluntary reattach/detach the HEAD with command line;
- ff-only merge of changes in the case of "checkout" in an attached
HEAD (doing "git checkout <branch>" is not enough);
- reattach of the HEAD with orphaned commits.
Unfortunately our patches are already a bit colliding. I'll wait for
other comments from git maintainers and let see. Anyway, I'm happy
because things are moving: after this debate git submodules will be
better for sure.
Cheers,
Francesco
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-05 20:33 ` Heiko Voigt
@ 2014-01-05 21:46 ` Francesco Pretto
2014-01-06 14:06 ` Heiko Voigt
2014-01-05 23:22 ` Francesco Pretto
1 sibling, 1 reply; 144+ messages in thread
From: Francesco Pretto @ 2014-01-05 21:46 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann
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?
>
Just in case you missed the first patch iteration[1].
> 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.
Greetings,
Francesco
[1] http://marc.info/?l=git&m=138836829531511&w=2
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-05 21:27 ` Francesco Pretto
@ 2014-01-05 21:47 ` W. Trevor King
2014-01-05 22:01 ` W. Trevor King
2014-01-06 14:47 ` Heiko Voigt
1 sibling, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-05 21:47 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Git, Junio C Hamano, Jens Lehmann, Heiko Voigt
[-- Attachment #1: Type: text/plain, Size: 3735 bytes --]
On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
> 2014/1/5 W. Trevor King:
> > Adding a check to only checkout submodule.<name>.branch if
> > submodule.<name>.update was 'rebase', 'merge', or 'none' would be
> > easy, but I don't think that makes much sense. I can't see any
> > reason for folks who specify submodule.<name>.branch to prefer a
> > detached HEAD over a local branch matching the remote branch's
> > name.
>
> I think the reason is that it still matches the original use case of
> submodules devs:
> - the maintainer decides the specific commit developers should have;
> - developers checkout that commit and don't pull (you can't do "git
> pull" in a detached HEAD);
> - they optionally get the upstream commit from the specified
> "submodule.<name>.branch" with "--remote". They are still in a
> detached HEAD and can't do "git pull".
>
> 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.
You're saying that the detached HEAD is a feature because it breaks
pull? And developers can't be trusted/trained to just not pull
reflexively? I'm not buying that ;). Although I was sad to see
jc/pull-training-wheel dropped and have that discussion stall out [1].
> > If they prefer checkout updates, the first such update will return
> > them to a detached HEAD. If they prefer merge/rebase updates,
> > future updates will keep them on the same branch. All my commit
> > does is setup that initial branch for folks who get the submodule
> > via 'update', in the same way it's currently setup for folks who
> > get the submodule via 'add'.
>
> My patch is in the same spirit but wants to obtain the same by being
> 100% additive and by not altering existing behavior in any way.
My v2 patch doesn't break the current test suite. I'd be surprised if
a change in such peripheral existing behavior as the post clone-update
branch actually break any user code, but I'd be happy to see links
that prove me wrong.
> Also it covers:
> - an "autoremote" behavior when the user wants an attached HEAD:
> with your patch "--remote" is still needed to really update the
> branch with "git submodule update":
> - voluntary reattach/detach the HEAD with command line;
> - ff-only merge of changes in the case of "checkout" in an attached
> HEAD (doing "git checkout <branch>" is not enough);
> - reattach of the HEAD with orphaned commits.
Personally, I don't think autoremote updates are worth the additional
UI complication (hence my alternative patch ;), but I'm open to
discussion on this point. Can you make a case for why and explicit
--remote update is burdensome?
I'm also not entirely clear on the problems avoided or workflows
enhanced via the last two entries. Could you sketch an example
workflow that makes that more obvious?
> Unfortunately our patches are already a bit colliding. I'll wait for
> other comments from git maintainers and let see. Anyway, I'm happy
> because things are moving: after this debate git submodules will be
> better for sure.
+1. I floated my patch as a proof-of-concept for my side of this
debate, but I'm pretty happy with the current setup, so it's hard for
me to imagine submodules getting worse as a result of this ;).
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/236372
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-05 21:47 ` W. Trevor King
@ 2014-01-05 22:01 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-05 22:01 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Git, Junio C Hamano, Jens Lehmann, Heiko Voigt
[-- Attachment #1: Type: text/plain, Size: 2629 bytes --]
On Sun, Jan 05, 2014 at 01:47:52PM -0800, W. Trevor King wrote:
> On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
> > 2014/1/5 W. Trevor King:
> > Also it covers:
> > - an "autoremote" behavior when the user wants an attached HEAD:
> > with your patch "--remote" is still needed to really update the
> > branch with "git submodule update":
> > - voluntary reattach/detach the HEAD with command line;
> > - ff-only merge of changes in the case of "checkout" in an attached
> > HEAD (doing "git checkout <branch>" is not enough);
> > - reattach of the HEAD with orphaned commits.
>
> Personally, I don't think autoremote updates are worth the additional
> UI complication (hence my alternative patch ;), but I'm open to
> discussion on this point. Can you make a case for why and explicit
> --remote update is burdensome?
>
> I'm also not entirely clear on the problems avoided or workflows
> enhanced via the last two entries. Could you sketch an example
> workflow that makes that more obvious?
For example, your original patch [1] claimed a reduction from:
# Maintainer
$ git submodule add --branch "master-project1" <repository> common
$ git commit -m "Added submodule"
$ git config -f .gitmodules submodule.common.ignore all
$ git push
$ cd <path>
$ git checkout "master-project1"
to:
# Maintainer
$ git submodule add --branch "master-project1" --attach <repository> <path>
$ git commit -m "Added submodule"
$ git push
My patch does not effect this maintainer flow at all, but I'm pretty
sure the initial checkout is already automatic:
$ git --version
git version 1.8.3.2
$ cd b/
$ git init
Initialized empty Git repository in /tmp/b/.git/
$ git submodule add --branch master ../a
Cloning into 'a'...
done.
Checking connectivity... done
$ cd a/
$ git branch
* master
You also claimed a reduction from:
# Developer
$ git pull
$ git submodule init
$ git submodule update --remote
$ cd <path>
$ branch="$(git config -f ..\.gitmodules submodule.common.branch)"; git checkout $branch
to:
# Developer
$ git pull
$ git submodule init
$ git submodule update
My patch should cover the developer reduction (auto branch checkout on
the initial cloning update) without confusing the situation with
autofloated updates.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/239799
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-05 21:24 ` W. Trevor King
@ 2014-01-05 22:57 ` Heiko Voigt
2014-01-05 23:39 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-05 22:57 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote:
> On Sun, Jan 05, 2014 at 08:48:50PM +0100, Heiko Voigt wrote:
> > On Sun, Jan 05, 2014 at 08:17:00AM -0800, W. Trevor King wrote:
> > > It's not clear if this refers to the initial-clone update, future
> > > post-clone updates, or both. Ideally, the behavior should be the
> > > same, but in the initial-clone case we don't have an existing
> > > checked-out branch to work with.
> >
> > I do not think that its actually important to end up with a detached
> > HEAD. The documentation just states it because in most cases there
> > is no other option. But I do not think anything will break if a
> > branch points to the exact sha1 we would checkout and we checkout
> > the branch instead.
>
> There's no "if the remote-tracking branch points to the exact sha1"
> logic in my patch.
I know I was more referring to the discussion whether detached HEAD for
submodules is important or not.
> If submodule.<name>.branch is set, it *always*
> creates a new local branch of that name pointing to the exact sha1.
> If submodule.<name>.branch is not set, we still create a detached-HEAD
> checkout of the exact sha1.
Thanks for this clarification. Since the usual usage with --remote is
with a remote-tracking branch, I confused this here. I am not sure
whether blindly creating a local branch from the recorded sha1 is the
right thing to do. In what situations would that be helpful?
At $dayjob we usually use feature branches for our work. So if someone
wants to work in a submodule you simply create a branch at the current
sha1 which you then send out for review.
The reason why one would set a branch option here is to share the
superproject branch with colleagues. He can make sure they can always
fetch and checkout the submodule even though the branch there is still
under cleanup and thus will be rebased often. The commit referenced by
sha1 would not be available to a developer fetching after a rebase.
> Thinking through this more, perhaps the
> logic should be:
>
> * If submodule.<name>.update (defaulting to checkout) is checkout,
> create a detached HEAD.
> * Otherwise, create a new branch submodule.<name>.branch (defaulting
> to master).
Why not trigger the attached state with the submodule.<name>.branch
configuration option? If there is a local branch available use that, if
not the tracking branch (as it is currently). Then a developer can start
working on the branch with:
cd submodule; git checkout -t origin/<branchname>
assuming that submodule update learns some more support for this.
> The motivation is that if submodule.<name>.update is checkout, the
> user is unlikely to be developing locally in the submodule, as
> subsequent updates would clobber their local commits. Having a
> detached HEAD is a helpful "don't develop here" reminder ;). If
> submodule.<name>.update is set, the user is likely to be developing
> locally, and will probably want a local branch already checked out to
> facilitate that.
>
> > > - module_clone "$sm_path" "$name" "$url" "$reference" "$depth" || exit
> > > + module_clone "$sm_path" "$name" "$url" "$reference" "$depth" "$config_branch" || exit
> >
> > In the simple case (update=checkout, no branch specified) with the
> > new checkout branch stuff in module_clone() this code here ends up
> > calling checkout twice. First for master and then here later with
> > the sha1. This feels a little bit double.
>
> There is no guarantee that the remote master and the exact sha1 point
> at the same commit. Ideally we'd just clone the exact sha1 in this
> case.
>
> > I would prefer if we skip the checkout in module_clone() if its not
> > necessary.
>
> When I tried to drop the '' case here:
>
> > > @@ -306,7 +307,15 @@ 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")
> > > + (
> > > + clear_local_git_env
> > > + cd "$sm_path" &&
> > > + GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
> > > + case "$branch" in
> > > + '') git checkout -f -q ;;
> > > + ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
> > > + esac
> > > + ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
> > > }
>
> I got test-suite errors that I didn't get to the bottom of. However…
>
> > How about we move the whole "what to checkout"-decision into one place
> > instead of having it in update() and moving it from add() into
> > module_clone() ?
>
> …this sounds like a good idea to me. However, it would be a more
> intrusive change, and there may be conflicts with Francesco's proposed
> attach/detach functionality. I'll wait until we have a clearer idea
> of where that is headed before I attempt a more complete
> consolidation.
I agree, that would be good.
> > > - update_module= ;;
> > > + if test -n "$config_branch"; then
> > > + update_module="!git reset --hard -q"
> >
> > If we get here the checkout has already been done. Shouldn't this
> > rather specify a noop. I.E. like
> >
> > update_module="!true"
>
> We are on a local branch at this point, but not neccessarily pointing
> at the gitlinked sha1. The reset here ensures that the new local
> branch does indeed point at the gitlinked sha1.
But isn't this a fresh clone? Why should the branch point at anything
else?
Cheers Heiko
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-05 20:33 ` Heiko Voigt
2014-01-05 21:46 ` Francesco Pretto
@ 2014-01-05 23:22 ` Francesco Pretto
2014-01-06 14:18 ` Heiko Voigt
1 sibling, 1 reply; 144+ messages in thread
From: Francesco Pretto @ 2014-01-05 23:22 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann
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.
Thank you,
Francesco
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-05 22:57 ` Heiko Voigt
@ 2014-01-05 23:39 ` W. Trevor King
2014-01-06 0:33 ` W. Trevor King
2014-01-06 15:47 ` Re: " Heiko Voigt
0 siblings, 2 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-05 23:39 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
[-- Attachment #1: Type: text/plain, Size: 4703 bytes --]
On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote:
> On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote:
> > If submodule.<name>.branch is set, it *always* creates a new local
> > branch of that name pointing to the exact sha1. If
> > submodule.<name>.branch is not set, we still create a
> > detached-HEAD checkout of the exact sha1.
>
> Thanks for this clarification. Since the usual usage with --remote
> is with a remote-tracking branch, I confused this here. I am not
> sure whether blindly creating a local branch from the recorded sha1
> is the right thing to do. In what situations would that be helpful?
In any situation where your going to develop the submodule locally,
you're going to want a branch to develop in. Starting local-submodule
developers off on a branch seems useful, even if we can only use
submodule.<name>.branch to guess at their preferred local branch name.
Sometimes (often?) the guess will be right. However, A detached HEAD
will never be right for local development, so being right sometimes is
still an improvement ;).
> At $dayjob we usually use feature branches for our work. So if
> someone wants to work in a submodule you simply create a branch at
> the current sha1 which you then send out for review.
I'm all for named feature branches for development, and in this case
submodule.<name>.branch is likely to be the wrong choice. However,
it's still safer to develop in that branch and then rename the branch
to match your feature than it would be to develop your fix with a
detached HEAD. If your developers have enough discipline to always
checkout their feature branch before starting development, my patch
won't affect them. However, I know a number of folks who go into
fight-or-flight mode when they have a detached HEAD :p.
> The reason why one would set a branch option here is to share the
> superproject branch with colleagues. He can make sure they can
> always fetch and checkout the submodule even though the branch there
> is still under cleanup and thus will be rebased often. The commit
> referenced by sha1 would not be available to a developer fetching
> after a rebase.
Yeah, floating gitlinks are something else. I'd be happy to have that
functionality (gitlinks pointing to references) should be built into
gitlinks themselves, not added as an additional layer in the submodule
script. This "gitlinked sha1 rebased out of existence" scenario is
the first I've heard where I think gitlinked references would be
useful.
> > Thinking through this more, perhaps the logic should be:
> >
> > * If submodule.<name>.update (defaulting to checkout) is checkout,
> > create a detached HEAD.
> > * Otherwise, create a new branch submodule.<name>.branch
> > (defaulting to master).
>
> Why not trigger the attached state with the submodule.<name>.branch
> configuration option? If there is a local branch available use that,
> if not the tracking branch (as it is currently). Then a developer
> can start working on the branch with:
>
> cd submodule; git checkout -t origin/<branchname>
>
> assuming that submodule update learns some more support for this.
Isn't that already what 'git update --remote <submodule>' already
does?
> > > > - update_module= ;;
> > > > + if test -n "$config_branch"; then
> > > > + update_module="!git reset --hard -q"
> > >
> > > If we get here the checkout has already been done. Shouldn't
> > > this rather specify a noop. I.E. like
> > >
> > > update_module="!true"
> >
> > We are on a local branch at this point, but not neccessarily
> > pointing at the gitlinked sha1. The reset here ensures that the
> > new local branch does indeed point at the gitlinked sha1.
>
> But isn't this a fresh clone? Why should the branch point at
> anything else?
We don't pass $sha1 to module_clone(). Before my patch, we don't even
pass $branch to module_clone(). That means that module_clone() will
only checkout the gitlinked sha1 when the upstream HEAD (or $branch
with my patch) happens to point to the gitlinked sha1. For example,
if Alice adds Charie's repo as a submodule (gitlinking his current
master d2dbd39), then Charlie pushes a new commit d0de817 to his
master, and then Bob clones Alice's superproject. Post-clone,
Charlie's submodule will have checked out Charlie's new d0de817, and
we need update's additional:
git reset --hard -q d2dbd39
to rewind to Alice's gitlinked sha1.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-05 23:39 ` W. Trevor King
@ 2014-01-06 0:33 ` W. Trevor King
2014-01-06 1:12 ` W. Trevor King
2014-01-06 15:47 ` Re: " Heiko Voigt
1 sibling, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-06 0:33 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]
On Sun, Jan 05, 2014 at 03:39:43PM -0800, W. Trevor King wrote:
> On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote:
> > The reason why one would set a branch option here is to share the
> > superproject branch with colleagues. He can make sure they can
> > always fetch and checkout the submodule even though the branch there
> > is still under cleanup and thus will be rebased often. The commit
> > referenced by sha1 would not be available to a developer fetching
> > after a rebase.
>
> Yeah, floating gitlinks are something else. I'd be happy to have
> that functionality (gitlinks pointing to references) be built into
> gitlinks themselves, not added as an additional layer in the
> submodule script. This "gitlinked sha1 rebased out of existence"
> scenario is the first I've heard where I think gitlinked references
> would be useful.
On the other hand, if the subproject has such a rebase, a superproject
dev can hop into an existing checkout, update around the rebase, add a
superproject commit with the fixed sha1, and push that for other
superproject devs. The only people who would need *automatic* rebase
recovery would be superproject devs update-cloning the subproject.
That's a small enough cross-section that I don't think it deserves the
ambiguity of gitlink-to-reference. In that case, all you really need
is a way to force a recovery gitlink (i.e. add a 'commit' object to
the tree by hand).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-06 0:33 ` W. Trevor King
@ 2014-01-06 1:12 ` W. Trevor King
2014-01-06 16:02 ` Heiko Voigt
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-06 1:12 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]
On Sun, Jan 05, 2014 at 04:33:14PM -0800, W. Trevor King wrote:
> The only people who would need *automatic* rebase recovery would be
> superproject devs update-cloning the subproject. That's a small
> enough cross-section that I don't think it deserves the ambiguity of
> gitlink-to-reference. In that case, all you really need is a way to
> force a recovery gitlink (i.e. add a 'commit' object to the tree by
> hand).
Actually, you recovering by hand is a lot easier. Setup a
rebased-away gitlink target:
mkdir subproject &&
(
cd subproject &&
git init
echo 'Subproject' > README &&
git add README &&
git commit -m 'Subproject v1' &&
echo 'Changes' >> README &&
git commit -am 'Subproject v2'
) &&
mkdir superproject &&
(
cd superproject &&
git init
git submodule add ../subproject &&
git commit -m 'Superproject v1'
) &&
(
cd subproject &&
git reset --hard HEAD^ &&
git reflog expire --expire=now --all &&
git gc --aggressive --prune=now
)
Then a recursive clone of the superproject dies:
$ git clone --recursive superproject super2
Cloning into 'super2'...
done.
Submodule 'subproject' (/tmp/x/subproject) registered for path 'subproject'
Cloning into 'subproject'...
done.
fatal: reference is not a tree: f589144d16282d1a80d17a9032c6f1d332e38dd0
Unable to checkout 'f589144d16282d1a80d17a9032c6f1d332e38dd0' in submodule path 'subproject'
But you still have the submodule checkout (up until the $sha1 setup):
$ cd super2
$ git diff
diff --git a/subproject b/subproject
index f589144..82d4553 160000
--- a/subproject
+++ b/subproject
@@ -1 +1 @@
-Subproject commit f589144d16282d1a80d17a9032c6f1d332e38dd0
+Subproject commit 82d4553fe437ae014f22bbc87a082c6d19e5d9f9-dirty
And you can automatically update to match the upstream remote:
$ git submodule update --remote --force
Submodule path 'subproject': checked out '82d4553fe437ae014f22bbc87a082c6d19e5d9f9'
$ git diff
diff --git a/subproject b/subproject
index f589144..82d4553 160000
--- a/subproject
+++ b/subproject
@@ -1 +1 @@
-Subproject commit f589144d16282d1a80d17a9032c6f1d332e38dd0
+Subproject commit 82d4553fe437ae014f22bbc87a082c6d19e5d9f9
When explicitly updating to the superproject or subproject's
(--remote) new tip is so easy, I don't see a need for floating the
gitlinks themselves.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-05 21:46 ` Francesco Pretto
@ 2014-01-06 14:06 ` Heiko Voigt
2014-01-06 17:47 ` Francesco Pretto
0 siblings, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-06 14:06 UTC (permalink / raw)
To: Francesco Pretto; +Cc: git, Jens Lehmann, Junio C Hamano, W. Trevor King
On Sun, Jan 05, 2014 at 10:46:11PM +0100, Francesco Pretto wrote:
> 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.
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.
> > - 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.
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.
> > - 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.
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?
> > - 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?
Cheers Heiko
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-05 23:22 ` Francesco Pretto
@ 2014-01-06 14:18 ` Heiko Voigt
2014-01-06 15:58 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-06 14:18 UTC (permalink / raw)
To: Francesco Pretto; +Cc: git, Jens Lehmann, W. Trevor King, Junio C Hamano
On Mon, Jan 06, 2014 at 12:22:23AM +0100, Francesco Pretto wrote:
> 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.
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.
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.
> > - 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.
Could you tell me a typical reason?
> 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.
Lets first discuss and figure out what is the real missing feature here
and what should be implemented before working further on the code.
Cheers Heiko
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-05 21:27 ` Francesco Pretto
2014-01-05 21:47 ` W. Trevor King
@ 2014-01-06 14:47 ` Heiko Voigt
2014-01-06 16:56 ` Junio C Hamano
1 sibling, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-06 14:47 UTC (permalink / raw)
To: Francesco Pretto; +Cc: W. Trevor King, Git, Junio C Hamano, Jens Lehmann
On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
> 2014/1/5 W. Trevor King <wking@tremily.us>:
> > On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote:
> >> Also it could break some users that rely on the current behavior.
> >
> > The current code always has a detached HEAD after an initial-clone
> > update, regardless of submodule.<name>.update, which doesn't match
> > those docs either.
>
> I perfectly agree with you that the documentation is a bit
> contradictory with regard to "update" command and detached HEAD.
> That's why it's so hard to add a feature and keep the same spirit of
> those that coded submodules at first. Also, I think that submodules
> didn't get much feedback with regards to these pitfalls because many
> people try to setup them, they see that "update" detaches the HEAD and
> they think "hmmm, maybe submodules are not what I was looking for".
I am not so sure about that. Why should detached HEAD make you think
like that? For us at $dayjob we have a pre-commit hook that denies you
to commit on a detached HEAD and asks you to create a branch first.
You then work on that branch and send it out for review. If the reviewer
is happy he merges it into a stable branch (master most times) of the
submodule. Only revisions that are on a stable branch in a submodule are
allowed to be linked in a superprojects branch that should be merged.
Before the submodule's branch gets merged we usually track the
development branches sha1 of the submodule in the superproject. For
cleanup in the submodule I currently use fixup! commits most times so
the referenced sha1 is not lost. In the very end when everyone is happy
with the submodule change I rebase, change the referenced sha1 in the
superproject and send the final branch out for review another time.
> > Adding a check to only checkout
> > submodule.<name>.branch if submodule.<name>.update was 'rebase',
> > 'merge', or 'none' would be easy, but I don't think that makes much
> > sense. I can't see any reason for folks who specify
> > submodule.<name>.branch to prefer a detached HEAD over a local branch
> > matching the remote branch's name.
>
> I think the reason is that it still matches the original use case of
> submodules devs:
> - the maintainer decides the specific commit developers should have;
Nope. We usually do not have a maintainer. We use a review based
workflow. Everyone is allowed to review. If you develop you need to send
you changes to a reviewer first who then merges when he is ok with it.
> - developers checkout that commit and don't pull (you can't do "git
> pull" in a detached HEAD);
Exactly. We consider pull evil ;-) Seriously: To update we only do fast
forward merges of local stable branches. Only reviewers or maintainers
are allowed to merge and push into stable branches. Direct commits to
stable branches are forbidden.
To review we have a shortcut to update the stable branch in git gui
for which the code can be found on my github[1].
> - they optionally get the upstream commit from the specified
> "submodule.<name>.branch" with "--remote". They are still in a
> detached HEAD and can't do "git pull".
Yes, why would you do a git pull in a submodule? Don't you want to do
something like
git checkout -t -b dev/my-topic origin/master
to start your development?
> 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.
Cheers Heiko
[1] https://github.com/hvoigt/git/commits/hv/gui-improvements
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-05 23:39 ` W. Trevor King
2014-01-06 0:33 ` W. Trevor King
@ 2014-01-06 15:47 ` Heiko Voigt
2014-01-06 17:22 ` W. Trevor King
1 sibling, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-06 15:47 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
On Sun, Jan 05, 2014 at 03:39:43PM -0800, W. Trevor King wrote:
> On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote:
> > On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote:
> > > If submodule.<name>.branch is set, it *always* creates a new local
> > > branch of that name pointing to the exact sha1. If
> > > submodule.<name>.branch is not set, we still create a
> > > detached-HEAD checkout of the exact sha1.
> >
> > Thanks for this clarification. Since the usual usage with --remote
> > is with a remote-tracking branch, I confused this here. I am not
> > sure whether blindly creating a local branch from the recorded sha1
> > is the right thing to do. In what situations would that be helpful?
>
> In any situation where your going to develop the submodule locally,
> you're going to want a branch to develop in. Starting local-submodule
> developers off on a branch seems useful, even if we can only use
> submodule.<name>.branch to guess at their preferred local branch name.
> Sometimes (often?) the guess will be right. However, A detached HEAD
> will never be right for local development, so being right sometimes is
> still an improvement ;).
Starting developers at a local submodule branch makes sense. But lets
think further. What happens after the initial update? Most times the
submodule will already be initialized and cloned. Then developers will
still get a detached HEAD even with your local branch feature.
If there are no changes on it should we advance the local branch
somehow on update? If it does not exist anymore should we recreate it?
> > At $dayjob we usually use feature branches for our work. So if
> > someone wants to work in a submodule you simply create a branch at
> > the current sha1 which you then send out for review.
>
> I'm all for named feature branches for development, and in this case
> submodule.<name>.branch is likely to be the wrong choice. However,
> it's still safer to develop in that branch and then rename the branch
> to match your feature than it would be to develop your fix with a
> detached HEAD. If your developers have enough discipline to always
> checkout their feature branch before starting development, my patch
> won't affect them. However, I know a number of folks who go into
> fight-or-flight mode when they have a detached HEAD :p.
I agree having an initial branch makes it less likely to loose committed
changes. Thats good. Also starting on some local branch name and then
renaming the branch sounds quite practical. Then we could recreate the
default local branch on update (like described above).
> > The reason why one would set a branch option here is to share the
> > superproject branch with colleagues. He can make sure they can
> > always fetch and checkout the submodule even though the branch there
> > is still under cleanup and thus will be rebased often. The commit
> > referenced by sha1 would not be available to a developer fetching
> > after a rebase.
>
> Yeah, floating gitlinks are something else. I'd be happy to have that
> functionality (gitlinks pointing to references) should be built into
> gitlinks themselves, not added as an additional layer in the submodule
> script. This "gitlinked sha1 rebased out of existence" scenario is
> the first I've heard where I think gitlinked references would be
> useful.
Yeah I have been thinking about this for quite a while now, but have not
yet found the time to really think it through and come up with a good
solution that does not put you in danger of unprecise revisions. The
only solution I can think of is a similar approach as
submodule.<name>.branch gives us now but possibly enabled by some
option (i.e.: submodule.<name>.remote = true).
This way you always get the current tip of development but still see the
differences (which you can choose to commit) in git status.
> > > Thinking through this more, perhaps the logic should be:
> > >
> > > * If submodule.<name>.update (defaulting to checkout) is checkout,
> > > create a detached HEAD.
> > > * Otherwise, create a new branch submodule.<name>.branch
> > > (defaulting to master).
> >
> > Why not trigger the attached state with the submodule.<name>.branch
> > configuration option? If there is a local branch available use that,
> > if not the tracking branch (as it is currently). Then a developer
> > can start working on the branch with:
> >
> > cd submodule; git checkout -t origin/<branchname>
> >
> > assuming that submodule update learns some more support for this.
>
> Isn't that already what 'git update --remote <submodule>' already
> does?
Does it? As far as I understood (not using the branch option yet) it
only does
git checkout origin/<branchname>
so there is no local branch created that tracks the remote branch (-t).
What I was thinking is that when submodule.<name>.branch is set a
git submodule update
will:
1. if no local branch with that name exists:
checkout the remote/<branch>
2. If a local branch with that name exists:
checkout the local branch and possibly advance it according to its
setting.
Thinking further: Maybe submodule.<name>.update = pull could denote that
a user wants to have a branch ready for work in a submodule. submodule
update will then
1. if no local branch with that name exists:
- automatically create the branch based on the referenced sha1
- set up that its tracking remote/<branch>
- issue a git pull in the submodule
2. if a local branch with that name exists:
- issue a git pull in the submodule
The superproject will still show if there are any changes in the
submodule (i.e. the sha1 does not match anymore). Even though the user
can disable it with submodule.<name>.ignore=all I would advise against
it.
> > > > > - update_module= ;;
> > > > > + if test -n "$config_branch"; then
> > > > > + update_module="!git reset --hard -q"
> > > >
> > > > If we get here the checkout has already been done. Shouldn't
> > > > this rather specify a noop. I.E. like
> > > >
> > > > update_module="!true"
> > >
> > > We are on a local branch at this point, but not neccessarily
> > > pointing at the gitlinked sha1. The reset here ensures that the
> > > new local branch does indeed point at the gitlinked sha1.
> >
> > But isn't this a fresh clone? Why should the branch point at
> > anything else?
>
> We don't pass $sha1 to module_clone(). Before my patch, we don't even
> pass $branch to module_clone(). That means that module_clone() will
> only checkout the gitlinked sha1 when the upstream HEAD (or $branch
> with my patch) happens to point to the gitlinked sha1. For example,
> if Alice adds Charie's repo as a submodule (gitlinking his current
> master d2dbd39), then Charlie pushes a new commit d0de817 to his
> master, and then Bob clones Alice's superproject. Post-clone,
> Charlie's submodule will have checked out Charlie's new d0de817, and
> we need update's additional:
>
> git reset --hard -q d2dbd39
>
> to rewind to Alice's gitlinked sha1.
Ah yeah, sorry I was confusing this with the checkout of remote/<branch>
here again. Since I have done that twice already maybe we should be
careful about not confusing users with this as well...
After wrapping my head around the fact that you want to simply create a
local branch on the referenced sha1 (and hopefully remembering it) I
still would like to think a little more about it and let it settle a
bit.
Cheers Heiko
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-06 14:18 ` Heiko Voigt
@ 2014-01-06 15:58 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-06 15:58 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Francesco Pretto, git, Jens Lehmann, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
On Mon, Jan 06, 2014 at 03:18:05PM +0100, Heiko Voigt wrote:
> 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'
Or (respecting submodule.<name>.branch):
$ git submodule update --remote
You can even:
$ git submodule update --remote --recursive
whenever you get an itch to upgrade everything everything in one
sweeping, hard-to-debug move ;).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-06 1:12 ` W. Trevor King
@ 2014-01-06 16:02 ` Heiko Voigt
2014-01-06 23:10 ` Francesco Pretto
0 siblings, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-06 16:02 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
On Sun, Jan 05, 2014 at 05:12:56PM -0800, W. Trevor King wrote:
> On Sun, Jan 05, 2014 at 04:33:14PM -0800, W. Trevor King wrote:
> > The only people who would need *automatic* rebase recovery would be
> > superproject devs update-cloning the subproject. That's a small
> > enough cross-section that I don't think it deserves the ambiguity of
> > gitlink-to-reference. In that case, all you really need is a way to
> > force a recovery gitlink (i.e. add a 'commit' object to the tree by
> > hand).
>
> Actually, you recovering by hand is a lot easier. Setup a
> rebased-away gitlink target:
>
> mkdir subproject &&
> (
> cd subproject &&
> git init
> echo 'Subproject' > README &&
> git add README &&
> git commit -m 'Subproject v1' &&
> echo 'Changes' >> README &&
> git commit -am 'Subproject v2'
> ) &&
> mkdir superproject &&
> (
> cd superproject &&
> git init
> git submodule add ../subproject &&
> git commit -m 'Superproject v1'
> ) &&
> (
> cd subproject &&
> git reset --hard HEAD^ &&
> git reflog expire --expire=now --all &&
> git gc --aggressive --prune=now
> )
>
> Then a recursive clone of the superproject dies:
>
> $ git clone --recursive superproject super2
> Cloning into 'super2'...
> done.
> Submodule 'subproject' (/tmp/x/subproject) registered for path 'subproject'
> Cloning into 'subproject'...
> done.
> fatal: reference is not a tree: f589144d16282d1a80d17a9032c6f1d332e38dd0
> Unable to checkout 'f589144d16282d1a80d17a9032c6f1d332e38dd0' in submodule path 'subproject'
>
> But you still have the submodule checkout (up until the $sha1 setup):
>
> $ cd super2
> $ git diff
> diff --git a/subproject b/subproject
> index f589144..82d4553 160000
> --- a/subproject
> +++ b/subproject
> @@ -1 +1 @@
> -Subproject commit f589144d16282d1a80d17a9032c6f1d332e38dd0
> +Subproject commit 82d4553fe437ae014f22bbc87a082c6d19e5d9f9-dirty
>
> And you can automatically update to match the upstream remote:
>
> $ git submodule update --remote --force
> Submodule path 'subproject': checked out '82d4553fe437ae014f22bbc87a082c6d19e5d9f9'
> $ git diff
> diff --git a/subproject b/subproject
> index f589144..82d4553 160000
> --- a/subproject
> +++ b/subproject
> @@ -1 +1 @@
> -Subproject commit f589144d16282d1a80d17a9032c6f1d332e38dd0
> +Subproject commit 82d4553fe437ae014f22bbc87a082c6d19e5d9f9
>
> When explicitly updating to the superproject or subproject's
> (--remote) new tip is so easy, I don't see a need for floating the
> gitlinks themselves.
I agree. If we were to support this more easily we could add a
configuration option so you can omit the --remote (i.e.:
submodule.<name>.remote=true, as I also suggested in the other email).
That way the developer checking out a branch in flight does not even
need to know whether (and which) submodules sha1s are still in flight
and temporarily set this configuration in the branches .gitmodules file.
Maybe that could actually be the attach operation Francesco is
suggesting:
git submodule attach [--pull] <submodule path> <branchname>
will attach the specified submodule to a branch. That means it changes
the .gitmodule file accordingly and stages it. With the --pull switch
one can specify whether a local branch tracking the remote branch should
be automatically created. Names and the command format are just a
suggestion here.
That way we can support the
fork superproject needing submodule changes and send submodule
changes upstream first.
workflow. What do you think?
Cheers Heiko
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command
2014-01-05 20:44 ` W. Trevor King
@ 2014-01-06 16:20 ` Junio C Hamano
2014-01-06 17:42 ` Junio C Hamano
0 siblings, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-06 16:20 UTC (permalink / raw)
To: W. Trevor King; +Cc: Francesco Pretto, git, Heiko Voigt
"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.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-06 14:47 ` Heiko Voigt
@ 2014-01-06 16:56 ` Junio C Hamano
2014-01-06 17:37 ` W. Trevor King
2014-01-07 0:55 ` Francesco Pretto
0 siblings, 2 replies; 144+ messages in thread
From: Junio C Hamano @ 2014-01-06 16:56 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Francesco Pretto, W. Trevor King, Git, Jens Lehmann
Heiko Voigt <hvoigt@hvoigt.net> writes:
> On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
>> 2014/1/5 W. Trevor King <wking@tremily.us>:
>> > On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote:
>> >> Also it could break some users that rely on the current behavior.
>> >
>> > The current code always has a detached HEAD after an initial-clone
>> > update, regardless of submodule.<name>.update, which doesn't match
>> > those docs either.
>>
>> I perfectly agree with you that the documentation is a bit
>> contradictory with regard to "update" command and detached HEAD.
>> That's why it's so hard to add a feature and keep the same spirit of
>> those that coded submodules at first. Also, I think that submodules
>> didn't get much feedback with regards to these pitfalls because many
>> people try to setup them, they see that "update" detaches the HEAD and
>> they think "hmmm, maybe submodules are not what I was looking for".
>
> I am not so sure about that. Why should detached HEAD make you think
> like that? For us at $dayjob we have a pre-commit hook that denies you
> to commit on a detached HEAD and asks you to create a branch first.
Perception is irrational ;-)
We long-timers think detached is a perfect starting point for both
users of submodule who merely want to use the specified commit and
developers who want to work on the submodule to match the need of
the superproject. The former do not have to do anything, and the
latter will have to chdir to the submodule working tree and create a
branch (or update the branch with rebase or pull on top of the
specified commit) as the first thing before doing anything.
Not everybody is a long-timer, but the saving grace is that nobody
stays a newcomer.
BUT.
>> - developers checkout that commit and don't pull (you can't do "git
>> pull" in a detached HEAD);
>
> Exactly. We consider pull evil ;-) Seriously: To update we only do fast
> forward merges of local stable branches.
> ...
> Yes, why would you do a git pull in a submodule? Don't you want to do
> something like
>
> git checkout -t -b dev/my-topic origin/master
>
> to start your development?
As long as origin/master contains the commit specified by the
superproject, that would work, but it may be a good thing to use a
mode of submodule.*.update that does not have to drop the user into
a detached state in the first place. I somehow thought that was
what rebase (or merge) was about, that is, starting from the state
where a branch is checked out in the submodule working tree, an
update in the superproject would cause that branch checked out in
the submodule brought up to date with respect to the commit
specified in the superproject tree. If that is not how it is
supposed to work, please correct me---and we may have to add another
mode that does so (or even make rebase/merge do so as a bugfix).
And wouldn't it make it unnecessary to have a new "re-attach" option
if such a mode that never have to detach is used?
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-06 15:47 ` Re: " Heiko Voigt
@ 2014-01-06 17:22 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-06 17:22 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Git, Francesco Pretto, Junio C Hamano, Jens Lehmann
[-- Attachment #1: Type: text/plain, Size: 7372 bytes --]
On Mon, Jan 06, 2014 at 04:47:39PM +0100, Heiko Voigt wrote:
> On Sun, Jan 05, 2014 at 03:39:43PM -0800, W. Trevor King wrote:
> > On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote:
> > > On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote:
> > > > Thinking through this more, perhaps the logic should be:
> > > >
> > > > * If submodule.<name>.update (defaulting to checkout) is checkout,
> > > > create a detached HEAD.
> > > > * Otherwise, create a new branch submodule.<name>.branch
> > > > (defaulting to master).
> > >
> > > Why not trigger the attached state with the
> > > submodule.<name>.branch configuration option? If there is a
> > > local branch available use that, if not the tracking branch (as
> > > it is currently). Then a developer can start working on the
> > > branch with:
> > >
> > > cd submodule; git checkout -t origin/<branchname>
> > >
> > > assuming that submodule update learns some more support for this.
> >
> > Isn't that already what 'git update --remote <submodule>' already
> > does?
>
> Does it? As far as I understood (not using the branch option yet) it
> only does
>
> git checkout origin/<branchname>
>
> so there is no local branch created that tracks the remote branch (-t).
That's right. Anyone who wants to do local development in a submodule
should probably not be using checkout updates, hence my proposal above
to base local-branch creation on submodule.<name>.update.
> What I was thinking is that when submodule.<name>.branch is set a
>
> git submodule update
>
> will:
>
> 1. if no local branch with that name exists:
>
> checkout the remote/<branch>
>
> 2. If a local branch with that name exists:
>
> checkout the local branch and possibly advance it according to
> its setting.
This sounds too complicated to me ;).
> Thinking further: Maybe submodule.<name>.update = pull could denote
> that a user wants to have a branch ready for work in a submodule.
This sounds like my quoted realization above. We both even preface
the idea with "thinking" ;). However, I think merge, rebase,
!command, and all other non-checkout update schemes are already
signals that the developer is interested in local developent (and
therefore wants a branch), without the need to add an aditional 'pull'
(and then how to distinguish between rebase/merge?).
> submodule update will then
>
> 1. if no local branch with that name exists:
>
> - automatically create the branch based on the referenced sha1
> - set up that its tracking remote/<branch>
With my patch this happens with the initial clone-update (as of v2,
only when submodule.<name>.branch is set. In a hypothetical v3, only
when submodule.<name>.update is not checkout). I'm not sure we want
to do this if the user switches to non-checkout updates after the
initial cloning update though. They may actually have work in that
detached HEAD that we'd be clobbering.
> - issue a git pull in the submodule
I think that updating using the gitlinked sha1 (a local update) and
updating using the upstream origin/$branch (a --remote update) should
always be two distinct events. Combining them in a single operation
just complicates the situation.
> 2. if a local branch with that name exists:
>
> - issue a git pull in the submodule
That's what we already have with submodule.<name>.update as 'merge'.
The merged object is either the gitlinked sha1 (a local update) or a
re-fetched upstream branch tip (a --remote update).
> > > > We are on a local branch at this point, but not neccessarily
> > > > pointing at the gitlinked sha1. The reset here ensures that
> > > > the new local branch does indeed point at the gitlinked sha1.
> > >
> > > But isn't this a fresh clone? Why should the branch point at
> > > anything else?
> >
> > We don't pass $sha1 to module_clone(). Before my patch, we don't
> > even pass $branch to module_clone(). That means that
> > module_clone() will only checkout the gitlinked sha1 when the
> > upstream HEAD (or $branch with my patch) happens to point to the
> > gitlinked sha1. For example, if Alice adds Charie's repo as a
> > submodule (gitlinking his current master d2dbd39), then Charlie
> > pushes a new commit d0de817 to his master, and then Bob clones
> > Alice's superproject. Post-clone, Charlie's submodule will have
> > checked out Charlie's new d0de817, and we need update's
> > additional:
> >
> > git reset --hard -q d2dbd39
> >
> > to rewind to Alice's gitlinked sha1.
>
> Ah yeah, sorry I was confusing this with the checkout of
> remote/<branch> here again. Since I have done that twice already
> maybe we should be careful about not confusing users with this as
> well...
>
> After wrapping my head around the fact that you want to simply create a
> local branch on the referenced sha1 (and hopefully remembering it) I
> still would like to think a little more about it and let it settle a
> bit.
The way I keep this straight is:
1. Submodules are links to Git commits (that's how they're stored in
the index).
2. There are two places to look if you want to update the linked
commit:
a. The superproject's tree (a local updates).
b. The remote subproject's current submodule.<name>.branch tip (a
--remote update).
3. There are a number of ways to integrate external updates with your
local submodule development.
a. checkout: blow away local development
b. merge: merge the update into the local branch
c. rebase: rebase the local branch onto the update
d. !command: do something fancier
We currently have easy config and command-line switches to select
between 2.a and 2.b, which for me makes extending 1 to support
floating branches unnecessary. Note that we're always updating to a
referenced sha1, and there are only two places we can look to find
that sha1.
We also have easy config and command-line switches to select between
3.a, 3.b, 3.c, and 3.d.
One thing that's a bit fuzzy is the definition of "local development".
We're currently treating it as "any commits leading up to HEAD that
are not in the update source", which works well until upstream starts
rebasing (or rolling back to an earlier release, etc.). It's hard for
Git to handle that sort of thing automatically, for all the usual
"recovering from upstream rebase" reasons [1]. I'm fine if we leave
it up to users to resolve this sort of situation by hand. Folks with
local work should know what was local, and folks without local work
can use a checkout update.
We're also not doing a great job of setting people up for local
development, but that's tricky if they may already have local work.
My "start them on a branch" patch is not saving anyone a lot of work,
but it's a step in that direction. Doing anything after the initial
cloning update is going to be much harder, because there's not much
that would be unabmiguously helpful. After all, the current submodule
implementation supports my workflows pretty well.
Cheers,
Trevor
[1]: See "RECOVERING FROM UPSTREAM REBASE" in git-rebase(1).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-06 16:56 ` Junio C Hamano
@ 2014-01-06 17:37 ` W. Trevor King
2014-01-06 21:32 ` Junio C Hamano
2014-01-07 0:55 ` Francesco Pretto
1 sibling, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-06 17:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Heiko Voigt, Francesco Pretto, Git, Jens Lehmann
[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]
On Mon, Jan 06, 2014 at 08:56:22AM -0800, Junio C Hamano wrote:
> Heiko Voigt <hvoigt@hvoigt.net> writes:
> > Yes, why would you do a git pull in a submodule? Don't you want to do
> > something like
> >
> > git checkout -t -b dev/my-topic origin/master
> >
> > to start your development?
>
> As long as origin/master contains the commit specified by the
> superproject, that would work, but it may be a good thing to use a
> mode of submodule.*.update that does not have to drop the user into
> a detached state in the first place. I somehow thought that was
> what rebase (or merge) was about, that is, starting from the state
> where a branch is checked out in the submodule working tree, an
> update in the superproject would cause that branch checked out in
> the submodule brought up to date with respect to the commit
> specified in the superproject tree.
That is my understanding as well. In fact, I don't think the
detached-HEAD-vs-branch distinction is important here, you can still
rebase your detached HEAD onto the superproject's referenced commit
(or origin/$branch with --remote). This will also work for merge, and
should work for well-crafted !commands.
> And wouldn't it make it unnecessary to have a new "re-attach" option
> if such a mode that never have to detach is used?
I think so, but we currently don't have a "never detached" route for
folks that are cloning submodules via update (instead of via
'submodule add'). Currently, new clone-updates will always leave you
with a detached HEAD (unless you have branch-creation in your update
!command). My patch aims to close this detached-HEAD gap, for folks
we expect will be doing local development, by creating an initial
branch at clone-update time.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command
2014-01-06 16:20 ` Junio C Hamano
@ 2014-01-06 17:42 ` Junio C Hamano
2014-01-06 17:52 ` Francesco Pretto
0 siblings, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-06 17:42 UTC (permalink / raw)
To: W. Trevor King; +Cc: Francesco Pretto, git, Heiko Voigt
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.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-06 14:06 ` Heiko Voigt
@ 2014-01-06 17:47 ` Francesco Pretto
2014-01-06 19:21 ` David Engster
` (3 more replies)
0 siblings, 4 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-06 17:47 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann, Junio C Hamano, W. Trevor King
Dear Heiko, my replies below. I also take a couple excerpts from other
emails, as I prefer to not flame on different threads :) .
2014/1/6 Heiko Voigt <hvoigt@hvoigt.net>:
> 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.
>
Correct, but this works also if the branch of the superproject is a
different branch than "master". I think you are right in a point, see
the next reply.
> 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.
>
Ok, you are right: setting "submodule.<name>.ignore" to "all" by
default with a switch "--attached" in "git submodule add" is too much.
My point is just make sure users will checkout an attached HEAD.
>> "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?
>
"submodule.<name>.attacched" set to true implies "--remote". sha1 of
the latest commit is taken from "origin/$branch". In this way you get
the latest commit of that branch, and you do a 'merge', 'rebase',
'checkout' or '!command' according to the configured ''. This
mechanism is already in the patch at the current state.
>> > - 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". This ability is of
course already possible reattaching the HEAD manually but you loose
the convenient ability to use "git submodule update".
>> 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?
>
I'm really sorry, I thought this was already clear from the first
patch iteration. I will go more in depth:
Say we have our actual projects "project1" and "project2". Say we have
a project "common". This "common" project is *not* independent: it
exists only to serve "project1" and "project2" and it's tested only in
the scope of "project1" and "project2". Also "common" is very actively
developed and follows the same lifecyle of "project1" and "project2"
on separate branches. I think that it's important that you get this
point: developers of "common" don't clone it separately, as it would
be impossible to test it, they clone "project1" and "project2" and
expect to find it inside one of these.
Let say now how "common" can be shared between "project1" and
"project2" so developers of "project1" don't break "project2" working
on "common" and the other way around. "common" has the following
stable branches:
- master;
- master-project1;
- master-project2;
The maintainer of "project1" at master branch sets "common" as
submodule at branch "master-project1". The maintainer of "project2" at
master branch sets "common" as submodule at branch "master-project2".
Periodically a maintainer of "common" will pull both master-project1
and master-project1 on a branch "next". Maintainers of both "project1"
and "project1", in coordination, are responsible to make next to be
merged in master, so they can both sync their master-project1 and
master-project2 in the "common" submodule.
Let say now how for example {"project1" and "common"} can evolve. As
told, these can't really evolve separately. Maintainer of "project1"
prepares a branch called "staging-featureA". "featureA" is big and
will require more people to work on the same feature for days/weeks.
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. Of course if "common" of
the developer is in a branch different that 'submodule.<name>.branch'
"git submodule update" has not to switch the branch.
>> 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.
>> > - 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?
>
No, I'm talking about "git submoudule update" with "--merge" or
"--rebase switches or "submodule.name.update" configured.
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
Of course the developer after they may want to move to a local branch
(or may not: please don't forget shared repositories), but the above
command may difficult to be taught. Also with the comit[1] that blocks
copying of !command to ".git/config" and sets default "none", you made
it harder to offer a mantainer decided default update behavior like
the one I described.
> 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.
>
Putting your reasoning to the extreme consequences: why does not "git
clone" clone a dettached HEAD? In your workflow I should probably
never start coding from "master", but people frequently do instead.
Also, as you observed, it's possible to track submodule revision sha1
also on an attached HEAD. If I don't want anyone to track the revision
I can already set 'ignore' property.
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.
Thank you for reading and sorry for the long email :)
Greetings,
Francesco
[1] http://marc.info/?l=git&m=138610752125816&w=2
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command
2014-01-06 17:42 ` Junio C Hamano
@ 2014-01-06 17:52 ` Francesco Pretto
0 siblings, 0 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-06 17:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: W. Trevor King, git, Heiko Voigt
Ok, applying the suggested modifications and resending shortly.
Thank you,
Francesco
2014/1/6 Junio C Hamano <gitster@pobox.com>:
> 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.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-06 17:47 ` Francesco Pretto
@ 2014-01-06 19:21 ` David Engster
2014-01-07 19:27 ` W. Trevor King
2014-01-07 4:10 ` W. Trevor King
` (2 subsequent siblings)
3 siblings, 1 reply; 144+ messages in thread
From: David Engster @ 2014-01-06 19:21 UTC (permalink / raw)
To: Francesco Pretto
Cc: Heiko Voigt, git, Jens Lehmann, Junio C Hamano, W. Trevor King
Francesco Pretto writes:
> 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:
While I have some trouble understanding all the details of Francesco's
description, I find the idea of "attaching submodules to branches" very
useful. I think I could well use that to simplify my merging grunt work
for GNU Emacs (which, in case you're wondering, is probably switching to
git as its VCS). I don't mean to hijack this thread, and I guess my use
case is a bit different than what Francesco has in mind; still, I think
it is similar enough that my use case could help in talking about the
details of his patch; if not, please feel free to ignore it.
GNU Emacs ships with some pretty large packages, namely Gnus, Org and
CEDET, which are also available as "stand-alone" versions for manual
installation, and their development happens in separate upstream
repositories. Since I'm a CEDET developer, I'll use it as an example in
the following.
First off, it is important to note that merges are always
bi-directional: not only is new CEDET code pulled into Emacs, but Emacs
developers also change things which have to be merged back upstream. So
far, merging between the two repositories was done manually by me, which
is error-prone (and boring). I think that by pulling in CEDET directly
as a submodule, this merging could be made easier. Most importantly, my
hope is that more people than me could do it. :-)
Here's how I would like this to work; first the CEDET -> Emacs part,
which is rather straight-forward:
- The CEDET repository has two branches: 'master' and 'stable'.
- The Emacs repository imports CEDET's 'stable' branch as a submodule.
- CEDET's main development happens in 'master', and the CEDET developers
are responsible for merging stable code to 'stable'. They will then
make a new commit for the submodule in Emacs accordingly.
The Emacs -> CEDET part is more hairy. Most of the time, the fixes
happening in the Emacs repository for CEDET are very small and/or
trivial and can usually be considered "always stable": fixes for
spelling, compiler warnings, or small refactorings like renames,
etc. This kind of "merging back to CEDET upstream" should hence be as
easy as possible for Emacs developers:
- When an Emacs developer changes something in the CEDET submodule, the
changes they commit should by default automatically land in CEDET's
'stable' branch. That means that when they enter the submodule, they
should be in the branch 'stable' instead of being detached, and a push
should update the 'stable' branch in CEDET accordingly. The submodule
must then be committed as well.
- It is then up to the CEDET developers to merge these changes into the
'master' branch of the CEDET repo.
I know that the "correct" workflow would be to always use feature
branches, but it'd be nice if that could be avoided if one so chooses.
A little picture in the hope that it makes things clearer:
+-----------+
| 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. If I understand
Francesco correctly, he wants to eliminate the need for that by simply
always taking the head of the attached branch. I also think that would
be a nice feature, since in the above drawing, the lisp/cedet submodule
should always follow the 'stable' branch in CEDET upstream. 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?
-David
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-06 17:37 ` W. Trevor King
@ 2014-01-06 21:32 ` Junio C Hamano
0 siblings, 0 replies; 144+ messages in thread
From: Junio C Hamano @ 2014-01-06 21:32 UTC (permalink / raw)
To: W. Trevor King; +Cc: Heiko Voigt, Francesco Pretto, Git, Jens Lehmann
"W. Trevor King" <wking@tremily.us> writes:
>> And wouldn't it make it unnecessary to have a new "re-attach" option
>> if such a mode that never have to detach is used?
>
> I think so, but we currently don't have a "never detached" route for
> folks that are cloning submodules via update (instead of via
> 'submodule add'). Currently, new clone-updates will always leave you
> with a detached HEAD (unless you have branch-creation in your update
> !command). My patch aims to close this detached-HEAD gap, for folks
> we expect will be doing local development, by creating an initial
> branch at clone-update time.
I am not a submodule expert so I may be missing some other gaps, but
what your change does sounds sensible to me.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-06 16:02 ` Heiko Voigt
@ 2014-01-06 23:10 ` Francesco Pretto
2014-01-06 23:32 ` Francesco Pretto
0 siblings, 1 reply; 144+ messages in thread
From: Francesco Pretto @ 2014-01-06 23:10 UTC (permalink / raw)
To: Heiko Voigt; +Cc: W. Trevor King, Git, Junio C Hamano, Jens Lehmann
2014/1/6 Heiko Voigt <hvoigt@hvoigt.net>:
>
> I agree. If we were to support this more easily we could add a
> configuration option so you can omit the --remote (i.e.:
> submodule.<name>.remote=true, as I also suggested in the other email).
>
> That way the developer checking out a branch in flight does not even
> need to know whether (and which) submodules sha1s are still in flight
> and temporarily set this configuration in the branches .gitmodules file.
>
"submodule.<name>.remote" can be useful but can be added later to aid
the current use case.
To not break the existing behavior what it's really needed here, IMO,
is a "submodule.<name>.attached" property that says two things:
- at the first clone on "git submodule update" stay attached to
"submodule.<name>.branch";
- implies "--remote", as it's the only thing that makes sense when the
submodules are attached.
My patch at the current unreleased state does exactly this.
> Maybe that could actually be the attach operation Francesco is
> suggesting:
>
> git submodule attach [--pull] <submodule path> <branchname>
>
> will attach the specified submodule to a branch. That means it changes
> the .gitmodule file accordingly and stages it. With the --pull switch
> one can specify whether a local branch tracking the remote branch should
> be automatically created. Names and the command format are just a
> suggestion here.
>
> That way we can support the
>
> fork superproject needing submodule changes and send submodule
> changes upstream first.
>
My patch didn't do this, as the maintainer can do these things quite
easily[1] (maintainer is "cooler" with respect to other devs :) ), but
I think it could be good to also have this feature.
The feature I think that are still needed and you don't mention are:
- an "--attached" switch for the "add" command when the maintainer
create the submodule the first time (DONE in patch);
- a easy way to attach|detach the submodule locally by developer. This should:
* fix the head state (DONE in patch);
* fix the local .git/config "submodule.<name>.attached" property
accordingly (DONE in patch, unreleased).
I do the latest in the "update" command but it seems bad to touch
.git/config in the "update" command...
Maybe we should have a "git submodule head" command that does all
these things: --attach (for the maintainer), --attach|--detach (for
the developer).
[1]
$ ( cd submodule && git branch newbranch && git push -u origin HEAD)
$ git config -f .gitmodules submodule.newbranch.branch newbranch
$ git config -f .gitmodules submodule.newbranch.attached true
$ git add . && git commit -m "Forked superproject" && git push
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-06 23:10 ` Francesco Pretto
@ 2014-01-06 23:32 ` Francesco Pretto
2014-01-07 18:27 ` Junio C Hamano
0 siblings, 1 reply; 144+ messages in thread
From: Francesco Pretto @ 2014-01-06 23:32 UTC (permalink / raw)
To: Heiko Voigt; +Cc: W. Trevor King, Git, Junio C Hamano, Jens Lehmann
2014/1/7 Francesco Pretto <ceztko@gmail.com>:
> To not break the existing behavior what it's really needed here, IMO,
> is a "submodule.<name>.attached" property that says two things:
> - at the first clone on "git submodule update" stay attached to
> "submodule.<name>.branch";
> - implies "--remote", as it's the only thing that makes sense when the
> submodules are attached.
>
Unless you decide to go with the proposed approach of Trevor, where
"submodule.<name>.branch" set means attached (if it's not changed:
this thread is quite hard to follow...). To this end, Junio could sync
with more "long-timers" (Heiko?) submodule users/devs to understand if
this breaks too much or not.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-06 16:56 ` Junio C Hamano
2014-01-06 17:37 ` W. Trevor King
@ 2014-01-07 0:55 ` Francesco Pretto
1 sibling, 0 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-07 0:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Heiko Voigt, W. Trevor King, Git, Jens Lehmann
2014/1/6 Junio C Hamano <gitster@pobox.com>:
>
> As long as origin/master contains the commit specified by the
> superproject, that would work, but it may be a good thing to use a
> mode of submodule.*.update that does not have to drop the user into
> a detached state in the first place. I somehow thought that was
> what rebase (or merge) was about, that is, starting from the state
> where a branch is checked out in the submodule working tree, an
> update in the superproject would cause that branch checked out in
> the submodule brought up to date with respect to the commit
> specified in the superproject tree. If that is not how it is
> supposed to work, please correct me---and we may have to add another
> mode that does so (or even make rebase/merge do so as a bugfix).
>
I think the mode you are referring to is actually my
"submodule.<name>.attached" property. As I said to Heiko, the
"submodule.<name>.attached" property says two things:
- at the first clone on "git submodule update" stay attached to
"submodule.<name>.branch";
- implies "--remote", as it's the only thing that makes sense when the
submodules are attached.
> And wouldn't it make it unnecessary to have a new "re-attach" option
> if such a mode that never have to detach is used?
I think the reattach|detach option are still needed (it is debatable
if we should have something like "git submodule head" command or we
can keep them in "git submodule update") because the user may want to
do so and doing it requires things should be really atomic:
* fix the head state;
* set the local .git/config "submodule.<name>.attached" property.
The "--attach" switch also can add a great bonus: it can reintegrate
orphaned commits when reattaching and having a "update" mode with
"merge" or "rebase". This is already in my patch.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-06 17:47 ` Francesco Pretto
2014-01-06 19:21 ` David Engster
@ 2014-01-07 4:10 ` W. Trevor King
2014-01-07 22:36 ` Preferred local submodule branches (was: Introduce git submodule attached update) W. Trevor King
2014-01-07 22:51 ` Re: [PATCH 2/2] Introduce git submodule attached update Heiko Voigt
2014-01-07 18:56 ` Junio C Hamano
2014-01-07 19:07 ` Junio C Hamano
3 siblings, 2 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-07 4:10 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Heiko Voigt, git, Jens Lehmann, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 6106 bytes --]
On Mon, Jan 06, 2014 at 06:47:58PM +0100, Francesco Pretto wrote:
> I'm really sorry, I thought this was already clear from the first
> patch iteration. I will go more in depth:
For me anyway, this extra detail is very helpful. Thanks :).
> 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 ....
So the checked-out branch switches depending on the local superproject
branch. That sounds nice, but I'm not sure where the
superproject-branch-to-local-submodule-branch mapping would be stored.
We currently do this for remote-tracking submodule branches with an
in-tree .gitmodules (which can differ between submodule branches) with
local overides in a single out-of-tree .git/config (which is
independent of the checked out branch). Ideally we'd have a way to
add local overrides on a per-superproject-branch basis, but I don't
know what that would look like.
> 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.
Rebasing the superproject and then updating the submodules (to the
superproject's gitlinked commits) is not the same as a --remote update
(to the subproject's upstream branch tip).
> Of course if "common" of the developer is in a branch different that
> 'submodule.<name>.branch' "git submodule update" has not to switch
> the branch.
I don't understand what you're saying here.
> >> 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.
You can cd into the submodule, and develop it as an independent
repository. When you want to test your changes, just cd back into the
superproject and run your test suite.
> 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
Which is equivalent to:
$ git submodule update --remote --checkout
except for branch-vs-detached-HEAD. If you are doing local
development, I'd recommend setting up submodule.<name>.update to a
non-checkout strategy and using:
$ git submodule update --remote
which will integrate the upstream changes with any local changes
(updating whichever local submodule branch you had checked out).
> Also with the comit[1] that blocks copying of !command to
> ".git/config" and sets default "none", you made it harder to offer a
> mantainer decided default update behavior like the one I described.
The maintainer can still suggest checkout/pull/rebase, and the
developer can still clear remove the none from .git/config after
initializing the submodule. You only need to do this once per
submodule.
> 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;
I agree, and want to use a non-checkout submodule.<name>.update mode
to identify developers who would want this. My v2 patch switches on
submodule.<name>.branch, but I'll update it in v3 to switch on
submodule.<name>.update. There's no need to confuse this with
additional attach/detach functionality.
> - "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.
You can already add aliases, but a remote/local-gitlink config
variable would be nice too.
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.
* Configurable (remote or local) default update source (so folks who
primarily update --remote don't have to have long command lines).
* New submodule.<name>.source = {remote|local} config
* New 'update [--source={local|remote}]' option
* Deprecate 'update --remote' with a long phase out.
However:
* Maybe they should just setup an alias instead?
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-05 16:17 ` [RFC v2] submodule: Respect requested " W. Trevor King
2014-01-05 19:48 ` Heiko Voigt
2014-01-05 21:27 ` Francesco Pretto
@ 2014-01-07 18:15 ` Junio C Hamano
2014-01-07 18:47 ` W. Trevor King
2 siblings, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-07 18:15 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Francesco Pretto, Jens Lehmann, Heiko Voigt
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> The previous code only checked out the requested branch in cmd_add.
> This commit moves the branch-checkout logic into module_clone, where
> it can be shared by cmd_add and cmd_update. I also update the initial
> checkout command to use 'rebase' to preserve branches setup during
> module_clone.
I want to see the log message explain the motivation behind it
(i.e. instead of stopping after saying "We used to do X, now we do
Y", but also explain why we consider that Y is better than X). Here
is my attempt.
submodule: respect requested branch on all clones
The previous code only checked out the requested branch in cmd_add
but not in cmd_update; this left the user on a detached HEAD after
an update initially cloned, and subsequent updates using rebase or
merge mode will kept the HEAD detached, unless the user moved to the
desired branch himself.
Move the branch-checkout logic into module_clone, where it can be
shared by cmd_add and cmd_update. Also update the initial checkout
command to use 'rebase' to preserve branches setup during
module_clone. This way, unless the user explicitly asks to work on
a detached HEAD, subsequent updates all happen on the specified
branch, which matches the end-user expectation much better.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Please correct me if I misunderstood the intention.
Having writing all the above and then looking at the patch again, it
is not immediately obvious to me where you use "rebase" when doing
the initial checkout, though.
> The current Documentation/git-submodule.txt has:
>
> 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`.
Side note but doesn't Francesco's "'checkout' is a valid update mode"
need to update this part of the documentation as well?
> git-submodule.sh | 34 ++++++++++++++++++++--------------
> 1 file changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 2979197..167d4fa 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -253,6 +253,7 @@ module_clone()
> url=$3
> reference="$4"
> depth="$5"
> + branch="$6"
> quiet=
> if test -n "$GIT_QUIET"
> then
> @@ -306,7 +307,15 @@ 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")
> + (
> + clear_local_git_env
> + cd "$sm_path" &&
> + GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
> + case "$branch" in
> + '') git checkout -f -q ;;
> + ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
> + esac
> + ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
> }
>
> isnumber()
> @@ -469,16 +478,7 @@ Use -f if you really want to add it." >&2
> echo "$(eval_gettext "Reactivating local git directory for submodule '\$sm_name'.")"
> fi
> fi
> - module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" || exit
> - (
> - clear_local_git_env
> - cd "$sm_path" &&
> - # ash fails to wordsplit ${branch:+-b "$branch"...}
> - case "$branch" in
> - '') git checkout -f -q ;;
> - ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
> - esac
> - ) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
> + module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" "$branch" || exit
> fi
> git config submodule."$sm_name".url "$realrepo"
>
> @@ -787,7 +787,8 @@ cmd_update()
> fi
> name=$(module_name "$sm_path") || exit
> url=$(git config submodule."$name".url)
> - branch=$(get_submodule_config "$name" branch master)
> + config_branch=$(get_submodule_config "$name" branch)
> + branch="${config_branch:-master}"
> if ! test -z "$update"
> then
> update_module=$update
> @@ -815,7 +816,7 @@ Maybe you want to use 'update --init'?")"
>
> if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
> then
> - module_clone "$sm_path" "$name" "$url" "$reference" "$depth" || exit
> + module_clone "$sm_path" "$name" "$url" "$reference" "$depth" "$config_branch" || exit
> cloned_modules="$cloned_modules;$name"
> subsha1=
> else
> @@ -861,7 +862,12 @@ Maybe you want to use 'update --init'?")"
> case ";$cloned_modules;" in
> *";$name;"*)
> # then there is no local change to integrate
> - update_module= ;;
> + if test -n "$config_branch"; then
> + update_module="!git reset --hard -q"
> + else
> + update_module=
> + fi
> + ;;
> esac
>
> must_die_on_failure=
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-06 23:32 ` Francesco Pretto
@ 2014-01-07 18:27 ` Junio C Hamano
2014-01-07 19:19 ` Francesco Pretto
0 siblings, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-07 18:27 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Heiko Voigt, W. Trevor King, Git, Jens Lehmann
Francesco Pretto <ceztko@gmail.com> writes:
> 2014/1/7 Francesco Pretto <ceztko@gmail.com>:
>> To not break the existing behavior what it's really needed here, IMO,
>> is a "submodule.<name>.attached" property that says two things:
>> - at the first clone on "git submodule update" stay attached to
>> "submodule.<name>.branch";
>> - implies "--remote", as it's the only thing that makes sense when the
>> submodules are attached.
>>
>
> Unless you decide to go with the proposed approach of Trevor, where
> "submodule.<name>.branch" set means attached (if it's not changed:
> this thread is quite hard to follow...). To this end, Junio could sync
> with more "long-timers" (Heiko?) submodule users/devs to understand if
> this breaks too much or not.
It is not immediately obvious to me why anybody who specifies the
submodule.*.branch variable to say "I want _that_ branch" not to
want to be on that branch but in a detached state, so from that
perspective, submodule.*.attach feels superfluous.
But I'd mostly defer the design discussion to Heiko (and Jens), WTK
and you.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-07 18:15 ` Junio C Hamano
@ 2014-01-07 18:47 ` W. Trevor King
2014-01-07 19:21 ` Junio C Hamano
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-07 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git, Francesco Pretto, Jens Lehmann, Heiko Voigt
[-- Attachment #1: Type: text/plain, Size: 2867 bytes --]
On Tue, Jan 07, 2014 at 10:15:25AM -0800, Junio C Hamano wrote:
> submodule: respect requested branch on all clones
>
> The previous code only checked out the requested branch in cmd_add
> but not in cmd_update; this left the user on a detached HEAD after
> an update initially cloned, and subsequent updates using rebase or
> merge mode will kept the HEAD detached, unless the user moved to the
> desired branch himself.
>
> Move the branch-checkout logic into module_clone, where it can be
> shared by cmd_add and cmd_update. Also update the initial checkout
> command to use 'rebase' to preserve branches setup during
> module_clone. This way, unless the user explicitly asks to work on
> a detached HEAD, subsequent updates all happen on the specified
> branch, which matches the end-user expectation much better.
This looks reasonable to me, but there are still changes I'd like to
make for a v3 (e.g. using submodule.<name>.update to trigger local
branch checkout). However, I'm currently leaning towards a new 'git
submodule checkout' command with explicit preferred local submodule
branches (see [1]). Maybe this should all wait until Jens rolls out
his update implementation [2]?
> Having writing all the above and then looking at the patch again, it
> is not immediately obvious to me where you use "rebase" when doing
> the initial checkout, though.
It's used to shift the local branch reference from from the
(arbitrary) cloned remote branch tip to the explicit submodule $sha1.
Otherwise the default method for that operation is a HEAD-detaching
'checkout'. I tried to explain it here [3].
> "W. Trevor King" <wking@tremily.us> writes:
> > The current Documentation/git-submodule.txt has:
> >
> > 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`.
>
> Side note but doesn't Francesco's "'checkout' is a valid update mode"
> need to update this part of the documentation as well?
That would be nice. I don't think his patch changes the docs, and I
don't know if mentioning the --checkout option belongs in that patch
as well, or in a separate fixup ;).
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/240097
[2]: http://article.gmane.org/gmane.comp.version-control.git/240117
[3]: http://article.gmane.org/gmane.comp.version-control.git/239953
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-06 17:47 ` Francesco Pretto
2014-01-06 19:21 ` David Engster
2014-01-07 4:10 ` W. Trevor King
@ 2014-01-07 18:56 ` Junio C Hamano
2014-01-07 19:44 ` Francesco Pretto
2014-01-07 19:07 ` Junio C Hamano
3 siblings, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-07 18:56 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Heiko Voigt, git, Jens Lehmann, W. Trevor King
Francesco Pretto <ceztko@gmail.com> writes:
>>> > - 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".
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?
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-06 17:47 ` Francesco Pretto
` (2 preceding siblings ...)
2014-01-07 18:56 ` Junio C Hamano
@ 2014-01-07 19:07 ` Junio C Hamano
2014-01-07 19:25 ` Francesco Pretto
3 siblings, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-07 19:07 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Heiko Voigt, git, Jens Lehmann, W. Trevor King
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?
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-07 18:27 ` Junio C Hamano
@ 2014-01-07 19:19 ` Francesco Pretto
2014-01-07 19:45 ` W. Trevor King
2014-01-07 19:52 ` Francesco Pretto
0 siblings, 2 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-07 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Heiko Voigt, W. Trevor King, Git, Jens Lehmann
2014/1/7 Junio C Hamano <gitster@pobox.com>:
>> Unless you decide to go with the proposed approach of Trevor, where
>> "submodule.<name>.branch" set means attached (if it's not changed:
>> this thread is quite hard to follow...). To this end, Junio could sync
>> with more "long-timers" (Heiko?) submodule users/devs to understand if
>> this breaks too much or not.
>
> It is not immediately obvious to me why anybody who specifies the
> submodule.*.branch variable to say "I want _that_ branch" not to
> want to be on that branch but in a detached state, so from that
> perspective, submodule.*.attach feels superfluous.
>
Junio, for what it concerns me I fully support this patch as, IMO, it
makes cleaner the role of the property "submodule.<name>.branch".
Because with my original proposal I decided to go non-breaking Heiko
and Jens could also take position on this because this patch will
represent a small behavior break.
Also, and important feature should be added together with this patch:
a way to go "--remote" by default on an attached HEAD. This can be
done at least in two ways:
- explicit, non breaking way: add a "submodule.<name>.remote"
property. When set to "true" it implies "--remote" when doing "git
submodule update", both on attached and detached HEAD;
- implicit, breaking way: assume "--remote" when doing "git submodule
update" on an attached HEAD. I am quite sure this will break a couple
of submodule tests (I already tried it), probably for marginal
reasons.
I think this is needed because it makes little sense to having an
attached HEAD and "git submodule update" does nothing.
Thank you,
Francesco
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-07 18:47 ` W. Trevor King
@ 2014-01-07 19:21 ` Junio C Hamano
2014-01-07 19:50 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-07 19:21 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Francesco Pretto, Jens Lehmann, Heiko Voigt
"W. Trevor King" <wking@tremily.us> writes:
> On Tue, Jan 07, 2014 at 10:15:25AM -0800, Junio C Hamano wrote:
>> submodule: respect requested branch on all clones
>>
>> The previous code only checked out the requested branch in cmd_add
>> but not in cmd_update; this left the user on a detached HEAD after
>> an update initially cloned, and subsequent updates using rebase or
>> merge mode will kept the HEAD detached, unless the user moved to the
>> desired branch himself.
>>
>> Move the branch-checkout logic into module_clone, where it can be
>> shared by cmd_add and cmd_update. Also update the initial checkout
>> command to use 'rebase' to preserve branches setup during
>> module_clone. This way, unless the user explicitly asks to work on
>> a detached HEAD, subsequent updates all happen on the specified
>> branch, which matches the end-user expectation much better.
>
> This looks reasonable to me, but there are still changes I'd like to
> make for a v3 (e.g. using submodule.<name>.update to trigger local
> branch checkout). However, I'm currently leaning towards a new 'git
> submodule checkout' command with explicit preferred local submodule
> branches (see [1]). Maybe this should all wait until Jens rolls out
> his update implementation [2]?
Sounds good. I'll backburner this one, then.
>> Having writing all the above and then looking at the patch again, it
>> is not immediately obvious to me where you use "rebase" when doing
>> the initial checkout, though.
>
> It's used to shift the local branch reference from from the
> (arbitrary) cloned remote branch tip to the explicit submodule $sha1.
The objective is not what I was questioning. In the patch I see
git checkout -f -q -B "$branch" "origin/$branch"
used in the module_clone (which I think makes sense), and then
cmd_update uses "git reset --hard -q" to make sure that the working
tree matches the commit $sha1 obtained from the superproject's
gitlink (which may make $branch diverged from origin/$branch, but
still I think it makes sense).
But there is no 'rebase' I can see in the codepath, which was what I
was puzzled about.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-07 19:07 ` Junio C Hamano
@ 2014-01-07 19:25 ` Francesco Pretto
0 siblings, 0 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-07 19:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Heiko Voigt, git, Jens Lehmann, W. Trevor King
2014/1/7 Junio C Hamano <gitster@pobox.com>:
> 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?
>
Yep, you got it correctly.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-06 19:21 ` David Engster
@ 2014-01-07 19:27 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-07 19:27 UTC (permalink / raw)
To: David Engster
Cc: Francesco Pretto, Heiko Voigt, git, Jens Lehmann, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]
On Mon, Jan 06, 2014 at 08:21:24PM +0100, David Engster wrote:
> +-----------+
> | master | <--
> +-------+ +-----------+ | Merges to/from master
> | CEDET | | done only by CEDET developers
> +-------+ |
> +-----------+ |
> | stable | <-- <--------
> +-----------+ |
> |
> |
> | Any Emacs developer
> | can push and commit
> | submodule
> +--------+ +----------------------+ |
> | Emacs | -- | lisp/cedet submodule | <-
> +--------+ +----------------------+
This looks reasonable, and except for the detached-HEAD after the
initial update-clone, I think Git already supports everything you
need. If you set submodule.cedet.update to 'rebase' (or 'merge') you
can easily integrate your local master changes with cedet/master
(e.g. if a CEDET dev updates cedet/master before the Emacs dev has a
chance to push their fix). With the non-checkout update mode, you'll
also stay on your checked-out master branch during 'submodule update'
calls.
> 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?
If an Emacs dev in the submodule makes the CEDET change, you could use
a post-commit hook (in the CEDET submodule) to also commit the change
to the Emacs superproject). However, commiting only the submodule
bump may not be what you want. Maybe there are other superproject
changes that should be committed alongside the submodule bump. Maybe
there is stuff in the superprojects's staging area that should *not*
be committed alongside the submodule bump. This ambiguity makes it
tricky for Git to automatically do “the right thing”.
If cedet/master is updated independently by the CEDET devs, there's no
way for the local Emacs repo to know about the change, so it's
impossible to automatically update Emacs (without polling for CEDET
updates or some other transgression ;).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-07 18:56 ` Junio C Hamano
@ 2014-01-07 19:44 ` Francesco Pretto
0 siblings, 0 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-07 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Heiko Voigt, git, Jens Lehmann, W. Trevor King
2014/1/7 Junio C Hamano <gitster@pobox.com>:
> 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?
>
Because of the overlapping change with the the other patch proposed by
Trevor, and to not generate confusion, I will stop for now pursuing
for an "attach|detach" command/switch specific for submodules, waiting
for Trevors's patch possible acceptance. After that I will see it
still makes sense or not.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-07 19:19 ` Francesco Pretto
@ 2014-01-07 19:45 ` W. Trevor King
2014-01-07 19:48 ` Francesco Pretto
2014-01-07 22:38 ` Heiko Voigt
2014-01-07 19:52 ` Francesco Pretto
1 sibling, 2 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-07 19:45 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Junio C Hamano, Heiko Voigt, Git, Jens Lehmann
[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]
On Tue, Jan 07, 2014 at 08:19:49PM +0100, Francesco Pretto wrote:
> 2014/1/7 Junio C Hamano <gitster@pobox.com>:
> > It is not immediately obvious to me why anybody who specifies the
> > submodule.*.branch variable to say "I want _that_ branch" not to
> > want to be on that branch but in a detached state, so from that
> > perspective, submodule.*.attach feels superfluous.
>
> Junio, for what it concerns me I fully support this patch as, IMO, it
> makes cleaner the role of the property "submodule.<name>.branch".
No, submodule.<name>.branch is the name of the remote-tracking branch
for 'update --remote'. In this patch, I'm using it as a hint for the
preferred local branch name [1], which I now think was a bad idea.
After [2], I think that we should just define the preferred local
branch name explicitly (submodule.<name>.local-branch?).
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/239980
[2]: http://article.gmane.org/gmane.comp.version-control.git/240097
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-07 19:45 ` W. Trevor King
@ 2014-01-07 19:48 ` Francesco Pretto
2014-01-07 21:37 ` W. Trevor King
2014-01-07 22:38 ` Heiko Voigt
1 sibling, 1 reply; 144+ messages in thread
From: Francesco Pretto @ 2014-01-07 19:48 UTC (permalink / raw)
To: W. Trevor King; +Cc: Junio C Hamano, Heiko Voigt, Git, Jens Lehmann
2014/1/7 W. Trevor King <wking@tremily.us>:
>> Junio, for what it concerns me I fully support this patch as, IMO, it
>> makes cleaner the role of the property "submodule.<name>.branch".
>
> No.
Trevor, maybe it was not clear. But I wanted to say:
" I fully support *Trevor's* patch..." :)
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-07 19:21 ` Junio C Hamano
@ 2014-01-07 19:50 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-07 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git, Francesco Pretto, Jens Lehmann, Heiko Voigt
[-- Attachment #1: Type: text/plain, Size: 1280 bytes --]
On Tue, Jan 07, 2014 at 11:21:28AM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> > On Tue, Jan 07, 2014 at 10:15:25AM -0800, Junio C Hamano wrote:
> >> Having writing all the above and then looking at the patch again, it
> >> is not immediately obvious to me where you use "rebase" when doing
> >> the initial checkout, though.
> >
> > It's used to shift the local branch reference from from the
> > (arbitrary) cloned remote branch tip to the explicit submodule $sha1.
>
> The objective is not what I was questioning. In the patch I see
>
> git checkout -f -q -B "$branch" "origin/$branch"
>
> used in the module_clone (which I think makes sense), and then
> cmd_update uses "git reset --hard -q" to make sure that the working
> tree matches the commit $sha1 obtained from the superproject's
> gitlink (which may make $branch diverged from origin/$branch, but
> still I think it makes sense).
>
> But there is no 'rebase' I can see in the codepath, which was what I
> was puzzled about.
Ah, thanks. s/rebase/reset/ in the commit message ;).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-07 19:19 ` Francesco Pretto
2014-01-07 19:45 ` W. Trevor King
@ 2014-01-07 19:52 ` Francesco Pretto
1 sibling, 0 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-07 19:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Heiko Voigt, W. Trevor King, Git, Jens Lehmann
2014/1/7 Francesco Pretto <ceztko@gmail.com>:
> 2014/1/7 Junio C Hamano <gitster@pobox.com>:
>> It is not immediately obvious to me why anybody who specifies the
>> submodule.*.branch variable to say "I want _that_ branch" not to
>> want to be on that branch but in a detached state, so from that
>> perspective, submodule.*.attach feels superfluous.
>>
>
> Junio, for what it concerns me I fully support *this* patch as,
Where "this" patch is Trevor's one, don't get me wrong... :)
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-07 19:48 ` Francesco Pretto
@ 2014-01-07 21:37 ` W. Trevor King
2014-01-07 21:51 ` Francesco Pretto
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-07 21:37 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Junio C Hamano, Heiko Voigt, Git, Jens Lehmann
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
On Tue, Jan 07, 2014 at 09:09:19PM +0100, Francesco Pretto wrote:
> 2014/1/7 W. Trevor King <wking@tremily.us>:
> >> Trevor, maybe it was not clear. But I wanted to say:
> >>
> >> " I fully support *Trevor's* patch..." :)
> >
> > Which I appreciate ;). I still though I should point out that my
> > patch *confuses* the role of submodule.<name>.branch :p.
>
> You are welcome. Also, at your wish, can you please reply also in
> public?
Here you go.
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.
It would also be nice if submodule.<name>.branch was just an initial
setup-time and detached-HEAD default. If the submodule is on a branch
it would make more sense to use the checked-out branch's @{upstream}.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-07 21:37 ` W. Trevor King
@ 2014-01-07 21:51 ` Francesco Pretto
0 siblings, 0 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-07 21:51 UTC (permalink / raw)
To: W. Trevor King; +Cc: Junio C Hamano, Heiko Voigt, Git, Jens Lehmann
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: I didn't proposed
such feature. I just wanted the attached submodule use case to be
supported and of course "--branch means attached" is even easier to
get this.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Preferred local submodule branches (was: Introduce git submodule attached update)
2014-01-07 4:10 ` W. Trevor King
@ 2014-01-07 22:36 ` W. Trevor King
2014-01-07 23:52 ` W. Trevor King
2014-01-07 22:51 ` Re: [PATCH 2/2] Introduce git submodule attached update Heiko Voigt
1 sibling, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-07 22:36 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Heiko Voigt, git, Jens Lehmann, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]
On Tue, Jan 07, 2014 at 10:51:34PM +0100, Francesco Pretto wrote:
> 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:
I'm grafting this discussion back on to the thread where I proposed
submodule.<name>.local-branch.
> I didn't proposed such feature.
Right. I proposed this feature after reading your proposed workflow.
> I just wanted the attached submodule use case to be supported and of
> course "--branch means attached" is even easier to get this.
As I understood it, the '--branch means attached' stuff was tied up
with automatic --remote updates.
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].
Cheers,
Trevor
[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
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-07 19:45 ` W. Trevor King
2014-01-07 19:48 ` Francesco Pretto
@ 2014-01-07 22:38 ` Heiko Voigt
2014-01-08 0:17 ` Francesco Pretto
1 sibling, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-07 22:38 UTC (permalink / raw)
To: W. Trevor King; +Cc: Francesco Pretto, Junio C Hamano, Git, Jens Lehmann
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
here my current thoughts in a kind of summary email.
On Tue, Jan 07, 2014 at 11:45:03AM -0800, W. Trevor King wrote:
> On Tue, Jan 07, 2014 at 08:19:49PM +0100, Francesco Pretto wrote:
> > 2014/1/7 Junio C Hamano <gitster@pobox.com>:
> > > It is not immediately obvious to me why anybody who specifies the
> > > submodule.*.branch variable to say "I want _that_ branch" not to
> > > want to be on that branch but in a detached state, so from that
> > > perspective, submodule.*.attach feels superfluous.
> >
> > Junio, for what it concerns me I fully support this patch as, IMO, it
> > makes cleaner the role of the property "submodule.<name>.branch".
>
> No, submodule.<name>.branch is the name of the remote-tracking branch
> for 'update --remote'. In this patch, I'm using it as a hint for the
> preferred local branch name [1], which I now think was a bad idea.
> After [2], I think that we should just define the preferred local
> branch name explicitly (submodule.<name>.local-branch?).
I am not so sure about that. Having an extra value adds more
configuration burden to the user and it also does not help to understand
how this feature is supposed to be used.
Even though I was confused in the first place by the remote/local branch
switch for this option, after thinking a little bit more about it I
think it makes perfect sense to use the branch option as a hint for the
local branch.
Let me explain by an example. Suppose we have the following setup:
1. Fast-forward situation
superproject submodule
master PA--------------->A master
|
B origin/master
Lets say superproject has submodule.submodule.branch=master and
submodule.submodule.update=merge.
Doing the initial update which clones results in the submodules master
branch being set to the sha1 registered in the superproject.
Now an update to the newest master in submodule is straightforward:
$ git submodule update --remote
2. Direct work situation
The developer start with the same setup as in situation 1 but now
directly starts to work in the submodule and creates commit C.
superproject submodule
master PA--------------->A
|\
origin/master B C master
$ git submodule update --remote
$ git commit -a -m "update submodule"
gets him this:
superproject submodule
PA--------------->A
| |\
| origin/master B C
| |/
master PB--------------->D master
Where now both the submodule and the superproject can be directly
pushed. If origin/master in the submodule is tracked by master this is
actually one command
$ git push --recurse-submodules=on-demand
So with your (Trevors) patch and reusing submodule.<name>.branch using
this kind of direct work in submodules is made easy. And wasn't that
what people always requested? ;-) Well, at least if you do not use
feature branches this makes it easy. But I think that is a good start
make the simple things easy first. Then we can later discuss the more
complicated ones. It seems to me that is also the case David wants for
his emacs/CEDET workflow: Make it easy for the superproject developers
to directly push out trivial fixes to the submodule.
And it also seems to me that is want Francesco wants.
One thing is missing though (and I think thats where Francesco came
from): What if the developer already has a detached HEAD in the
submodule?
How does he attach to a branch? For this we need something similar to
Francescos attach/detach or Trevors submodule checkout with Junio's checkout
HEAD~0 from here[1].
I am still undecided how we should call it. Because of my
Idea for feature branch support
- -------------------------------
For the branch attaching feature I would also like something that can actually
modify .git/config and for me more importantly .gitmodules.
So e.g. if I want to work on a longer lived feature branch in a submodule which
I need in a feature branch in the superproject I would do something like this:
$ git submodule checkout --gitmodules --merge -b hv/my-cool-feature
Which should create a local feature branch hv/my-cool-feature in the submodule,
checkout that branch and modify .gitmodules (because of --gitmodules) to have
submodule.<name>.update=merge, submodule.<name>.branch=hv/my-cool-feature and
stage that to the index.
This is a temporary setting so everyone who is working together can update
their branches easily. Once finished (with the prove that the big feature in
the superproject works) everyone can go and polish the submodule branches,
get their changes accepted there first, and then the update/branch setting
local for this branch will be dropped. In this workflow these settings never
enter a stable branch but are still very useful to transport this information
while developing.
Just an idea of a future extension we should keep in mind when designing the
command to attach to a branch. But maybe the command to configure this should
be completely independent from checkout. I.e.:
git submodule checkout - syncs to a possible update/branch
git submodule attach - creates a submodule branch and configures
update/branch in .git/config or .gitmodules
git submodule detach? - reverse attach
or maybe --attach and --detach in this scenario could be options to checkout?
Still unsure...
Cheers Heiko
[1] http://article.gmane.org/gmane.comp.version-control.git/240097
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iEYEARECAAYFAlLMggIACgkQjLR3Aoip+rpoMACgpn4XzDD4CvD+HCi8coIlwueP
gQUAn1v1BSJ+k8IJT7S/hwtojT+sUmgP
=GGTX
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-07 4:10 ` W. Trevor King
2014-01-07 22:36 ` Preferred local submodule branches (was: Introduce git submodule attached update) W. Trevor King
@ 2014-01-07 22:51 ` Heiko Voigt
2014-01-07 23:14 ` W. Trevor King
1 sibling, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-07 22:51 UTC (permalink / raw)
To: W. Trevor King; +Cc: Francesco Pretto, git, Jens Lehmann, Junio C Hamano
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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. But AFAIK it should
trigger the "you are leaving commits from a detached HEAD behind"
warning, so there is some safeguard and recovery.
Cheers Heiko
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iEYEARECAAYFAlLMhPAACgkQjLR3Aoip+rqP6wCeIhtpWLJC3XVO3nu2ViQTbHPg
T5wAoLLEZ256GOOjBxoTKo2/FmfvQGLp
=+bqm
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH 2/2] Introduce git submodule attached update
2014-01-07 22:51 ` Re: [PATCH 2/2] Introduce git submodule attached update Heiko Voigt
@ 2014-01-07 23:14 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-07 23:14 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Francesco Pretto, git, Jens Lehmann, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]
On Tue, Jan 07, 2014 at 11:51:28PM +0100, Heiko Voigt wrote:
> 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.
Only if you use the checkout strategy. With --merge or --rebase,
you'll have the $sha1 (or upstream remote with --remote) integrated
with your detached HEAD work. You end up with a new detached HEAD
containing the result of the integration (just confirmed with tests
using Git v1.8.3.2). That seems reasonable to me, so I'm happy with
the integration logic.
> But AFAIK it should trigger the "you are leaving commits from a
> detached HEAD behind" warning, so there is some safeguard and
> recovery.
I did not see those in testing with Git v1.8.3.2, likely because of
the '-f -q' we pass to 'git checkout' for checkout-mode updates.
Regardless of branch integration issues, I think a
per-superproject-branch preferred submodule branch is important for
'git checkout' to work in the superproject. If you want:
* submodule branch master for superproject branch master, and
* submodule branch my-feature for superproject branch my-feature,
$ git checkout my-feature
in the superproject is currently going to leave you with the submodule
on master, which is not convenient ;). I think we should come up with
a better solution to the superproject checkout problem before adding
in additional complications due to branch integration ;).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Preferred local submodule branches (was: Introduce git submodule attached update)
2014-01-07 22:36 ` Preferred local submodule branches (was: Introduce git submodule attached update) W. Trevor King
@ 2014-01-07 23:52 ` W. Trevor King
2014-01-08 3:47 ` Preferred local submodule branches W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-07 23:52 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Heiko Voigt, git, Jens Lehmann, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 2802 bytes --]
On Tue, Jan 07, 2014 at 02:36:25PM -0800, W. Trevor King wrote:
> 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
For example, in Jonathan's recent version of Jens' series, the
initial-setup and update functionality are moving into C. See:
* populate_submodule() [1] for the initial-clone setup (calling
'read-tree'), and
* update_submodule() [2] for subsequent updates (calling 'checkout -q'
with an optional '-f')
this is where any submodule.<name>.local-branch would come into play,
if we decide to go down that route. It doesn't look like the C
updates have the auto-clone functionality that the Bash updates have.
I'm not sure if that's in the pipe or not. I'm not as familiar with
the C implementation though, so maybe I'm missing the mark here.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/239698
[2]: http://article.gmane.org/gmane.comp.version-control.git/239699
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-07 22:38 ` Heiko Voigt
@ 2014-01-08 0:17 ` Francesco Pretto
2014-01-08 1:05 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Francesco Pretto @ 2014-01-08 0:17 UTC (permalink / raw)
To: Heiko Voigt; +Cc: W. Trevor King, Junio C Hamano, Git, Jens Lehmann
2014/1/7 Heiko Voigt <hvoigt@hvoigt.net>:
> One thing is missing though (and I think thats where Francesco came
> from): What if the developer already has a detached HEAD in the
> submodule?
>
> How does he attach to a branch? For this we need something similar to
> Francescos attach/detach or Trevors submodule checkout with Junio's checkout
> HEAD~0 from here[1].
>
> I am still undecided how we should call it. Because of my
>
> Idea for feature branch support
> - -------------------------------
>
> For the branch attaching feature I would also like something that can actually
> modify .git/config and for me more importantly .gitmodules.
>
> So e.g. if I want to work on a longer lived feature branch in a submodule which
> I need in a feature branch in the superproject I would do something like this:
>
> $ git submodule checkout --gitmodules --merge -b hv/my-cool-feature
>
I said in another thread I said to Junio am not pursuing
--attach|--detach anymore, but seeing that now everybody seem to be
excited about attached HEAD here we are...
Heiko, it's all day I think this syntax: it supports your above "git
submodule checkout" and more. Take attention at the feature branch
part!
NOTE: the following seems to me compatible with Trevor's
"submodule.<module>.branch means attached" patch.
git submodule head
================
The full syntax is the sum of the following ones:
git submodule head [-b <branch>] [--attach] [--] [<path>...]
git submodule head [-b <branch>] [--attach] --index [--] [<path>...]
git submodule head --reset [--] [<path>...]
git submodule head --reset --index [--] [<path>...]
(NOTE: --index should be the same as Heiko's above --gitmodules, it
means -> touch .gitmodules)
All the switches combinations follow, explained:
# Attach the submodule HEAD to <branch>.
# Also set ".git/config" 'submodule.<module>.branch' to <branch>
$ git submodule head -b <branch> --attach <module>
# Attach the submodule HEAD to 'submodule.<module>.branch'.
# If it does not exists defaults to <remote>/master
$ git submodule head --attach <module>
# 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>
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>
---------------------------------------------------------------------
Also note that a --detach switch is not needed with Trevor's patch. To
resync to a dettached HEAD workflow, when 'submodule.<module>.branch'
is unset in ".gitmodule", --reset (without --index) should be enough.
What do you think? Better?
Thank you,
Francesco
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-08 0:17 ` Francesco Pretto
@ 2014-01-08 1:05 ` W. Trevor King
2014-01-08 2:12 ` Francesco Pretto
` (2 more replies)
0 siblings, 3 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-08 1:05 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Heiko Voigt, Junio C Hamano, Git, Jens Lehmann
[-- Attachment #1: Type: text/plain, Size: 4079 bytes --]
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 prefer submodule.<name>.local-branch for the submodule's local
branch name. I also prefer 'checkout' to 'head', because 'checkout'
already exists in non-submodule Git for switching between local
branches.
> # Attach the submodule HEAD to 'submodule.<module>.branch'.
> # If it does not exists defaults to <remote>/master
> $ git submodule head --attach <module>
Defaulting to the configured local branch is fine, but I think it
should default to 'master' if no local branch is configured. This
should not have anything to do with remote-tracking branches (that's
what 'submodule update' already handles). I don't understand why
remote-tracking-branch integration keeps getting mixed up with
local-branch checkout.
> # 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). 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].
> 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.
> What do you think? Better?
I don't think so. 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 deal-breaker for recycling submodule.<name>.branch to also mean
the local branch name is the {my-feature, my-feature, master} case.
Do we want to force submodule developers to always match the upstream
name of the feature branch they'd like to integrate with? What if
there is no upstream my-feature branch (and the superproject developer
pushes submodule branches upstream via email)? Making the local
branch name independently configurable avoids these issues with a
minimal increase in complexity.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/240177
[2]: http://article.gmane.org/gmane.comp.version-control.git/240180
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-08 1:05 ` W. Trevor King
@ 2014-01-08 2:12 ` Francesco Pretto
2014-01-08 23:07 ` Francesco Pretto
2014-01-08 23:54 ` Re: [RFC v2] submodule: Respect requested branch on all clones Francesco Pretto
2 siblings, 0 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-08 2:12 UTC (permalink / raw)
To: W. Trevor King; +Cc: Heiko Voigt, Junio C Hamano, Git, Jens Lehmann
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. Also, you
didn't update the patch. If you were endorsed by someone (Junio,
Heiko, ...) for the "submodule.<name>.local-branch" feature please
show me where.
I somehow understand the point of the
"submodule.<name>.local-branch" property, but I can't "see" the the
workflow. Please, show me some hypothetical scripting example with as
much complete as possible workflow (creation, developer update,
mantainers creates feature branch, developer update, developer attach
to another branch). Also, consider I proposed to support the attached
HEAD path to reduce complexity and support a simpler use case for
git submodules. I would be disappointed if the complexity is reduced in a
way and augmented in another.
> On Wed, Jan 08, 2014 at 01:17:49AM +0100, Francesco Pretto wrote:
>> # Attach the submodule HEAD to <branch>.
>> # Also set ".git/config" 'submodule.<module>.branch' to <branch>
>> $ git submodule head -b <branch> --attach <module>
> [...]
> I also prefer 'checkout' to 'head', because 'checkout'
> already exists in non-submodule Git for switching between local
> branches.
>
I can agree with similarity to other git commands, but 'checkout' does
not give me the idea of something that writes to ".git/config" or
".gitmodules".
>> # Attach the submodule HEAD to 'submodule.<module>.branch'.
>> # If it does not exists defaults to <remote>/master
>> $ git submodule head --attach <module>
>
> Defaulting to the configured local branch is fine, but I think it
> should default to 'master' if no local branch is configured. This
> should not have anything to do with remote-tracking branches (that's
> what 'submodule update' already handles). I don't understand why
> remote-tracking-branch integration keeps getting mixed up with
> local-branch checkout.
>
Yep, it should default to "master", my fault.
>> # Unset ".git/config" 'submodule.<module>.branch'
>> # Also attach or detach the HEAD according to what is in ".gitmodules":
>> # with Trevor's patch 'submodule.<module>.branch' set means attached,
>> # unset means detached
>> $ git submodule head --reset <module>
>
> To me this reads “always detach HEAD” (because it unsets
> submodule.<name>.branch, and submodule.<name>.branch unset means
> detached).
I disagree: this would remove only the value in ".git/config". If the
value is till present in ".gitmodules", as I wrote above, the behavior
of what is in the index should be respected as for the other
properties. Also it gives a nice meaning to a switch like --reset :
return to how it was before.
>> NOTE: feature branch part!
>>
>> # Set ".gitmodules" 'submodule.<module>.branch' to <branch>
>> $ git submodule head -b <branch> --attach --index <module>
>>
>> # Unset ".gitmodules" 'submodule.<module>.branch'
>> $ git submodule head --reset --index <module>
>> ---------------------------------------------------------------------
>
> These are just manipulating .gitmodules. I think we also need
> per-superproject-branch configs under the superproject's .git/ for
> developer overrides.
>
I disagree: in my idea the --index switch is a maintainer only command
to modify the behavior of the developers and touch only indexed files
(.gitmodules, or create a new submodule branch). It expressly don't
touch .git/config.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Preferred local submodule branches
2014-01-07 23:52 ` W. Trevor King
@ 2014-01-08 3:47 ` W. Trevor King
2014-01-08 4:06 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-08 3:47 UTC (permalink / raw)
To: Francesco Pretto
Cc: Heiko Voigt, git, Jens Lehmann, Jonathan Nieder, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 8904 bytes --]
On Wed, Jan 08, 2014 at 03:12:44AM +0100, Francesco Pretto wrote:
> 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 tried to refocus things (with a new subject) in this sub-thread.
Hopefully that helps make the discussion more linear ;).
> Also, you didn't update the patch.
I'm waiting [1] to see how the C-level checkout by Jens and Jonathan
progresses [2,3] before writing more code.
> If you were endorsed by someone (Junio, Heiko, ...) for the
> "submodule.<name>.local-branch" feature please show me where.
As far as I know, no-one else has endorsed this idea (yet :). Heiko
has expressed concern [4], but not convincingly enough (yet :) to win
me over ;).
> 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).
I've put this at the bottom of the message to avoid bothering the
tl;dr crowd, although they have probably long since tuned us out ;).
> Also, consider I proposed to support the attached HEAD path to
> reduce complexity and support a simpler use case for git
> submodules. I would be disappointed if the complexity is reduced in
> a way and augmented in another.
Agreed. I think we're all looking for the least-complex solution that
covers all (or most) reasonable workflows.
> > 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".
Neither does 'head'. We have precedence in 'git submodule add' for
embracing and extending a core git command with additional .gitmodules
manipulation. I think it's easier to pick up the submodule jargon
when we add submodule-specific side-effects to submodule-specific
commands named after their core analogs than it would be if we pick
unique names for the submodule-specific commands.
> >> # 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.
Ah, that makes more sense. I had confused .git/config with
“.gitmodules and .git/config”.
> >> 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.
Something that just touches the config files is syntactic sugar, so I
avoided a more detailed review and moved on to address what I saw as a
more fundamental issue (preferred submodule local branches on a
per-superproject-branch level).
Here's a detailed workflow for the {my-feature, my-feature, master}
example I roughed out before [5].
# create the subproject
mkdir subproject &&
(
cd subproject &&
git init &&
echo 'Hello, world' > README &&
git add README &&
git commit -m 'Subproject v1'
) &&
# create the superproject
mkdir superproject
(
cd superproject &&
git init &&
git submodule add ../subproject submod &&
git config -f .gitmodules submodule.submod.update merge &&
git commit -am 'Superproject v1' &&
( # 'submodule update' doesn't look in .gitmodules (yet [6]) for a
# default update mode. Copy submodule.submod.update over to
# .git/config
git submodule init
)
) &&
# start a feature branch on the superproject
(
cd superproject &&
#git checkout -b my-feature --recurse-submodules &&
( # 'git submodule checkout --recurse-submodules' doesn't exist yet, so...
git checkout -b my-feature &&
git config -f .gitmodules submodule.submod.local-branch my-feature &&
cd submod &&
git checkout -b my-feature
) &&
(
cd submod &&
echo 'Add the subproject side of this feature' > my-feature &&
git add my-feature &&
git commit -m 'Add my feature to the subproject'
) &&
echo 'Add the superproject side of this feature' > my-feature &&
git add my-feature &&
git commit -m 'Add the feature to the superproject'
) &&
# meanwhile, the subproject has been advancing
(
cd subproject &&
echo 'Goodbye, world' >> README &&
git commit -am 'Subproject v2'
) &&
# we need to get that critical advance into the superproject quick!
(
cd superproject &&
# update the master branch
#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
)
git submodule update --remote &&
git commit -am 'Catch submod up with Subproject v2' &&
# what does the history look like?
(
cd submod &&
git --no-pager log --graph --date-order --oneline --decorate --all
# * 3a22cef (HEAD, my-feature) Merge commit 'd53958b18277ce5bd6c734e9597a69bb878b31e1' into my-feature
# |\
# * | 8322dcc Add my feature to the subproject
# | * d53958b (origin/master, origin/HEAD, master) Subproject v2
# |/
# * 9813010 Subproject v1
) &&
git ls-tree master submod &&
# 160000 commit d53958b18277ce5bd6c734e9597a69bb878b31e1 submod
git ls-tree my-feature submod
# 160000 commit 3a22cef30db57f1b89251f3e434fa0bd0f1b99a2 submod
)
git --version
# git version 1.8.3.2
The currently-ugly bits could be fixed with:
* 'git submodule update' falling back on .gitmodules for
submodule.<name>.update [6].
* 'git submodule checkout -b my-feature --recurse-submodules' should
checkout the submodule.<name>.local-branch configured for the
super-project's my-feature branch (but only if that wouldn't destroy
some current submodule information). This would build on work in
Jens and Jonathans' branch [2,3].
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/240127
[2]: http://article.gmane.org/gmane.comp.version-control.git/240117
[3]: http://thread.gmane.org/gmane.comp.version-control.git/239695
[4]: http://article.gmane.org/gmane.comp.version-control.git/240178
[5]: http://article.gmane.org/gmane.comp.version-control.git/240190
[6]: http://article.gmane.org/gmane.comp.version-control.git/239246
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Preferred local submodule branches
2014-01-08 3:47 ` Preferred local submodule branches W. Trevor King
@ 2014-01-08 4:06 ` W. Trevor King
2014-01-09 6:17 ` [RFC v3 0/4] " W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-08 4:06 UTC (permalink / raw)
To: Francesco Pretto
Cc: Heiko Voigt, git, Jens Lehmann, Jonathan Nieder, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]
On Tue, Jan 07, 2014 at 07:47:08PM -0800, W. Trevor King wrote:
> #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
> )
Oops, the my-feature checkout block should have been:
#git checkout --recurse-submodules my-feature
( # 'git checkout --recurse-submodules' doesn't exist yet...
git checkout my-feature &&
cd submod &&
git checkout my-feature
)
mirroring the earlier master checkout block. Sorry for the sloppy
editing.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-08 1:05 ` W. Trevor King
2014-01-08 2:12 ` Francesco Pretto
@ 2014-01-08 23:07 ` Francesco Pretto
2014-01-09 0:03 ` W. Trevor King
2014-01-08 23:54 ` Re: [RFC v2] submodule: Respect requested branch on all clones Francesco Pretto
2 siblings, 1 reply; 144+ messages in thread
From: Francesco Pretto @ 2014-01-08 23:07 UTC (permalink / raw)
To: W. Trevor King; +Cc: Heiko Voigt, Junio C Hamano, Git, Jens Lehmann
2014/1/8 W. Trevor King <wking@tremily.us>:
> 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.
>
After long thoughts, I think your idea about a local branch with a
differently named remote branch looks interesting but I would be
extremely cautious to add a ' submodule.<name>.local-branch' now. Do
we have a similar mechanism on regular repository clones? We can clone
and switch to a branch other than "master" by default, but can we also
have a different remote by default? If we don't have it, we shouldn't
add it first on submodules, as there's the chance the feature never
get coupled on the regular clones.
Also, I think you fear too much that this can't be added also later.
I think you should pursue your initial proposal of "--branch means
attached" to get it upstream first. It's alone, IMO, a great
improvement on submodules.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-08 1:05 ` W. Trevor King
2014-01-08 2:12 ` Francesco Pretto
2014-01-08 23:07 ` Francesco Pretto
@ 2014-01-08 23:54 ` Francesco Pretto
2014-01-09 0:23 ` W. Trevor King
2 siblings, 1 reply; 144+ messages in thread
From: Francesco Pretto @ 2014-01-08 23:54 UTC (permalink / raw)
To: W. Trevor King; +Cc: Heiko Voigt, Junio C Hamano, Git, Jens Lehmann
2014/1/8 W. Trevor King <wking@tremily.us>:
> I also prefer 'checkout' to 'head', because 'checkout'
> already exists in non-submodule Git for switching between local
> branches.
>
Reasons I would loosely support 'git submodule checkout'
--------------------------------------------------------------------------------
1) It's true that 'git submodule checkout' would also often run 'git checkout'.
Reasons, as an user, I seriously would *not* like 'git submodule checkout'
-----------------------------------------------------------------------------------------------------
1) 'git submodule checkout' would also touch '.git/config' and
'.gitmodules', and I don't like much the idea of a 'checkout' command
touching config files. It looks dirty.
2) Having 'git checkout', 'git checkout --recurse-submodules' and
finally 'git submodule checkout' is too much for me.
Also, in my proposal, 'git submodule [tobedecided] --attach' would
also merge orphaned commits by default, and 'checkout' is not about
merge.
Reasons I would fervently support 'git submodule head'
----------------------------------------------------------------------------
1) It tells immediately that this command is about HEAD of the
submodule, and will take care of it. Newcomers would loveit if they
don't like their HEAD state;
2) "head" is unspecific enough to admit it can also touch
'.git/config' and '.gitmodules'.
Said this, it seems Heiko[1] proposed a similar syntax and the only
difference was about names, not behavior of the command to be added
(if we eventually take this path, ofc).
> 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 prefer submodule.<name>.local-branch for the submodule's local
> branch name.
I think this was still part of your original misunderstanding about my
"git submodule head". This command would touch 'branch' property
anyway because '-b <branch>' would still be the remote branch, even in
the case you have a 'local-branch' property (maybe to be coupled here
with a --local-branch <local-branch> switch).
Greetings,
Francesco
[1] http://marc.info/?l=git&m=138913435216349&w=2
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-08 23:07 ` Francesco Pretto
@ 2014-01-09 0:03 ` W. Trevor King
2014-01-09 1:09 ` Francesco Pretto
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-09 0:03 UTC (permalink / raw)
To: Francesco Pretto
Cc: Heiko Voigt, Junio C Hamano, Git, Jens Lehmann, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 3215 bytes --]
On Thu, Jan 09, 2014 at 12:07:56AM +0100, Francesco Pretto wrote:
> After long thoughts, I think your idea about a local branch with a
> differently named remote branch looks interesting but I would be
> extremely cautious to add a ' submodule.<name>.local-branch' now. Do
> we have a similar mechanism on regular repository clones?
The default upstream branch is currently configured with
branch.<name>.merge. Earlier [1], I suggested we piggyback on this
for the submodule's upstream branches, and only use
submodule.<name>.branch for the initial setup. That would allow
developers to configure upstreams on a per-submodule-branch basis. We
should probably fall back to submodule.<name>.branch if the submodule
does not have a branch.<name>.merge configured.
However, submodule.<name>.local-branch has nothing to do with remote
repositories or tracking branches. It just selects the preferred
submodule branch for the superproject branch. This will only work for
in-tree .gitmodules configs (since the contents are per-branch). I
don't have a good idea for where local overrides would live. We'd
want something like
branch.<superproject-branch>.submodule.<submodule-name>.local-branch:
[branch "my-feature"]
remote = origin
merge = refs/heads/my-feature
[submodule "submod"]
local-branch = "my-feature"
and I don't think Git's config supports such nesting.
> We can clone and switch to a branch other than "master" by default,
> but can we also have a different remote by default?
Sure, the existing submodule.<name>.url defines the remote repository,
and the existing submodule.<name>.branch defines the remote branch.
The existing code even sets up remote.origin.url and
branch.<name>.merge (to the matching refs/heads/<name>) in the the
submodule's config.
> Also, I think you fear too much that this can't be added also later.
We can add submodule.<name>.local-branch support later, but I see no
reason not to add it on top of Jens and Jonathan's current submodule
checkout work. With increasingly robust submodule checkout support in
the core, I expect the amount of update logic stored in
git-submodule.sh will decrease significantly.
> I think you should pursue your initial proposal of "--branch means
> attached" to get it upstream first. It's alone, IMO, a great
> improvement on submodules.
I can resuscitate that if folks want, but Heiko felt that my initial
consolidation didn't go far enough [2]. If it turns out that we're ok
with the current level of consolidation, would you be ok with
"non-checkout submodule.<name>.update" as the trigger [3]? I think
that adding a halfway step between the current status and full(ish)
submodule.<name>.local-branch support is just going to confuse people
;).
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/240164
[2]: http://article.gmane.org/gmane.comp.version-control.git/239968
[3]: http://article.gmane.org/gmane.comp.version-control.git/239973
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-08 23:54 ` Re: [RFC v2] submodule: Respect requested branch on all clones Francesco Pretto
@ 2014-01-09 0:23 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-09 0:23 UTC (permalink / raw)
To: Francesco Pretto
Cc: Heiko Voigt, Junio C Hamano, Git, Jens Lehmann, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]
On Thu, Jan 09, 2014 at 12:54:54AM +0100, Francesco Pretto wrote:
> 2) Having 'git checkout', 'git checkout --recurse-submodules' and
> finally 'git submodule checkout' is too much for me.
Agreed. Since 'git checkout' already exists and 'git checkout
--recurse-submodules' is close [1,2], I think that means we should
drop this and start arguing about adjusting 'git checkout
--recurse-submodules' to checkout branches as well ;).
> Also, in my proposal, 'git submodule [tobedecided] --attach' would
> also merge orphaned commits by default, and 'checkout' is not about
> merge.
And that's good. Bailing with “you have orphaned commits, which you
should integrate them with $some_integration_command before checking
out a different branch” is better than having overlapping
responsibilities between the checkout command and the integration
command.
Cheers,
Trevor
[1]: http://thread.gmane.org/gmane.comp.version-control.git/239695
[2]: http://article.gmane.org/gmane.comp.version-control.git/240117
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-09 0:03 ` W. Trevor King
@ 2014-01-09 1:09 ` Francesco Pretto
2014-01-09 2:22 ` W. Trevor King
2014-01-09 8:31 ` Jens Lehmann
0 siblings, 2 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-09 1:09 UTC (permalink / raw)
To: W. Trevor King
Cc: Heiko Voigt, Junio C Hamano, Git, Jens Lehmann, Jonathan Nieder
2014/1/9 W. Trevor King <wking@tremily.us>:
>
> However, submodule.<name>.local-branch has nothing to do with remote
> repositories or tracking branches.
My bad: this means the feature is still not entirely clear to me.
>
> [branch "my-feature"]
> remote = origin
> merge = refs/heads/my-feature
> [submodule "submod"]
> local-branch = "my-feature"
>
> and I don't think Git's config supports such nesting.
>
Aesthetically, It doesn't look very nice.
>
> I can resuscitate that if folks want, but Heiko felt that my initial
> consolidation didn't go far enough [2]. If it turns out that we're ok
> with the current level of consolidation, would you be ok with
> "non-checkout submodule.<name>.update" as the trigger [3]?
For me it was ok with what you did:
-------------------------------------------------
if "just_cloned" and "config_branch"
then
!git reset --hard -q"
fi
-------------------------------------------------
So yes: at the first clone 'checkout' keeps attached HEAD, while
'merge' and 'rebase' attach to the branch.
If it's not the first clone, you should take no action (and your
original patch was ok about this).
> I think
> that adding a halfway step between the current status and full(ish)
> submodule.<name>.local-branch support is just going to confuse people
Well, for now you got some success in confusing me with this "local-branch" :)
At certain point you may ask maintainers what are the accepted
features (because all these debates should be about getting, or not
getting, endorsement about something) and finalize a patch so people
can further review.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-09 1:09 ` Francesco Pretto
@ 2014-01-09 2:22 ` W. Trevor King
2014-01-09 8:31 ` Jens Lehmann
1 sibling, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-09 2:22 UTC (permalink / raw)
To: Francesco Pretto
Cc: Heiko Voigt, Junio C Hamano, Git, Jens Lehmann, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]
On Thu, Jan 09, 2014 at 02:09:37AM +0100, Francesco Pretto wrote:
> 2014/1/9 W. Trevor King <wking@tremily.us>:
> > [branch "my-feature"]
> > remote = origin
> > merge = refs/heads/my-feature
> > [submodule "submod"]
> > local-branch = "my-feature"
> >
> > and I don't think Git's config supports such nesting.
>
> Aesthetically, It doesn't look very nice.
The INI syntax does not lend itself to easy nesting, but I'm pretty
sure some mapping from (<superproject-branch>, <submodule-name>) to
<submodule-local-branch-name> is what we need for submodule checkouts.
I'm just not sure where local overides to the per-branch .gitmodules
should live. We could turn it around, and store:
[superproject "<superproject-branch>"]
local-branch = "<submodule-local-branch-name>"
in .git/modules/<submodule-name>/config, with the UI:
$ cd submodule
$ git config superproject.<superproject-branch>.local-branch = <submodule-branch>
Not beautiful, but maybe a bit more palatable, and already supported
by Git's current config parser. That's enough that I can work up a
patch that will hopefully clarify my position ;).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* [RFC v3 0/4] Preferred local submodule branches
2014-01-08 4:06 ` W. Trevor King
@ 2014-01-09 6:17 ` W. Trevor King
2014-01-09 6:17 ` [RFC v3 1/4] submodule: Add helpers for configurable local branches W. Trevor King
` (4 more replies)
0 siblings, 5 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-09 6:17 UTC (permalink / raw)
To: Git
Cc: Francesco Pretto, Junio C Hamano, Heiko Voigt, Jens Lehmann,
Jonathan Nieder, W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
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]. After this
series, I can get through:
# create the subproject
mkdir subproject &&
(
cd subproject &&
git init &&
echo 'Hello, world' > README &&
git add README &&
git commit -m 'Subproject v1'
) &&
# create the superproject
mkdir superproject
(
cd superproject &&
git init &&
git submodule add ../subproject submod &&
git config -f .gitmodules submodule.submod.update merge &&
git commit -am 'Superproject v1' &&
( # 'submodule update' doesn't look in .gitmodules (yet [4]) for a
# default update mode. Copy submodule.submod.update over to
# .git/config
git submodule init
)
) &&
# start a feature branch on the superproject
(
cd superproject &&
#git checkout -b my-feature --recurse-submodules &&
( # 'git submodule checkout --recurse-submodules' doesn't exist yet, so...
git checkout -b my-feature &&
git submodule checkout -b --gitmodules
) &&
(
cd submod &&
echo 'Add the subproject side of this feature' > my-feature &&
git add my-feature &&
git commit -m 'Add my feature to the subproject'
) &&
echo 'Add the superproject side of this feature' > my-feature &&
git add my-feature &&
git commit -am 'Add the feature to the superproject'
) &&
# meanwhile, the subproject has been advancing
(
cd subproject &&
echo 'Goodbye, world' >> README &&
git commit -am 'Subproject v2'
) &&
# we need to get that critical advance into the superproject quick!
(
cd superproject &&
# update the master branch
#git checkout --recurse-submodules master
( # 'git checkout --recurse-submodules' doesn't exist yet [5,6].
# Even with that patch, 'git checkout' won't respect
# submodule.<name>.local-branch without further work.
git checkout master &&
git submodule checkout
) &&
git submodule update --remote &&
git commit -am 'Catch submod up with Subproject v2' &&
# update the my-feature branch
#git checkout --recurse-submodules my-feature &&
( # 'git checkout --recurse-submodules' doesn't exist yet [5,6].
git checkout my-feature &&
git submodule checkout
) &&
git submodule update --remote &&
git commit -am 'Catch submod up with Subproject v2' &&
# what does the history look like?
(
cd submod &&
git --no-pager log --graph --date-order --oneline --decorate --all
# * 16d9e3e (HEAD, my-feature) Merge commit 'f5e134d5747ee4a206e96d8c017f92f5b29a07f3' into my-feature
# |\
# | * f5e134d (origin/master, origin/HEAD, master) Subproject v2
# * | 0a1cd07 Add my feature to the subproject
# |/
# * c2d32ba Subproject v1
) &&
printf 'master: ' &&
git ls-tree master submod &&
# master: 160000 commit f5e134d5747ee4a206e96d8c017f92f5b29a07f3 submod
printf 'my-feature: ' &&
git ls-tree my-feature submod
# my-feature: 160000 commit 16d9e3ea2fb57e7a166587203abdb328f90895d1 submod
)
git --version
# git version 1.8.5.2.237.g01c62c6
I think the first three patches are fairly solid. The last one gets
through the above script, but I'd need a more thorough test suite
before I trusted it. I tried to be detailed in the commit messages,
but of course, we'd want some user-facing documentation if we actually
merged something like this series. I'm sending it to the list mostly
to explain my current views and re-focus debate [1].
[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
[4]: http://article.gmane.org/gmane.comp.version-control.git/239246
[5]: http://thread.gmane.org/gmane.comp.version-control.git/239695
[6]: http://article.gmane.org/gmane.comp.version-control.git/240117
Cheers,
Trevor
W. Trevor King (4):
submodule: Add helpers for configurable local branches
submodule: Teach 'update' to preserve local branches
submodule: Teach 'add' about a configurable local-branch
submodule: Add a new 'checkout' command
git-submodule.sh | 152 ++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 138 insertions(+), 14 deletions(-)
--
1.8.5.2.237.g01c62c6
^ permalink raw reply [flat|nested] 144+ messages in thread
* [RFC v3 1/4] submodule: Add helpers for configurable local branches
2014-01-09 6:17 ` [RFC v3 0/4] " W. Trevor King
@ 2014-01-09 6:17 ` W. Trevor King
2014-01-09 6:17 ` [RFC v3 2/4] submodule: Teach 'update' to preserve " W. Trevor King
` (3 subsequent siblings)
4 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-09 6:17 UTC (permalink / raw)
To: Git
Cc: Francesco Pretto, Junio C Hamano, Heiko Voigt, Jens Lehmann,
Jonathan Nieder, W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
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 tracks a branch in
upstream submodule.<name>.url repository.
3. The submodule's locally checked out branch, which we currently let
the developer setup by hand, which is integrated with one of the
other two branches by non-checkout update modes.
Git is currently a bit weak on conveniently handling branch #3. "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.
This is easy to fix if you accept submodule.<name>.branch or the
branch pointed to by the cloned repository's HEAD as a guess, but
this conflates branch #2 and branch #3, which may confuse users.
* Workflows where the preferred #3 branch depends on the superproject
branch. For example, if the remote subproject has only a master
branch, but the local superproject needs to develop several
submodule feature branches simultaneously, you can have a situation
like this:
Superproject branch Submodule branch Subproject branch
=================== ================ =================
master master master
feature-1 feature-1 master
feature-2 feature-2 master
feature-3 feature-2 master
In order to checkout the appropriate submodule branch for a given
superproject branch, we need a way to specify the preferred submodule
branch for a given superproject branch. This commit adds two helper
functions:
* get_current_branch, to determine which superproject branch you're
on, and
* get_local_branch, to determine the preferred submodule branch for
that superproject branch.
The lookup chain for the local-branch is:
1. superproject.<superproject-branch>.local-branch in the submodule's
config (superproject/.git/modules/<submodule-name>/config). This
is where the developer can store local per-superproject-branch
overrides (e.g. if they wanted to use submodule branch feature-1
with superproject branch feature-3).
2. submodule.<submodule-name>.local-branch in the superproject's
config. This is where the developer can store local
cross-superproject-branch overrides (e.g. if they wanted to use
submodule branch master for any superproject branch that didn't
have a per-superproject-branch override).
3. submodule.<submodule-name>.local-branch in the superproject's
.gitmodules file. Because the gitmodules file is stored in the
superproject's versioned tree, it is automatically
superproject-branch-specific. For example:
$ git cat-file -p feature-1:.gitmodules
...
[submodule "submod"]
...
local-branch = feature-1
$ git cat-file -p feature-3:.gitmodules
...
[submodule "submod"]
...
local-branch = feature-2
this is where the project-wide defaults are setup and shared
between developers.
4. The default local-branch is 'master'.
The new get_local_branch function handles the first step in this
chain. The next two steps are already covered by the existing
get_submodule_config.
---
git-submodule.sh | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/git-submodule.sh b/git-submodule.sh
index 2677f2e..56fc3f1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -220,6 +220,39 @@ get_submodule_config () {
printf '%s' "${value:-$default}"
}
+#
+# Print a submodule's configured local branch name
+#
+# $1 = superproject branch
+# $2 = default (from the superproject's .gitmodules)
+#
+# To be called from the submodule root directory.
+#
+get_local_branch ()
+{
+ superproject_branch="$1"
+ default="${2:-master}"
+ if test -z "${superproject_branch}"
+ then
+ value=""
+ else
+ value=$(git config superproject."$superproject_branch".local-branch)
+ fi
+ printf '%s' "${value:-$default}"
+}
+
+#
+# Print the currently checked out branch of the current repository
+#
+# $1 = default
+#
+get_current_branch ()
+{
+ default="$1"
+ branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null) ||
+ branch=""
+ printf '%s' "${branch:-$default}"
+}
#
# Map submodule path to submodule name
--
1.8.5.2.237.g01c62c6
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [RFC v3 2/4] submodule: Teach 'update' to preserve local branches
2014-01-09 6:17 ` [RFC v3 0/4] " W. Trevor King
2014-01-09 6:17 ` [RFC v3 1/4] submodule: Add helpers for configurable local branches W. Trevor King
@ 2014-01-09 6:17 ` W. Trevor King
2014-01-09 6:17 ` [RFC v3 3/4] submodule: Teach 'add' about a configurable local-branch W. Trevor King
` (2 subsequent siblings)
4 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-09 6:17 UTC (permalink / raw)
To: Git
Cc: Francesco Pretto, Junio C Hamano, Heiko Voigt, Jens Lehmann,
Jonathan Nieder, W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
There's no sense in setting up a local branch if we're just going to
go back to a detached HEAD with every checkout-mode update. This
commit replaces the checkout with a reset, updating whatever the
locally checked out branch (or detached HEAD) happens to be. While it
is tempting to checkout a new local-branch here (as we did after the
clone), it's more consistent to follow the lead of the other update
modes and just use the currently checked out branch.
---
git-submodule.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 56fc3f1..c5ea7bd 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -930,9 +930,9 @@ Maybe you want to use 'update --init'?")"
must_die_on_failure=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'")"
+ command="git reset --hard -q"
+ die_msg="$(eval_gettext "Unable to reset branch to '\$sha1' in submodule path '\$displaypath'")"
+ say_msg="$(eval_gettext "Submodule path '\$displaypath': reset branch to '\$sha1'")"
;;
esac
--
1.8.5.2.237.g01c62c6
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [RFC v3 3/4] submodule: Teach 'add' about a configurable local-branch
2014-01-09 6:17 ` [RFC v3 0/4] " W. Trevor King
2014-01-09 6:17 ` [RFC v3 1/4] submodule: Add helpers for configurable local branches W. Trevor King
2014-01-09 6:17 ` [RFC v3 2/4] submodule: Teach 'update' to preserve " W. Trevor King
@ 2014-01-09 6:17 ` W. Trevor King
2014-01-15 0:18 ` Francesco Pretto
2014-01-09 6:17 ` [RFC v3 4/4] submodule: Add a new 'checkout' command W. Trevor King
2014-01-12 1:08 ` Tight submodule bindings (was: Preferred local submodule branches) W. Trevor King
4 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-09 6:17 UTC (permalink / raw)
To: Git
Cc: Francesco Pretto, Junio C Hamano, Heiko Voigt, Jens Lehmann,
Jonathan Nieder, W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
This patch teaches 'git submodule add' to look for a preferred
local-branch, and to checkout that branch after the initial clone.
The local branch will always point at the commit checked out by the
internal 'git clone' operation. For example:
$ git submodule add git://example.com/subproject.git submod
will checkout the branch pointed to by the cloned repository's HEAD,
and call the local branch 'master'.
$ git submodule add -b my-feature git://example.com/subproject.git submod
will checkout the branch pointed to by the cloned repository's
my-feature, and *still* call the local branch 'master'.
'git submodule add' does not always make an initial clone (e.g. if a
git repository already exists at the target path). In cases where
'git submodule add' does not clone a repository, we just leave the
local branch alone.
This commit also shifts the post-clone branch checkout logic from
cmd_add to module_clone, so it can be shared with cmd_update. The
previous code only checked out the requested branch in cmd_add but not
in cmd_update; this left the user on a detached HEAD after an update
initially cloned, and subsequent updates kept the HEAD detached,
unless the user moved to the desired branch himself. Now, unless the
user explicitly asks to work on a detached HEAD, subsequent updates
all happen on the specified branch, which matches the end-user
expectation much better.
---
git-submodule.sh | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index c5ea7bd..7cee0bf 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -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'")"
}
isnumber()
@@ -503,15 +515,6 @@ Use -f if you really want to add it." >&2
fi
fi
module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" || exit
- (
- clear_local_git_env
- cd "$sm_path" &&
- # ash fails to wordsplit ${branch:+-b "$branch"...}
- case "$branch" in
- '') git checkout -f -q ;;
- ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
- esac
- ) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
fi
git config submodule."$sm_name".url "$realrepo"
--
1.8.5.2.237.g01c62c6
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [RFC v3 4/4] submodule: Add a new 'checkout' command
2014-01-09 6:17 ` [RFC v3 0/4] " W. Trevor King
` (2 preceding siblings ...)
2014-01-09 6:17 ` [RFC v3 3/4] submodule: Teach 'add' about a configurable local-branch W. Trevor King
@ 2014-01-09 6:17 ` W. Trevor King
2014-01-12 1:08 ` Tight submodule bindings (was: Preferred local submodule branches) W. Trevor King
4 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-09 6:17 UTC (permalink / raw)
To: Git
Cc: Francesco Pretto, Junio C Hamano, Heiko Voigt, Jens Lehmann,
Jonathan Nieder, W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
This borrows a good deal of the cmd_foreach logic to iterate through
submodules (potentially recursively), checking out the preferred local
branch for each submodule (as appropriate for the current superproject
branch). Ideally, this logic would be bundled into the forthcoming:
$ git checkout --recurse-submodules
logic that Jens Lehmann and Jonathan Nieder are working up in C.
Until that happens, you can simulate that checkout behaviour with:
$ git checkout some-branch
$ git submodule checkout --recursive
The relevant superproject branch used to determine the preferred
submodule branch is the submodules immediate parent, not the top-level
superproject. For example, with the following submodule inheritance:
superproject (branch super-1)
`-- midproject (branch mid-1)
`-- subproject (branch sub-1)
The .gitmodules configs should look like (assuming there are no local
overrides):
$ git cat-file -p super-1:.gitmodules
...
[submodule "midproject"]
...
local-branch = mid-1
$ cd midproject
$ git cat-file -p mid-1:.gitmodules
...
[submodule "subproject"]
...
local-branch = sub-1
The super-1 branch need not even exist in the midproject repository.
This commit handles branch switches inside existing submodules.
Handling (or even detecting) submodules that are created and destroyed
or moving submodules that change path between the initial and final
superproject branch is put off to future patches.
I also added minimal support for initial branch creation. Create your
initial branch with:
$ git checkout -b my-feature
$ git submodule checkout --recursive -b --gitmodules
which will create new 'my-feature' branches in each submodule (or die
trying). It will also save 'my-feature' to the superproject's
.gitmodules' submodule.<name>.local-branch for future checkouts.
After setting up a branch like this, future checkouts (from some other
branch) will look like:
$ git checkout my-feature
$ git submodule checkout --recursive
---
git-submodule.sh | 90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 89 insertions(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 7cee0bf..16cebb1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -6,6 +6,7 @@
dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="[--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
+ or: $dashless [--quiet] checkout [--recursive] [-b|-B] [--gitmodules] [--] [<path>...]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
or: $dashless [--quiet] deinit [-f|--force] [--] <path>...
@@ -36,6 +37,10 @@ update=
prefix=
custom_name=
depth=
+create_new_branch=
+checkout_options=
+save_in_gitmodules=
+default_local_branch="master"
# The function takes at most 2 arguments. The first argument is the
# URL that navigates to the submodule origin repo. When relative, this URL
@@ -532,6 +537,89 @@ Use -f if you really want to add it." >&2
}
#
+# Checkout the appropriate local branch for each submodule
+#
+cmd_checkout()
+{
+ # parse $args after "submodule ... checkout".
+ while test $# -ne 0
+ do
+ case "$1" in
+ -q|--quiet)
+ GIT_QUIET=1
+ ;;
+ --recursive)
+ recursive=1
+ ;;
+ -b|-B)
+ checkout_options="${checkout_options} $1"
+ create_new_branch=1
+ ;;
+ --gitmodules)
+ save_in_gitmodules=1
+ ;;
+ --)
+ shift
+ break
+ ;;
+ -*)
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+ done
+
+ toplevel=$(pwd)
+
+ superproject_branch=$(get_current_branch)
+ if test -n "$create_new_branch"
+ then
+ default_local_branch="${superproject_branch}"
+ fi
+
+ # dup stdin so that it can be restored when running the external
+ # command in the subshell (and a recursive call to this function)
+ exec 3<&0
+
+ module_list "$@" |
+ while read mode sha1 stage sm_path
+ do
+ die_if_unmatched "$mode"
+ name=$(module_name "$sm_path") || exit
+ displaypath=$(relative_path "$prefix$sm_path")
+ if test -e "$sm_path"/.git
+ then
+ say "$(eval_gettext "Entering '\$displaypath'")"
+ name=$(module_name "$sm_path")
+ super_local_branch=$(get_submodule_config "$name" local-branch "${default_local_branch}")
+ (
+ prefix="$prefix$sm_path/"
+ clear_local_git_env
+ cd "$sm_path" &&
+ local_branch=$(get_local_branch "${superproject_branch}" "${super_local_branch}") &&
+ git checkout ${checkout_options} "${local_branch}" &&
+ if test -n "$recursive"
+ then
+ cmd_checkout
+ fi
+ ) <&3 3<&- ||
+ die "$(eval_gettext "Stopping at '\$displaypath'; script returned non-zero status.")"
+ if test -n "${save_in_gitmodules}"
+ then
+ (
+ local_branch=$(clear_local_git_env && cd "$sm_path" && get_current_branch) &&
+ git config -f .gitmodules submodule."${name}".local-branch "${local_branch}"
+ ) ||
+ die "$(eval_gettext "Could not save local-branch for '\$displaypath'")"
+ fi
+ fi
+ done
+}
+
+#
# Execute an arbitrary command sequence in each checked out
# submodule
#
@@ -1378,7 +1466,7 @@ cmd_sync()
while test $# != 0 && test -z "$command"
do
case "$1" in
- add | foreach | init | deinit | update | status | summary | sync)
+ add | checkout | foreach | init | deinit | update | status | summary | sync)
command=$1
;;
-q|--quiet)
--
1.8.5.2.237.g01c62c6
^ permalink raw reply related [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-09 1:09 ` Francesco Pretto
2014-01-09 2:22 ` W. Trevor King
@ 2014-01-09 8:31 ` Jens Lehmann
2014-01-09 17:32 ` W. Trevor King
1 sibling, 1 reply; 144+ messages in thread
From: Jens Lehmann @ 2014-01-09 8:31 UTC (permalink / raw)
To: Francesco Pretto, W. Trevor King
Cc: Heiko Voigt, Junio C Hamano, Git, Jonathan Nieder
Am 09.01.2014 02:09, schrieb Francesco Pretto:
> 2014/1/9 W. Trevor King <wking@tremily.us>:
>>
>> However, submodule.<name>.local-branch has nothing to do with remote
>> repositories or tracking branches.
>
> My bad: this means the feature is still not entirely clear to me.
>
>>
>> [branch "my-feature"]
>> remote = origin
>> merge = refs/heads/my-feature
>> [submodule "submod"]
>> local-branch = "my-feature"
>>
>> and I don't think Git's config supports such nesting.
>>
>
> Aesthetically, It doesn't look very nice.
And I'm not sure we even need that. What's wrong with having the
branch setting in the .gitmodules file of the my-feature branch?
The only problem I can imagine is accidentally merging that into
a branch where that isn't set, but that could be solved by a merge
helper for the .gitmodules file.
>> I can resuscitate that if folks want, but Heiko felt that my initial
>> consolidation didn't go far enough [2]. If it turns out that we're ok
>> with the current level of consolidation, would you be ok with
>> "non-checkout submodule.<name>.update" as the trigger [3]?
>
> For me it was ok with what you did:
> -------------------------------------------------
> if "just_cloned" and "config_branch"
> then
> !git reset --hard -q"
> fi
> -------------------------------------------------
>
> So yes: at the first clone 'checkout' keeps attached HEAD, while
> 'merge' and 'rebase' attach to the branch.
It have the impression that attaching the head to the given branch
for merge and rebase might be the sensible thing to do, but it
would be great to hear from users of merge and rebase if that
would break anything for them in their current use cases for these
settings.
> If it's not the first clone, you should take no action (and your
> original patch was ok about this).
I'm not sure this is the right thing to do, after all you
configured git to follow that branch so I'd expect it to be
updated later too, no? Otherwise you might end up with an old
version of your branch while upstream is a zillion commits
ahead.
>> I think
>> that adding a halfway step between the current status and full(ish)
>> submodule.<name>.local-branch support is just going to confuse people
>
> Well, for now you got some success in confusing me with this "local-branch" :)
>
> At certain point you may ask maintainers what are the accepted
> features (because all these debates should be about getting, or not
> getting, endorsement about something) and finalize a patch so people
> can further review.
First I'd like to see a real consensus about what exactly should
happen when a branch is configured to be checked out (and if I
missed such a summary in this thread, please point me to it ;-).
And we should contrast that to the exact checkout and floating
branch use cases.
So what should happen on initial clone, later updates, updates
where the local and the remote branch diverged, when superproject
branches are merged (with and without conflicts), on a rebase in
the superproject and so on.
After that we can discuss about how to implement them (even though I
believe we won't need a new submodule command at the end of this
process, simply because if it isn't configurable we cannot teach git
checkout and friends to do that automatically for us later).
And from reading this discussion I believe we need another value for
the ignore option which only ignores changes to the SHA-1 but not to
work tree modifications of a submodule work tree relative to its HEAD
(or make that two: another one which ignores untracked files too and
only shows modification of tracked files). Otherwise users of the
floating or attached model can easily miss submodule modifications.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-09 8:31 ` Jens Lehmann
@ 2014-01-09 17:32 ` W. Trevor King
2014-01-09 19:23 ` Jens Lehmann
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-09 17:32 UTC (permalink / raw)
To: Jens Lehmann
Cc: Francesco Pretto, Heiko Voigt, Junio C Hamano, Git, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 8016 bytes --]
On Thu, Jan 09, 2014 at 09:31:13AM +0100, Jens Lehmann wrote:
> Am 09.01.2014 02:09, schrieb Francesco Pretto:
> > 2014/1/9 W. Trevor King <wking@tremily.us>:
> >>
> >> However, submodule.<name>.local-branch has nothing to do with remote
> >> repositories or tracking branches.
> >
> > My bad: this means the feature is still not entirely clear to me.
> >
> >>
> >> [branch "my-feature"]
> >> remote = origin
> >> merge = refs/heads/my-feature
> >> [submodule "submod"]
> >> local-branch = "my-feature"
> >>
> >> and I don't think Git's config supports such nesting.
> >>
> >
> > Aesthetically, It doesn't look very nice.
>
> And I'm not sure we even need that. What's wrong with having the
> branch setting in the .gitmodules file of the my-feature branch?
> The only problem I can imagine is accidentally merging that into
> a branch where that isn't set, but that could be solved by a merge
> helper for the .gitmodules file.
.gitmodules is fine so long as the config can live in the versioned
tree. Many (all?) .gitmodules settings can be overridden in
.git/config. However, the local-branch setting needs to be both
per-submodule and per-superproject-branch, so .git/config doesn't work
very well. I think it's better to use something like my
.git/modules/<submodule-name>/config implementation [1] to set this
override.
This lack of per-superproject-branch overrides applies to all of the
submodule.<name>.* settings, but you're unlikely to want an
out-of-tree override for 'path' or a per-superproject-branch override
for 'url', 'ignore', 'update', or 'chRecurseSubmodules'. Maybe folks
would want per-superproject-branch overrides to 'branch', although I'd
prefer we reuse branch.<name>.merge in the submodule's config for
that [2].
On the other hand, maybe an in-tree .gitmodules is good enough, and
folks who want a local override can just edit .gitmodules in their
local branch? I've never felt the need to override .gitmodules myself
(for any setting), so feedback from someone who has would be useful.
> >> I can resuscitate that if folks want, but Heiko felt that my initial
> >> consolidation didn't go far enough [2]. If it turns out that we're ok
> >> with the current level of consolidation, would you be ok with
> >> "non-checkout submodule.<name>.update" as the trigger [3]?
> >
> > For me it was ok with what you did:
> > -------------------------------------------------
> > if "just_cloned" and "config_branch"
> > then
> > !git reset --hard -q"
> > fi
> > -------------------------------------------------
> >
> > So yes: at the first clone 'checkout' keeps attached HEAD, while
> > 'merge' and 'rebase' attach to the branch.
>
> It have the impression that attaching the head to the given branch
> for merge and rebase might be the sensible thing to do, but it
> would be great to hear from users of merge and rebase if that
> would break anything for them in their current use cases for these
> settings.
Which local branch would you attach to before merging? I think 'git
submodule update' should always use the current submodule state
(attached branch or detached HEAD) [3], and we should have a separate
call that explicitly checked out the desired submodule branch [4].
> > If it's not the first clone, you should take no action (and your
> > original patch was ok about this).
>
> I'm not sure this is the right thing to do, after all you
> configured git to follow that branch so I'd expect it to be
> updated later too, no? Otherwise you might end up with an old
> version of your branch while upstream is a zillion commits
> ahead.
Non-clone updates should not change the submodule's *local* branch
*name*. They should change the commit that that branch references,
otherwise 'git submodule update' would be a no-op ;).
> First I'd like to see a real consensus about what exactly should
> happen when a branch is configured to be checked out (and if I
> missed such a summary in this thread, please point me to it ;-).
I don't think we have a consensus yet. A stand-alone outline of my
current position is in my v3 RFC [5], but I don't have any buy-in yet
;).
> And we should contrast that to the exact checkout and floating
> branch use cases.
With my v3 series, there are no more detached HEADs. Folks using
checkout updates get a local master branch. I do not change any of
the exact checkout (superproject gitlinked sha1) vs. floating
(subproject's remote submodule.<name>.branch via 'update --remote')
logic, because that already works well. The problem is the local
branch handling, not the update/integration logic.
> So what should happen on initial clone,
For 'add', clone the command line URL and create a new branch 'master'
pointing at the commit referenced by the remote's HEAD (or other
branch with --branch).
For 'update', do the same, except use a local-branch setting to
determine the name for the local branch, falling back to 'master' if
it is not set.
> later updates,
The same thing that currently happens, with the exception that
checkout-style updates should use reset to update the
currently-checked out branch (or detached-HEAD), instead of always
detaching the HEAD.
> updates where the local and the remote branch diverged,
The same thing that currently happens. For local (non --remote)
updates, the integrated branch is the superproject's gitlinked sha1.
For --remote updates, the integrated branch is the remote subproject's
submodule.<name>.branch. We integrate that with the
currently-checked-out local branch (or detached HEAD) using the user's
preferred submodule.<name>.update strategy.
> 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.
> on a rebase in the superproject and so on.
Same as the merge case. Why would configuring a preferred
local-branch that only affects checkout (and the initial clone) have
anything to do with rebases and merges?
> After that we can discuss about how to implement them (even though I
> believe we won't need a new submodule command at the end of this
> process, simply because if it isn't configurable we cannot teach git
> checkout and friends to do that automatically for us later).
I think it is configurable, and I have an implementation that works
(modulo bugs) [5]. I think we should teach 'git checkout
--recurse-submodules' this logic, and then we can drop my 'git
submodule checkout' entirely.
> And from reading this discussion I believe we need another value for
> the ignore option which only ignores changes to the SHA-1 but not to
> work tree modifications of a submodule work tree relative to its HEAD
> (or make that two: another one which ignores untracked files too and
> only shows modification of tracked files). Otherwise users of the
> floating or attached model can easily miss submodule modifications.
I am ignore-agnostic ;). Do whatever you like here.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/240251
[2]: http://article.gmane.org/gmane.comp.version-control.git/240164
[3]: http://article.gmane.org/gmane.comp.version-control.git/240250
[4]: http://article.gmane.org/gmane.comp.version-control.git/240249
[5]: http://article.gmane.org/gmane.comp.version-control.git/240248
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-09 17:32 ` W. Trevor King
@ 2014-01-09 19:23 ` Jens Lehmann
2014-01-09 19:55 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Jens Lehmann @ 2014-01-09 19:23 UTC (permalink / raw)
To: W. Trevor King
Cc: Francesco Pretto, Heiko Voigt, Junio C Hamano, Git, Jonathan Nieder
Am 09.01.2014 18:32, schrieb W. Trevor King:
> On Thu, Jan 09, 2014 at 09:31:13AM +0100, Jens Lehmann wrote:
>> Am 09.01.2014 02:09, schrieb Francesco Pretto:
>>> 2014/1/9 W. Trevor King <wking@tremily.us>:
>>>>
>>>> However, submodule.<name>.local-branch has nothing to do with remote
>>>> repositories or tracking branches.
>>>
>>> My bad: this means the feature is still not entirely clear to me.
>>>
>>>>
>>>> [branch "my-feature"]
>>>> remote = origin
>>>> merge = refs/heads/my-feature
>>>> [submodule "submod"]
>>>> local-branch = "my-feature"
>>>>
>>>> and I don't think Git's config supports such nesting.
>>>>
>>>
>>> Aesthetically, It doesn't look very nice.
>>
>> And I'm not sure we even need that. What's wrong with having the
>> branch setting in the .gitmodules file of the my-feature branch?
>> The only problem I can imagine is accidentally merging that into
>> a branch where that isn't set, but that could be solved by a merge
>> helper for the .gitmodules file.
>
> .gitmodules is fine so long as the config can live in the versioned
> tree. Many (all?) .gitmodules settings can be overridden in
> .git/config.
With the exception of path, as that would make no sense at all.
> However, the local-branch setting needs to be both
> per-submodule and per-superproject-branch, so .git/config doesn't work
> very well. I think it's better to use something like my
> .git/modules/<submodule-name>/config implementation [1] to set this
> override.
Yes, the local branch should be set in the submodule's .git/config
to make operations done inside the submodule work seamlessly.
> This lack of per-superproject-branch overrides applies to all of the
> submodule.<name>.* settings, but you're unlikely to want an
> out-of-tree override for 'path' or a per-superproject-branch override
> for 'url', 'ignore', 'update', or 'chRecurseSubmodules'.
Unlikely it is not ;-) We do have people who set update=none in
the .git/config of the superproject for submodules they don't have
access to (and which is not necessary for their work). And it isn't
a "per-superproject-branch override" but a "per-superproject-branch
default" which can be overridden in .git/config (except for 'update',
but I intend to fix that).
> Maybe folks
> would want per-superproject-branch overrides to 'branch', although I'd
> prefer we reuse branch.<name>.merge in the submodule's config for
> that [2].
But that might still have to be synced with what the superproject
wants. Maybe manually, maybe automatically on checkout. Dunno yet.
> On the other hand, maybe an in-tree .gitmodules is good enough, and
> folks who want a local override can just edit .gitmodules in their
> local branch? I've never felt the need to override .gitmodules myself
> (for any setting), so feedback from someone who has would be useful.
That way these changes would propagate to others working on the same
branch when pushing, which I believe is a feature.
>>>> I can resuscitate that if folks want, but Heiko felt that my initial
>>>> consolidation didn't go far enough [2]. If it turns out that we're ok
>>>> with the current level of consolidation, would you be ok with
>>>> "non-checkout submodule.<name>.update" as the trigger [3]?
>>>
>>> For me it was ok with what you did:
>>> -------------------------------------------------
>>> if "just_cloned" and "config_branch"
>>> then
>>> !git reset --hard -q"
>>> fi
>>> -------------------------------------------------
>>>
>>> So yes: at the first clone 'checkout' keeps attached HEAD, while
>>> 'merge' and 'rebase' attach to the branch.
>>
>> It have the impression that attaching the head to the given branch
>> for merge and rebase might be the sensible thing to do, but it
>> would be great to hear from users of merge and rebase if that
>> would break anything for them in their current use cases for these
>> settings.
>
> Which local branch would you attach to before merging? I think 'git
> submodule update' should always use the current submodule state
> (attached branch or detached HEAD) [3], and we should have a separate
> call that explicitly checked out the desired submodule branch [4].
Like we currently do with "git submodule update --remote" (where you
have to have an explicit command telling git when to advance the
branch)? Having a separate call that does something *after* a git
command is exactly the problem I'm trying to fix with recursive
update, so I'm not terribly excited ;-)
>>> If it's not the first clone, you should take no action (and your
>>> original patch was ok about this).
>>
>> I'm not sure this is the right thing to do, after all you
>> configured git to follow that branch so I'd expect it to be
>> updated later too, no? Otherwise you might end up with an old
>> version of your branch while upstream is a zillion commits
>> ahead.
>
> Non-clone updates should not change the submodule's *local* branch
> *name*. They should change the commit that that branch references,
> otherwise 'git submodule update' would be a no-op ;).
Okay, I seem to have misunderstood that. But what happens when the
branch setting in .gitmodules changes, shouldn't that be updated?
>> First I'd like to see a real consensus about what exactly should
>> happen when a branch is configured to be checked out (and if I
>> missed such a summary in this thread, please point me to it ;-).
>
> I don't think we have a consensus yet. A stand-alone outline of my
> current position is in my v3 RFC [5], but I don't have any buy-in yet
> ;).
I'll volunteer to prepare a table explaining the different modes
in my github wiki. Will scan this thread and your pointers for input
and will come back soon when I have something ready.
>> And we should contrast that to the exact checkout and floating
>> branch use cases.
>
> With my v3 series, there are no more detached HEADs. Folks using
> checkout updates get a local master branch. I do not change any of
> the exact checkout (superproject gitlinked sha1) vs. floating
> (subproject's remote submodule.<name>.branch via 'update --remote')
> logic, because that already works well. The problem is the local
> branch handling, not the update/integration logic.
Ok. Maybe we could use the "<remote>:<local>" notation to store both
remote and local branch in a single setting?
>> So what should happen on initial clone,
>
> For 'add', clone the command line URL and create a new branch 'master'
> pointing at the commit referenced by the remote's HEAD (or other
> branch with --branch).
>
> For 'update', do the same, except use a local-branch setting to
> determine the name for the local branch, falling back to 'master' if
> it is not set.
Good.
>> later updates,
>
> The same thing that currently happens, with the exception that
> checkout-style updates should use reset to update the
> currently-checked out branch (or detached-HEAD), instead of always
> detaching the HEAD.
Won't the user loose any modifications to his local branch here?
>> updates where the local and the remote branch diverged,
>
> The same thing that currently happens. For local (non --remote)
> updates, the integrated branch is the superproject's gitlinked sha1.
> For --remote updates, the integrated branch is the remote subproject's
> submodule.<name>.branch. We integrate that with the
> currently-checked-out local branch (or detached HEAD) using the user's
> preferred submodule.<name>.update strategy.
And for checkout I can easily overwrite the upstream branch with
my local changes?
>> 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").
>> on a rebase in the superproject and so on.
>
> Same as the merge case. Why would configuring a preferred
> local-branch that only affects checkout (and the initial clone) have
> anything to do with rebases and merges?
Because teaching --recurse-submodules to checkout is only one part,
in the full recursive update series every work tree manipulating
command (like rebase and merge) will update submodules. So it is
not only affecting checkout, but a lot of other commands too.
>> After that we can discuss about how to implement them (even though I
>> believe we won't need a new submodule command at the end of this
>> process, simply because if it isn't configurable we cannot teach git
>> checkout and friends to do that automatically for us later).
>
> I think it is configurable, and I have an implementation that works
> (modulo bugs) [5]. I think we should teach 'git checkout
> --recurse-submodules' this logic, and then we can drop my 'git
> submodule checkout' entirely.
Okay, I have no problem with a proof of concept implementation to
play around with.
>> And from reading this discussion I believe we need another value for
>> the ignore option which only ignores changes to the SHA-1 but not to
>> work tree modifications of a submodule work tree relative to its HEAD
>> (or make that two: another one which ignores untracked files too and
>> only shows modification of tracked files). Otherwise users of the
>> floating or attached model can easily miss submodule modifications.
>
> I am ignore-agnostic ;). Do whatever you like here.
I was hoping someone else would jump in to do that, as I'm rather
busy with the recursive checkout topic ;-)
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-09 19:23 ` Jens Lehmann
@ 2014-01-09 19:55 ` W. Trevor King
2014-01-09 21:40 ` Jens Lehmann
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-09 19:55 UTC (permalink / raw)
To: Jens Lehmann
Cc: Francesco Pretto, Heiko Voigt, Junio C Hamano, Git, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 9386 bytes --]
On Thu, Jan 09, 2014 at 08:23:07PM +0100, Jens Lehmann wrote:
> Am 09.01.2014 18:32, schrieb W. Trevor King:
> > However, the local-branch setting needs to be both
> > per-submodule and per-superproject-branch, so .git/config doesn't work
> > very well. I think it's better to use something like my
> > .git/modules/<submodule-name>/config implementation [1] to set this
> > override.
>
> Yes, the local branch should be set in the submodule's .git/config
> to make operations done inside the submodule work seamlessly.
Once you're inside the submodule my local-branch setting shouldn't
matter, because it just connects superproject branches with submodule
branches. The submodule's config is just a convenient out-of-tree
place to store per-submodule overrides.
> > This lack of per-superproject-branch overrides applies to all of the
> > submodule.<name>.* settings, but you're unlikely to want an
> > out-of-tree override for 'path' or a per-superproject-branch override
> > for 'url', 'ignore', 'update', or 'chRecurseSubmodules'.
>
> Unlikely it is not ;-) We do have people who set update=none in
> the .git/config of the superproject for submodules they don't have
> access to (and which is not necessary for their work).
That is not a per-superproject-branch override. local-branch is the
only per-submodule config I can think of where I can imagine a sane
person actually wanting an out-of-tree per-superproject-branch
override.
> And it isn't a "per-superproject-branch override" but a
> "per-superproject-branch default" which can be overridden in
> .git/config (except for 'update', but I intend to fix that).
You're talking about .gitmodules vs. .git/config here, but for
local-branch, I'm talking about a fallback chain like [1]:
1. superproject.<superproject-branch>.local-branch in the submodule's
config (superproject/.git/modules/≤submodule-name>/config).
2. submodule.<submodule-name>.local-branch in the superproject's
config (.git/config).
3. submodule.<submodule-name>.local-branch in the superproject's
.gitmodules file.
4. default to 'master'
Only #1 is a new idea.
> > On the other hand, maybe an in-tree .gitmodules is good enough,
> > and folks who want a local override can just edit .gitmodules in
> > their local branch? I've never felt the need to override
> > .gitmodules myself (for any setting), so feedback from someone who
> > has would be useful.
>
> That way these changes would propagate to others working on the same
> branch when pushing, which I believe is a feature.
Sure. Unless they don't want to propagate them, at which point they
use an out-of-tree override masking the .gitmodules value. The
question is, would folks want local overrides for local-branch (like
they do for submodule.<name>.update), or not? Since it's easy to do
[1], I don't see the point of *not* supporting per-superproject-branch
overrides.
> >> It have the impression that attaching the head to the given
> >> branch for merge and rebase might be the sensible thing to do,
> >> but it would be great to hear from users of merge and rebase if
> >> that would break anything for them in their current use cases for
> >> these settings.
> >
> > Which local branch would you attach to before merging? I think
> > 'git submodule update' should always use the current submodule
> > state (attached branch or detached HEAD) [3], and we should have a
> > separate call that explicitly checked out the desired submodule
> > branch [4].
>
> Like we currently do with "git submodule update --remote" (where you
> have to have an explicit command telling git when to advance the
> branch)? Having a separate call that does something *after* a git
> command is exactly the problem I'm trying to fix with recursive
> update, so I'm not terribly excited ;-)
I'm all for rolling my 'git submodule checkout' into 'git checkout
--recurse-submodules' [2]. It was just faster to mock up in shell
while we decide how it should work.
> >>> If it's not the first clone, you should take no action (and your
> >>> original patch was ok about this).
> >>
> >> I'm not sure this is the right thing to do, after all you
> >> configured git to follow that branch so I'd expect it to be
> >> updated later too, no? Otherwise you might end up with an old
> >> version of your branch while upstream is a zillion commits
> >> ahead.
> >
> > Non-clone updates should not change the submodule's *local* branch
> > *name*. They should change the commit that that branch references,
> > otherwise 'git submodule update' would be a no-op ;).
>
> Okay, I seem to have misunderstood that. But what happens when the
> branch setting in .gitmodules changes, shouldn't that be updated?
Not by 'git submodule update'. If there are no out-of-tree overrides
and the user calls 'git submodule checkout' with a new local-branch in
.gitmodules, *that* should checkout a new submodule branch.
> >> First I'd like to see a real consensus about what exactly should
> >> happen when a branch is configured to be checked out (and if I
> >> missed such a summary in this thread, please point me to it ;-).
> >
> > I don't think we have a consensus yet. A stand-alone outline of my
> > current position is in my v3 RFC [5], but I don't have any buy-in yet
> > ;).
>
> I'll volunteer to prepare a table explaining the different modes
> in my github wiki. Will scan this thread and your pointers for input
> and will come back soon when I have something ready.
Thanks :).
> >> And we should contrast that to the exact checkout and floating
> >> branch use cases.
> >
> > With my v3 series, there are no more detached HEADs. Folks using
> > checkout updates get a local master branch. I do not change any of
> > the exact checkout (superproject gitlinked sha1) vs. floating
> > (subproject's remote submodule.<name>.branch via 'update --remote')
> > logic, because that already works well. The problem is the local
> > branch handling, not the update/integration logic.
>
> Ok. Maybe we could use the "<remote>:<local>" notation to store both
> remote and local branch in a single setting?
Meh :p. I'm fine with (remote-)branch and local-branch as separate
settings, or a single combined '<remote>:<local>' setting. However, I
think the local branch name is going to be more closely associated
with the superproject branch than with the subproject's remote branch,
and expect folks to want to override the local-branch on a
per-superproject-branch basis much more often then they'll override
the latter.
> >> later updates,
> >
> > The same thing that currently happens, with the exception that
> > checkout-style updates should use reset to update the
> > currently-checked out branch (or detached-HEAD), instead of always
> > detaching the HEAD.
>
> Won't the user loose any modifications to his local branch here?
They just called for a checkout-style update, so yes. If they want to
keep local modifications, chose an integration mode that preserves
local changes.
> >> updates where the local and the remote branch diverged,
> >
> > The same thing that currently happens. For local (non --remote)
> > updates, the integrated branch is the superproject's gitlinked sha1.
> > For --remote updates, the integrated branch is the remote subproject's
> > submodule.<name>.branch. We integrate that with the
> > currently-checked-out local branch (or detached HEAD) using the user's
> > preferred submodule.<name>.update strategy.
>
> And for checkout I can easily overwrite the upstream branch with
> my local changes?
? I don't understand. How would you overwrite something in the
upstream repository? Maybe you meant "for checkout I can easily
overwrite the local changes with the upstream branch", which is what I
understand checkout to do.
> >> 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.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/240251
[2]: http://article.gmane.org/gmane.comp.version-control.git/240249
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-09 19:55 ` W. Trevor King
@ 2014-01-09 21:40 ` Jens Lehmann
2014-01-09 22:18 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Jens Lehmann @ 2014-01-09 21:40 UTC (permalink / raw)
To: W. Trevor King
Cc: Francesco Pretto, Heiko Voigt, Junio C Hamano, Git, Jonathan Nieder
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:
>>> However, the local-branch setting needs to be both
>>> per-submodule and per-superproject-branch, so .git/config doesn't work
>>> very well. I think it's better to use something like my
>>> .git/modules/<submodule-name>/config implementation [1] to set this
>>> override.
>>
>> Yes, the local branch should be set in the submodule's .git/config
>> to make operations done inside the submodule work seamlessly.
>
> Once you're inside the submodule my local-branch setting shouldn't
> matter, because it just connects superproject branches with submodule
> branches. The submodule's config is just a convenient out-of-tree
> place to store per-submodule overrides.
Now I get it, you want to be able to override a submodule branch for
every superproject branch. I'm not sure I'd add that in the first
iteration though, as it seems to add quite some complexity and I'm
not convinced yet users really need it (but I won't object when we
find real world use cases for that).
>>> This lack of per-superproject-branch overrides applies to all of the
>>> submodule.<name>.* settings, but you're unlikely to want an
>>> out-of-tree override for 'path' or a per-superproject-branch override
>>> for 'url', 'ignore', 'update', or 'chRecurseSubmodules'.
>>
>> Unlikely it is not ;-) We do have people who set update=none in
>> the .git/config of the superproject for submodules they don't have
>> access to (and which is not necessary for their work).
>
> That is not a per-superproject-branch override. local-branch is the
> only per-submodule config I can think of where I can imagine a sane
> person actually wanting an out-of-tree per-superproject-branch
> override.
Oops, again I managed to miss the per-superproject*-branch* part.
>> And it isn't a "per-superproject-branch override" but a
>> "per-superproject-branch default" which can be overridden in
>> .git/config (except for 'update', but I intend to fix that).
>
> You're talking about .gitmodules vs. .git/config here, but for
> local-branch, I'm talking about a fallback chain like [1]:
>
> 1. superproject.<superproject-branch>.local-branch in the submodule's
> config (superproject/.git/modules/≤submodule-name>/config).
> 2. submodule.<submodule-name>.local-branch in the superproject's
> config (.git/config).
> 3. submodule.<submodule-name>.local-branch in the superproject's
> .gitmodules file.
> 4. default to 'master'
>
> Only #1 is a new idea.
Thanks for the explanation, now I understand what you're aiming at.
>>> On the other hand, maybe an in-tree .gitmodules is good enough,
>>> and folks who want a local override can just edit .gitmodules in
>>> their local branch? I've never felt the need to override
>>> .gitmodules myself (for any setting), so feedback from someone who
>>> has would be useful.
>>
>> That way these changes would propagate to others working on the same
>> branch when pushing, which I believe is a feature.
>
> Sure. Unless they don't want to propagate them, at which point they
> use an out-of-tree override masking the .gitmodules value. The
> question is, would folks want local overrides for local-branch (like
> they do for submodule.<name>.update), or not? Since it's easy to do
> [1], I don't see the point of *not* supporting per-superproject-branch
> overrides.
Unless actual use cases are shown I'd vote for YAGNI here. A new
config option means considerable maintenance burden, no matter how
easy it is to implement in the first place.
>>>> It have the impression that attaching the head to the given
>>>> branch for merge and rebase might be the sensible thing to do,
>>>> but it would be great to hear from users of merge and rebase if
>>>> that would break anything for them in their current use cases for
>>>> these settings.
>>>
>>> Which local branch would you attach to before merging? I think
>>> 'git submodule update' should always use the current submodule
>>> state (attached branch or detached HEAD) [3], and we should have a
>>> separate call that explicitly checked out the desired submodule
>>> branch [4].
>>
>> Like we currently do with "git submodule update --remote" (where you
>> have to have an explicit command telling git when to advance the
>> branch)? Having a separate call that does something *after* a git
>> command is exactly the problem I'm trying to fix with recursive
>> update, so I'm not terribly excited ;-)
>
> I'm all for rolling my 'git submodule checkout' into 'git checkout
> --recurse-submodules' [2]. It was just faster to mock up in shell
> while we decide how it should work.
Sure. As I said that's perfectly fine for testing this approach,
but we should do that right in "git checkout" and friends and not
add yet another submodule command.
>>>>> If it's not the first clone, you should take no action (and your
>>>>> original patch was ok about this).
>>>>
>>>> I'm not sure this is the right thing to do, after all you
>>>> configured git to follow that branch so I'd expect it to be
>>>> updated later too, no? Otherwise you might end up with an old
>>>> version of your branch while upstream is a zillion commits
>>>> ahead.
>>>
>>> Non-clone updates should not change the submodule's *local* branch
>>> *name*. They should change the commit that that branch references,
>>> otherwise 'git submodule update' would be a no-op ;).
>>
>> Okay, I seem to have misunderstood that. But what happens when the
>> branch setting in .gitmodules changes, shouldn't that be updated?
>
> Not by 'git submodule update'. If there are no out-of-tree overrides
> and the user calls 'git submodule checkout' with a new local-branch in
> .gitmodules, *that* should checkout a new submodule branch.
Hmm, but isn't "submodule sync" the command that copies changed
upstream config values (currently only the url) into the local config?
Then a subsequent "submodule update" could do the actual checkout.
>>>> First I'd like to see a real consensus about what exactly should
>>>> happen when a branch is configured to be checked out (and if I
>>>> missed such a summary in this thread, please point me to it ;-).
>>>
>>> I don't think we have a consensus yet. A stand-alone outline of my
>>> current position is in my v3 RFC [5], but I don't have any buy-in yet
>>> ;).
>>
>> I'll volunteer to prepare a table explaining the different modes
>> in my github wiki. Will scan this thread and your pointers for input
>> and will come back soon when I have something ready.
>
> Thanks :).
A first - rather basic - attempt can be seen at:
https://github.com/jlehmann/git-submod-enhancements/wiki/Submodule-modes
Input of any kind is very welcome!
>>>> And we should contrast that to the exact checkout and floating
>>>> branch use cases.
>>>
>>> With my v3 series, there are no more detached HEADs. Folks using
>>> checkout updates get a local master branch. I do not change any of
>>> the exact checkout (superproject gitlinked sha1) vs. floating
>>> (subproject's remote submodule.<name>.branch via 'update --remote')
>>> logic, because that already works well. The problem is the local
>>> branch handling, not the update/integration logic.
>>
>> Ok. Maybe we could use the "<remote>:<local>" notation to store both
>> remote and local branch in a single setting?
>
> Meh :p. I'm fine with (remote-)branch and local-branch as separate
> settings, or a single combined '<remote>:<local>' setting. However, I
> think the local branch name is going to be more closely associated
> with the superproject branch than with the subproject's remote branch,
> and expect folks to want to override the local-branch on a
> per-superproject-branch basis much more often then they'll override
> the latter.
Okay. This is a detail we can decide later.
>>>> later updates,
>>>
>>> The same thing that currently happens, with the exception that
>>> checkout-style updates should use reset to update the
>>> currently-checked out branch (or detached-HEAD), instead of always
>>> detaching the HEAD.
>>
>> Won't the user loose any modifications to his local branch here?
>
> They just called for a checkout-style update, so yes. If they want to
> keep local modifications, chose an integration mode that preserves
> local changes.
Hmm, as current "submodule updates" already makes it too easy to
loose commits, this does not look right to me. I'd prefer to stop
at that point and tell the user what he can do to solve the conflict.
>>>> updates where the local and the remote branch diverged,
>>>
>>> The same thing that currently happens. For local (non --remote)
>>> updates, the integrated branch is the superproject's gitlinked sha1.
>>> For --remote updates, the integrated branch is the remote subproject's
>>> submodule.<name>.branch. We integrate that with the
>>> currently-checked-out local branch (or detached HEAD) using the user's
>>> preferred submodule.<name>.update strategy.
>>
>> And for checkout I can easily overwrite the upstream branch with
>> my local changes?
>
> ? I don't understand. How would you overwrite something in the
> upstream repository?
If the update doesn't overwrite the user-updated local branch (what
I assumed it would do to protect his changes) and he pushes that.
> Maybe you meant "for checkout I can easily
> overwrite the local changes with the upstream branch", which is what I
> understand checkout to do.
But which I find really unfriendly and would not like to see in a new
feature. We should protect the user from loosing any local changes,
not simply throw them away. Recursive update makes sure it won't
overwrite any local modification before it checks out anything and
will abort before doing so (unless forced of course).
>>>> 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?
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-09 21:40 ` Jens Lehmann
@ 2014-01-09 22:18 ` W. Trevor King
2014-01-14 10:24 ` Heiko Voigt
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-09 22:18 UTC (permalink / raw)
To: Jens Lehmann
Cc: Francesco Pretto, Heiko Voigt, Junio C Hamano, Git, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 11062 bytes --]
On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote:
> 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:
> >>> However, the local-branch setting needs to be both
> >>> per-submodule and per-superproject-branch, so .git/config doesn't work
> >>> very well. I think it's better to use something like my
> >>> .git/modules/<submodule-name>/config implementation [1] to set this
> >>> override.
> >>
> >> Yes, the local branch should be set in the submodule's .git/config
> >> to make operations done inside the submodule work seamlessly.
> >
> > Once you're inside the submodule my local-branch setting shouldn't
> > matter, because it just connects superproject branches with submodule
> > branches. The submodule's config is just a convenient out-of-tree
> > place to store per-submodule overrides.
>
> Now I get it, you want to be able to override a submodule branch for
> every superproject branch. I'm not sure I'd add that in the first
> iteration though, as it seems to add quite some complexity and I'm
> not convinced yet users really need it (but I won't object when we
> find real world use cases for that).
Not much complexity in the code, it's all in the first patch of my v3
series [1]. Adding a new override location doesn't seem that
complicated to me, but I haven't been very successful at getting this
idea across, so maybe it's weirder than I think ;). Clearer
explanations welcome ;).
> >> And it isn't a "per-superproject-branch override" but a
> >> "per-superproject-branch default" which can be overridden in
> >> .git/config (except for 'update', but I intend to fix that).
> >
> > You're talking about .gitmodules vs. .git/config here, but for
> > local-branch, I'm talking about a fallback chain like [1]:
> >
> > 1. superproject.<superproject-branch>.local-branch in the submodule's
> > config (superproject/.git/modules/≤submodule-name>/config).
> > 2. submodule.<submodule-name>.local-branch in the superproject's
> > config (.git/config).
> > 3. submodule.<submodule-name>.local-branch in the superproject's
> > .gitmodules file.
> > 4. default to 'master'
> >
> > Only #1 is a new idea.
>
> Thanks for the explanation, now I understand what you're aiming at.
For additional clarity, my whole v3 series is not super long [2]… ;)
> >>> On the other hand, maybe an in-tree .gitmodules is good enough,
> >>> and folks who want a local override can just edit .gitmodules in
> >>> their local branch? I've never felt the need to override
> >>> .gitmodules myself (for any setting), so feedback from someone
> >>> who has would be useful.
> >>
> >> That way these changes would propagate to others working on the
> >> same branch when pushing, which I believe is a feature.
> >
> > Sure. Unless they don't want to propagate them, at which point
> > they use an out-of-tree override masking the .gitmodules value.
> > The question is, would folks want local overrides for local-branch
> > (like they do for submodule.<name>.update), or not? Since it's
> > easy to do [1], I don't see the point of *not* supporting
> > per-superproject-branch overrides.
>
> Unless actual use cases are shown I'd vote for YAGNI here. A new
> config option means considerable maintenance burden, no matter how
> easy it is to implement in the first place.
Automatically checking out the preferred submodule branch for a given
superproject branch already requires a new config option. The
per-superproject-branch out-of-tree override just renames it (from
submodule.<submodule-name>.local-branch to
superproject.<superproject-branch>.local-branch). So different names
depending on superproject-level or submodule-level config, but still
the same option. That doesn't sound like it's adding that much of a
maintenance burden.
On the other hand, I, personally, have no need for out-of-tree
overrides for *any* submodule-related config, so I'm fine if we drop
the submodule-level lookup location ;).
> > I'm all for rolling my 'git submodule checkout' into 'git checkout
> > --recurse-submodules' [2]. It was just faster to mock up in shell
> > while we decide how it should work.
>
> Sure. As I said that's perfectly fine for testing this approach,
> but we should do that right in "git checkout" and friends and not
> add yet another submodule command.
The current C code looked fairly focused on detached HEAD sha1
checkouts, which was so far away from what I think should happen that
I didn't know where to start ;). If we like the logic layed out in my
v3 series, I'll take another look at the C series and see if I can
come up with something.
> >>>>> If it's not the first clone, you should take no action (and your
> >>>>> original patch was ok about this).
> >>>>
> >>>> I'm not sure this is the right thing to do, after all you
> >>>> configured git to follow that branch so I'd expect it to be
> >>>> updated later too, no? Otherwise you might end up with an old
> >>>> version of your branch while upstream is a zillion commits
> >>>> ahead.
> >>>
> >>> Non-clone updates should not change the submodule's *local* branch
> >>> *name*. They should change the commit that that branch references,
> >>> otherwise 'git submodule update' would be a no-op ;).
> >>
> >> Okay, I seem to have misunderstood that. But what happens when the
> >> branch setting in .gitmodules changes, shouldn't that be updated?
> >
> > Not by 'git submodule update'. If there are no out-of-tree overrides
> > and the user calls 'git submodule checkout' with a new local-branch in
> > .gitmodules, *that* should checkout a new submodule branch.
>
> Hmm, but isn't "submodule sync" the command that copies changed
> upstream config values (currently only the url) into the local config?
> Then a subsequent "submodule update" could do the actual checkout.
'submodule update' currently only checks out detached HEADs with the
'checkout' update mode. I got rid of that in my v3 series, so now all
'submodule update' does is integrate some branch (the gitlinked sha1
or the upstream --remote). It has nothing to do with changing the
locally-checked-out branch.
> >>>> later updates,
> >>>
> >>> The same thing that currently happens, with the exception that
> >>> checkout-style updates should use reset to update the
> >>> currently-checked out branch (or detached-HEAD), instead of
> >>> always detaching the HEAD.
> >>
> >> Won't the user loose any modifications to his local branch here?
> >
> > They just called for a checkout-style update, so yes. If they
> > want to keep local modifications, chose an integration mode that
> > preserves local changes.
>
> Hmm, as current "submodule updates" already makes it too easy to
> loose commits, this does not look right to me. I'd prefer to stop at
> that point and tell the user what he can do to solve the conflict.
Users who are worried about loosing local updates should not be using
a checkout-style updates. If they are using a checkout-style update,
and they ask for an update, they're specifically requesting that we
blow away their local work and checkout/reset to the new sha1.
Solving update conflicts is the whole point of the non-checkout update
modes.
> > Maybe you meant "for checkout I can easily overwrite the local
> > changes with the upstream branch", which is what I understand
> > checkout to do.
>
> But which I find really unfriendly and would not like to see in a
> new feature. We should protect the user from loosing any local
> changes, not simply throw them away. Recursive update makes sure it
> won't overwrite any local modification before it checks out anything
> and will abort before doing so (unless forced of course).
If you want to get rid of checkout-mode updates, I'm fine with that.
However, I don't think it supports use-cases like Heiko's (implied) “I
don't care what's happening upstream, I never touch that submodule,
just checkout what the superproject maintainer says should be checked
out for this branch. Even if they have been rebasing or whatever”
[3].
> >>>> 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.
Those both sound like “integration with the remote submodule” issues
to me. I'm more worried about what happens purely locally as the
developer checks out different superproject branches and wants the
submodules to follow along automatically (without detaching HEADs).
Once we have something that works there, I expect it will be easier to
add recursive superproject branch integration cleanly. For example,
all of the usual branch-level config options (branch.<name>.*) come
along for free.
> But neither local nor upstream changes take precedence, so the user
> should either use "merge" or "rebase" as update strategy
That sounds good to me.
> or be asked to resolve the conflict manually when "checkout" is
> configured and the branches diverged.
I still think that checkout-mode updates should be destructive. See
my paraphrased-version of Heiko's use case above. How are they going
to resolve this manually? Merge or rebase? Why weren't they using
that update mode in the first place?
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/240251
[2]: http://article.gmane.org/gmane.comp.version-control.git/240248
[3]: http://article.gmane.org/gmane.comp.version-control.git/240013
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Tight submodule bindings (was: Preferred local submodule branches)
2014-01-09 6:17 ` [RFC v3 0/4] " W. Trevor King
` (3 preceding siblings ...)
2014-01-09 6:17 ` [RFC v3 4/4] submodule: Add a new 'checkout' command W. Trevor King
@ 2014-01-12 1:08 ` W. Trevor King
2014-01-13 19:37 ` Tight submodule bindings Jens Lehmann
2014-01-13 22:13 ` Junio C Hamano
4 siblings, 2 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-12 1:08 UTC (permalink / raw)
To: Jens Lehmann
Cc: Francesco Pretto, Junio C Hamano, Heiko Voigt, Jonathan Nieder, Git
[-- Attachment #1: Type: text/plain, Size: 13861 bytes --]
On Wed, Jan 08, 2014 at 10:17:51PM -0800, W. Trevor King wrote:
> 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
While mulling over better ways to explain my local-branch idea, I've
come up with a more tightly bound model that may help break the
silence that has greeted the “Preferred local submodule branches”
series ;). That series doesn't have strong options on update
mechanics, which leads to wishy-washy exchanges where nobody has a
clear mental picture:
On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote:
> 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?
The current series is only weakly bound (you can explicitly call git
submodule checkout' to change to the preferred local submodule
branch), and the current Git is extremely weakly bound (you have to cd
into the submodule and change branches by hand). The following
extrapolates the “Preferred local submodule branches” series to a
tightly-bound ideal.
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.
New .git/config options:
* submodule.<name>.active, for init/deinit.
* 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 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.
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. Similarly, a global push would be just:
$ git submodule foreach 'git push'
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.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/44162
[2]: http://article.gmane.org/gmane.comp.version-control.git/211042
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH/RFC] Introduce git submodule add|update --attach
2014-01-02 18:48 ` Francesco Pretto
@ 2014-01-13 17:31 ` Junio C Hamano
0 siblings, 0 replies; 144+ messages in thread
From: Junio C Hamano @ 2014-01-13 17:31 UTC (permalink / raw)
To: Francesco Pretto; +Cc: Phil Hord, git
Francesco Pretto <ceztko@gmail.com> writes:
> Thanks for the comments, my replies below. Before, a couple of general
> questions:
> - I'm also writing some tests, should I commit them together with the
> feature patch?
> - to determine the attached/detached state I did this:
>
> head_detached=
> if test "$(rev-parse --abbrev-ref HEAD)" = "HEAD"
> then
> head_detached="true"
> fi
Use "git symbolic-ref HEAD" to read off of it.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Tight submodule bindings
2014-01-12 1:08 ` Tight submodule bindings (was: Preferred local submodule branches) W. Trevor King
@ 2014-01-13 19:37 ` Jens Lehmann
2014-01-13 20:07 ` W. Trevor King
2014-01-13 22:13 ` Junio C Hamano
1 sibling, 1 reply; 144+ messages in thread
From: Jens Lehmann @ 2014-01-13 19:37 UTC (permalink / raw)
To: W. Trevor King
Cc: Francesco Pretto, Junio C Hamano, Heiko Voigt, Jonathan Nieder, Git
Thanks for the writeup, comments below.
Am 12.01.2014 02:08, schrieb W. Trevor King:
> 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.
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 ;-).
> 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.
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.
> 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*.
You don't need to copy it every time when you simply use the
.gitmodules file as fallback, no?
> 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 ;-)
> 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.
Such a logic might make sense. And without copying stuff from
.gitmodules someplace else it becomes even easier ;-)
> 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.
> 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).
Yep.
> 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.
Yup, our working title for that is "autoinit".
> 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.
> 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.
Agreed.
> 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).
But we won't rename those now.
> 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.
I'm still hoping we might come up with a solution that doesn't need
the syncing.
> 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?
> * 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.
Not needed if you use .gitmodules as fallback.
> 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.
Agreed.
> 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.
> 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>
Ok.
> 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 ;-)
> 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?
The thoughts about the branch workflow are really interesting. Some
other proposals overshoot a bit in my opinion ;-)
> 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.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Tight submodule bindings
2014-01-13 19:37 ` Tight submodule bindings Jens Lehmann
@ 2014-01-13 20:07 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-13 20:07 UTC (permalink / raw)
To: Jens Lehmann
Cc: Francesco Pretto, Junio C Hamano, Heiko Voigt, Jonathan Nieder, Git
[-- Attachment #1: Type: text/plain, Size: 8694 bytes --]
On Mon, Jan 13, 2014 at 08:37:37PM +0100, Jens Lehmann wrote:
> 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 ;-).
I'm still not clear on how this works for you ;). Can you sketch out
an example shell history showing how you use checkout updates to do
this?
> > 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.
I think copying into the submodule's out-of-tree config is the way to
go, because users won't always be driving the submodule from the
superproject. If the settings are in the submodule's out-of-tree
config, everything will be consistent betwee stuff run from the
superproject and stuff run from submodule itself. It also allows us
to use familiar configuration commands inside the submodule, and have
those automatically mapped back into the .gitmodules file for us.
> > 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 ;-)
I'm fine if there is no opt-out, and the syncing is mandatory, but I
imagine that folks who want a local (unshared, not in .gitmodules) URL
would complain.
> > 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.
Good. Then there's no need for this special class of settings.
> > 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.
If you've already checked out the submodule with a current URL, you
should already have the old commit locally, and Git will use it
without trying to re-fetch from the broken old URL.
> > 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.
Sounds good to me.
> > 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.
It's fine because we forced them to commit or stash any (not trivially
mergable) changes before starting the checkout command.
> > 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"?
That checkout-inducing commands should die if the .gitmodule's
local-branch and the submodule's HEAD don't match.
> > 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?
This isn't auto-anything. This is just “I think the submodule is
interesting, please turn it on” (i.e. I ran “git submodule init
<submod>”).
Only active submodules should get all the syncing, setup, and teardown
logic that goes along with submodule checkout. Inactive submodules
are ignored.
> > 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.
Ok.
> > 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?
It does the same thing. Without submodule.<name>.branch configured,
you just integrate the subproject's master.
> > 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 ;-)
That's a strong argument ;). I still don't think the new-in-1.7.4 UI
change will add value. The new-in-1.7.7 --recurse-submodules=check
would still be useful.
> > 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.
I'll prototype it, and keep trying to convince you about the syncing
;). I think the main arguments for syncing are:
* No divergent configs between superproject-initiated actions and
submodule-initiated actions.
* No work clobbered, or accidentally uncommitted, due to syncing
submodule -> superproject before checkout-inducing commands.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Tight submodule bindings
2014-01-12 1:08 ` Tight submodule bindings (was: Preferred local submodule branches) W. Trevor King
2014-01-13 19:37 ` Tight submodule bindings Jens Lehmann
@ 2014-01-13 22:13 ` Junio C Hamano
2014-01-14 2:44 ` W. Trevor King
1 sibling, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-13 22:13 UTC (permalink / raw)
To: W. Trevor King
Cc: Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder, Git
"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. In fact, they would want to be
able to develop more than one histories on top, which means more
than one branches they can name themselves.
The only thing they care about is where the result of their
development _goes_, that is the URL and the branch of the remote
they are pushing back to.
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 ;-)?
And also branch.<name>.merge may say on which of _their_ branch the
commit you learn in the superproject tree would be found. If you
are using centralized workflow, that would be the branch at your
central repository to update with your push, too.
In any case, "local-branch" is wrong from two aspects:
1. (obvious) It does not follow our naming convention not to use
dashed-names for configuration variables.
2. You do not care about the names you use locally. The only thing
you care about is where people meet at the central repository,
i.e. where your result is pushed to.
> 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. But see below.
> ... 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.
I think we would need a bit more sophisticated mechanism than "use
from .git/config if set, otherwise use from .gitmodules", at least
for the URL. It may not be limited to the URL, and other pieces
of metainformation about submodules may need similar handling, but
I'd refrain from extending the scope of discussion needlessly at
this point.
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*]. One way to make it work
semi-automatically is to keep track of what the user has seen in
.gitmodules and offer chances to update entries in .git/config. If
you cloned the superproject recently, you would only know about the
new git://k.org/linux URL and that would be copied to .git/config
(which the current code does). In addition, you would remember that
we saw git://k.org/linux URL (which the current code does not).
Upon switching back to an old version, we could notice that the URL
in .gitmodules, which is git://k.org/linux-2.6, is not something the
user has seen, and at that point we could ask the user to tell us
what URL should be used, record the answer _and_ the fact that we
saw that old URL as well. Then until the superproject updates the
URL the next time to a value that we have never seen, the user can
keep using the right URL without being asked [*2*].
> 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).
Sure.
> 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).
See above.
[Footnote]
*1* On the other hand, the switch of the submodule URL in the
superproject may have been between two separate projects (e.g. you
used to build your embedded appliance using BSD kernel but recent
versions use Linux kernel)---in such a project, you would want the
submodule URL to follow what is in .gitmodules when you switch
between old and new versions in the superproject. But our
recommendation in such a case is to use different names for
submodules that is bound at the same path in the superproject so
that we can keep them as two separate repositories in .git/mdoules/
of the superproject. So at least for the URL, there is no reason to
use the old version that appears in .gitmodules of the superproject
even when you checkout an old version of it.
*2* This "remembering" may have to be more than "have we seen this"
one-bit per different values. For URL, I think the one-bit is
enough, but for other things, it might make sense to keep track of
"In the version of superproject with X in .gitmodules, the user
wants to use value Y" for each values X the user has seen.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Tight submodule bindings
2014-01-13 22:13 ` Junio C Hamano
@ 2014-01-14 2:44 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-14 2:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder, Git
[-- Attachment #1: Type: text/plain, Size: 6868 bytes --]
On Mon, Jan 13, 2014 at 02:13:46PM -0800, Junio C Hamano wrote:
> "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.
They do if they want to checkout the banch out again later, before
pushing it somewhere public.
> In fact, they would want to be able to develop more than one
> histories on top, which means more than one branches they can name
> themselves.
Agreed, bug for each superproject branch they will still have a single
submodule branch that should be checked out by default when they
checkout that superproject branch.
> The only thing they care about is where the result of their
> development _goes_, that is the URL and the branch of the remote
> they are pushing back to.
Maybe they're just doing local development? I think the remote
branch(es) you pull from and push to are important, but not the only
thing you might care about.
> 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.
That makes sense. I don't think the former (as distinct from the
latter) is of any interest to anybody. I don't care what the branch
name was when the past history was developed. I don't even really
care about the new branch name. I do care that checking out a
superproject branch gives me the same branch (with pull/push configs,
etc.) that I had the last time I was on that superproject branch.
> > 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 ;-)?
I can't count? :p
> In any case, "local-branch" is wrong from two aspects:
>
> 1. (obvious) It does not follow our naming convention not to use
> dashed-names for configuration variables.
I'll use localBranch in my mockup ;). Although skimming through
config.txt shows a number of alllowercase settings as well as
camelCase.
> 2. You do not care about the names you use locally. The only thing
> you care about is where people meet at the central repository,
> i.e. where your result is pushed to.
I also care about local-checkout consistency, as described above.
> > 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.
That only works for superproject-level commands that know about the
.gitmodules file. If you cd into the submodule and work there
directly, your actions will be using the submodule's out-of-tree
config. I think most of the time folks will want those out-of-tree
configs to match the settings in the superproject's .gitmodules, hence
the submodule.<name>.sync defaulting to true.
> > ... 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.
Why not? We're blindly updating it to the value that was previously
pulled out of the submodule's out-of-tree config. If the user doesn't
like what's happening to .gitmodules upstream and doesn't want to keep
a patched version locally, they can always turn off
submodule.<name>.sync.
> 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*].
The checkout would work (because the old gitlinked commit is already
in the local repository), but the push would not. I don't think it
would be difficult to recover from that manually (and just specify the
full URL when pushing). You could also:
1. Commit your fix.
2. Checkout a more modern superproject branch (which will load the
current URL into the submodule's config).
3. Push the fix.
4. Continue to work on the modern branch.
That doesn't sound much more difficult than the ideal:
1. Commit your fix.
2. Push the fix.
3. Checkout a more modern superproject branch (which will load the
current URL into the submodule's config).
4. Continue to work on the modern branch.
If you expect to be back making more superproject/subproject joint
bugfixes in future, I think it makes sense to start a maintenance
branch of the superproject that updates the .gitmodules URL to point
at the modern location.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-09 22:18 ` W. Trevor King
@ 2014-01-14 10:24 ` Heiko Voigt
2014-01-14 16:57 ` W. Trevor King
2014-01-14 21:46 ` Re: " Heiko Voigt
0 siblings, 2 replies; 144+ messages in thread
From: Heiko Voigt @ 2014-01-14 10:24 UTC (permalink / raw)
To: W. Trevor King
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Git, Jonathan Nieder
Hi,
On Thu, Jan 09, 2014 at 02:18:40PM -0800, W. Trevor King wrote:
> On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote:
> > 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:
> > >>>> later updates,
> > >>>
> > >>> The same thing that currently happens, with the exception that
> > >>> checkout-style updates should use reset to update the
> > >>> currently-checked out branch (or detached-HEAD), instead of
> > >>> always detaching the HEAD.
> > >>
> > >> Won't the user loose any modifications to his local branch here?
> > >
> > > They just called for a checkout-style update, so yes. If they
> > > want to keep local modifications, chose an integration mode that
> > > preserves local changes.
> >
> > Hmm, as current "submodule updates" already makes it too easy to
> > loose commits, this does not look right to me. I'd prefer to stop at
> > that point and tell the user what he can do to solve the conflict.
>
> Users who are worried about loosing local updates should not be using
> a checkout-style updates. If they are using a checkout-style update,
> and they ask for an update, they're specifically requesting that we
> blow away their local work and checkout/reset to the new sha1.
> Solving update conflicts is the whole point of the non-checkout update
> modes.
But checkout is different from reset --hard in that it does not blow
away local uncommitted changes. Please see below.
> > > Maybe you meant "for checkout I can easily overwrite the local
> > > changes with the upstream branch", which is what I understand
> > > checkout to do.
> >
> > But which I find really unfriendly and would not like to see in a
> > new feature. We should protect the user from loosing any local
> > changes, not simply throw them away. Recursive update makes sure it
> > won't overwrite any local modification before it checks out anything
> > and will abort before doing so (unless forced of course).
>
> If you want to get rid of checkout-mode updates, I'm fine with that.
> However, I don't think it supports use-cases like Heiko's (implied) “I
> don't care what's happening upstream, I never touch that submodule,
> just checkout what the superproject maintainer says should be checked
> out for this branch. Even if they have been rebasing or whatever”
> [3].
I never stated that in that post. Even with the current checkout-mode
updates you'll never loose local modifications (without force) that are
not committed. I think you have to distinguish between local
modifications in the worktree and the ones that are committed.
The recursive checkout Jens is working on is simply implementing the
current checkout-mode to the places where the superproject checks out
its files. That way submodules get checked out when the superproject is
checked out. If the submodule does not match the sha1 registered in the
superproject it either stays there (if the checkout would not need to
update the submodule) or (if checkout would need to update) git will not
do the checkout and bail out with "you have local modifications to ... .
I think the whole recursive checkout topic is already complicated enough
as it is so we should currently not add anything from this discussion to
it until it is cleaned up and merged. We also need recursive fetch for
that which I am planning to work on as soon as we settle this
discussion. I will write another post about how I think we should/can
proceed.
> > or be asked to resolve the conflict manually when "checkout" is
> > configured and the branches diverged.
>
> I still think that checkout-mode updates should be destructive. See
> my paraphrased-version of Heiko's use case above. How are they going
> to resolve this manually? Merge or rebase? Why weren't they using
> that update mode in the first place?
I strongly disagree. They should only be destructive in the sense that
another commit get checked out but never loose local modifications.
> [1]: http://article.gmane.org/gmane.comp.version-control.git/240251
> [2]: http://article.gmane.org/gmane.comp.version-control.git/240248
> [3]: http://article.gmane.org/gmane.comp.version-control.git/240013
Cheers Heiko
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-14 10:24 ` Heiko Voigt
@ 2014-01-14 16:57 ` W. Trevor King
2014-01-14 20:58 ` Heiko Voigt
2014-01-14 21:46 ` Re: " Heiko Voigt
1 sibling, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-14 16:57 UTC (permalink / raw)
To: Heiko Voigt
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Git, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 3556 bytes --]
On Tue, Jan 14, 2014 at 11:24:45AM +0100, Heiko Voigt wrote:
> On Thu, Jan 09, 2014 at 02:18:40PM -0800, W. Trevor King wrote:
> > Users who are worried about loosing local updates should not be
> > using a checkout-style updates. If they are using a
> > checkout-style update, and they ask for an update, they're
> > specifically requesting that we blow away their local work and
> > checkout/reset to the new sha1. Solving update conflicts is the
> > whole point of the non-checkout update modes.
>
> But checkout is different from reset --hard in that it does not blow
> away local uncommitted changes. Please see below.
Ah, good point. We should definately die if there are local
uncommitted changes.
> > On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote:
> > > Am 09.01.2014 20:55, schrieb W. Trevor King:
> > > > Maybe you meant "for checkout I can easily overwrite the local
> > > > changes with the upstream branch", which is what I understand
> > > > checkout to do.
> > >
> > > But which I find really unfriendly and would not like to see in
> > > a new feature. We should protect the user from loosing any local
> > > changes, not simply throw them away. Recursive update makes sure
> > > it won't overwrite any local modification before it checks out
> > > anything and will abort before doing so (unless forced of
> > > course).
> >
> > If you want to get rid of checkout-mode updates, I'm fine with
> > that. However, I don't think it supports use-cases like Heiko's
> > (implied) “I don't care what's happening upstream, I never touch
> > that submodule, just checkout what the superproject maintainer
> > says should be checked out for this branch. Even if they have
> > been rebasing or whatever” [3].
>
> I never stated that in that post.
Sorry for misunderstanding. I think I'm just unclear on your
workflow?
> The recursive checkout Jens is working on is simply implementing the
> current checkout-mode to the places where the superproject checks
> out its files. That way submodules get checked out when the
> superproject is checked out. If the submodule does not match the
> sha1 registered in the superproject it either stays there (if the
> checkout would not need to update the submodule) or (if checkout
> would need to update) git will not do the checkout and bail out with
> "you have local modifications to ... .
Sounds good to me as far as it goes. I think it misses the “what
should we do if the gitlinked hashes are different” case, because the
checkout will always leave you with a detached HEAD.
> > > or be asked to resolve the conflict manually when "checkout" is
> > > configured and the branches diverged.
> >
> > I still think that checkout-mode updates should be destructive.
> > See my paraphrased-version of Heiko's use case above. How are
> > they going to resolve this manually? Merge or rebase? Why
> > weren't they using that update mode in the first place?
>
> I strongly disagree. They should only be destructive in the sense
> that another commit get checked out but never loose local
> modifications.
I think the key I'm missing is an example workflow where a developer
wants to make local submodule changes, but also wants to use
checkout-mode updates instead of merge/rebase updates. Can you sketch
one out for me?
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-14 16:57 ` W. Trevor King
@ 2014-01-14 20:58 ` Heiko Voigt
2014-01-14 21:42 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-14 20:58 UTC (permalink / raw)
To: W. Trevor King
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Git, Jonathan Nieder
On Tue, Jan 14, 2014 at 08:57:09AM -0800, W. Trevor King wrote:
> > > On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote:
> > > > Am 09.01.2014 20:55, schrieb W. Trevor King:
> > > > > Maybe you meant "for checkout I can easily overwrite the local
> > > > > changes with the upstream branch", which is what I understand
> > > > > checkout to do.
> > > >
> > > > But which I find really unfriendly and would not like to see in
> > > > a new feature. We should protect the user from loosing any local
> > > > changes, not simply throw them away. Recursive update makes sure
> > > > it won't overwrite any local modification before it checks out
> > > > anything and will abort before doing so (unless forced of
> > > > course).
> > >
> > > If you want to get rid of checkout-mode updates, I'm fine with
> > > that. However, I don't think it supports use-cases like Heiko's
> > > (implied) “I don't care what's happening upstream, I never touch
> > > that submodule, just checkout what the superproject maintainer
> > > says should be checked out for this branch. Even if they have
> > > been rebasing or whatever” [3].
> >
> > I never stated that in that post.
>
> Sorry for misunderstanding. I think I'm just unclear on your
> workflow?
Yes probably. We mostly use submodules for shared code and for tracking
external libraries. For the shared code we want to make sure that
the changes that come from one project do not break anything in another
project that also uses that code so the submodules are maintained and
reviewed separately and ideally contain tests for the expected
functionality.
A typical workflow where a feature in a project needs some extension or
change in a submodule goes like this:
1. The developer does his changes locally implementing everything
needed. To commit he creates a local branch in the submodule and in
the superproject (most of the times from the current HEAD that is
checked out).
2. For convenience I usually commit the resulting commit sha1 of the
submodule in the commit that needs the change. That way when I switch
to a different branch and back I can simply say: git submodule update
and get the correct code everywhere.
3. Once done with the whole feature I first do the review process
(adding any missing tests to ensure my change does not break, ...)
for the submodule to get the feature branch merged into a stable one.
In our superproject only commits sha1 from a stable branch are
allowed so the submodule change needs to be reviewed first.
4. Once the change is in a stable branch in the submodule I then update
the commit sha1 link in the superproject that needs the change. That
is usually done by rebasing the branch in the superproject and
registering the new stable branch (typically master).
5. Then I proceed with the review process in the superproject as if it
was a normal change without a submodule.
Thats our main use case.
> > The recursive checkout Jens is working on is simply implementing the
> > current checkout-mode to the places where the superproject checks
> > out its files. That way submodules get checked out when the
> > superproject is checked out. If the submodule does not match the
> > sha1 registered in the superproject it either stays there (if the
> > checkout would not need to update the submodule) or (if checkout
> > would need to update) git will not do the checkout and bail out with
> > "you have local modifications to ... .
>
> Sounds good to me as far as it goes. I think it misses the “what
> should we do if the gitlinked hashes are different” case, because the
> checkout will always leave you with a detached HEAD.
>
> > > > or be asked to resolve the conflict manually when "checkout" is
> > > > configured and the branches diverged.
> > >
> > > I still think that checkout-mode updates should be destructive.
> > > See my paraphrased-version of Heiko's use case above. How are
> > > they going to resolve this manually? Merge or rebase? Why
> > > weren't they using that update mode in the first place?
> >
> > I strongly disagree. They should only be destructive in the sense
> > that another commit get checked out but never loose local
> > modifications.
>
> I think the key I'm missing is an example workflow where a developer
> wants to make local submodule changes, but also wants to use
> checkout-mode updates instead of merge/rebase updates. Can you sketch
> one out for me?
How about the use-case I sketched above? Is that what you are searching
for? In that use-case we have to update to the new master after a
submodule change was merged. That could be achieved by
git submodule update --remote <submodule>
with the wanted stable branch configured. But in practise something
along the lines of
(cd <submodule> && git checkout origin/<stable>)
is usually used and simple enough.
We have a tool in our git gui configuration that does
git submodule foreach 'git fetch && git checkout origin/master'
which can be used by the maintainer before a release to ensure that all
submodules are up-to-date. But in practise it turn out that all
submodules are fairly current since everyone is adding features to the
quite frequently and thus pulling in the current version automatically.
I hope that draws a clear picture of how we use submodules.
Cheers Heiko
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-14 20:58 ` Heiko Voigt
@ 2014-01-14 21:42 ` W. Trevor King
2014-01-14 22:19 ` Heiko Voigt
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-14 21:42 UTC (permalink / raw)
To: Heiko Voigt
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Git, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]
On Tue, Jan 14, 2014 at 09:58:30PM +0100, Heiko Voigt wrote:
> A typical workflow where a feature in a project needs some extension or
> change in a submodule goes like this:
>
> 1. The developer does his changes locally implementing everything
> needed. To commit he creates a local branch in the submodule and in
> the superproject (most of the times from the current HEAD that is
> checked out).
>
> 2. For convenience I usually commit the resulting commit sha1 of the
> submodule in the commit that needs the change. That way when I switch
> to a different branch and back I can simply say: git submodule update
> and get the correct code everywhere.
This checkout functionality is exactly what my
submodule.<name>.localBranch is designed to automate [1]. I think
that should be different from integrating local and external changes,
which is what 'git submodule update' is about. For example, after you
run 'git submodule update' here, you'll have your original commit
checked out, but you'll be on a detached HEAD instead of your original
branch. If you want to further develop the submodule feature branch,
you currently have to cd into the submodule and check the branch out
by hand.
> How about the use-case I sketched above? Is that what you are searching
> for? In that use-case we have to update to the new master after a
> submodule change was merged. That could be achieved by
>
> git submodule update --remote <submodule>
>
> with the wanted stable branch configured. But in practise something
> along the lines of
>
> (cd <submodule> && git checkout origin/<stable>)
>
> is usually used and simple enough.
The “gitlinked commits must be in the subproject's master” rule
protects you from blowing stuff away here. You could use rebase- or
merge-style integration as well, assuming the maintainer didn't have
dirty local work in their submodule.
> We have a tool in our git gui configuration that does
>
> git submodule foreach 'git fetch && git checkout origin/master'
I agree that with 'submodule update' seems superfluous. With proper
out-of-tree submodule configs specifying remote URLs and upstream
branches,
git submodule foreach 'git fetch && git checkout @{upstream}'
(or merge/rebase/…) should cover this case more generically and with
less mental overhead.
> I hope that draws a clear picture of how we use submodules.
It's certainly clearer, thanks :). I'm not sure where checkout-mode
is specifically important, though. In your step-2, it doesn't restore
your original branch. In your “update the superproject's master”
step, you aren't even using 'submodule update' :p.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/240336
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-14 10:24 ` Heiko Voigt
2014-01-14 16:57 ` W. Trevor King
@ 2014-01-14 21:46 ` Heiko Voigt
2014-01-14 22:22 ` W. Trevor King
1 sibling, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-14 21:46 UTC (permalink / raw)
To: W. Trevor King
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Git, Jonathan Nieder
Hi,
On Tue, Jan 14, 2014 at 11:24:45AM +0100, Heiko Voigt wrote:
> I will write another post about how I think we should/can proceed.
and here is my suggestion how we should proceed.
I think there have been many interesting ideas in this thread but IMO
some of them tried to achieve a little bit to much and were not clear
enough. I am a fan of: Keep it as simple as possible, but *no simpler*.
I think some ideas where going in the "make it to simple" direction.
Take my idea for feature branch support from here[1]. After thinking more
thoroughly it still too many corner cases. E.g. it is way to easy to
accidentally merge the feature branch configuration into the stable branch. But
we want to support the user properly so we need to catch stuff like that.
Submodules are separate projects. There is a boundary between
superproject and submodule and IMO its there for a good reason. E.g.
take the typical "shared code" use-case. If A and B are using C
then both want to make sure a change from A does not break B's
expectations and vice versa. Thats were you usually write unit tests in
C for: Ensure that the expectations are met. The more users of the code
the higher the quality and thus the boundary for bad code should be.
I would like to step back a bit and get back to the original problem at hand:
Francescos original use case of an attached head for direct commits on a stable
branch in a submodule. How about we finish discussing the exact solution of
that first. AFAIK that is already solved with the following:
* Trevor's first patch[2] to create a branch on initial clone of a submodule
* A possibly a configuration variable for --remote so it can be
set as the default update method
* Combined with submodule.<name>.update=merge/rebase
That should be all (and IIRC Francesco agreed) needed for that use-case.
Lets not implement more than currently is needed. We can revisit the ideas once
some other real use-case manifests. Also we (Jens and I) would first like to
proceed with the recursive checkout / fetch (for which the plan is clear) as
the next complicated step.
Once that is done and people gain some experience with it we can still extend
further.
What do you think?
Cheers Heiko
[1] http://article.gmane.org/gmane.comp.version-control.git/240178/
[2] http://article.gmane.org/gmane.comp.version-control.git/239921
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-14 21:42 ` W. Trevor King
@ 2014-01-14 22:19 ` Heiko Voigt
2014-01-14 22:39 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Heiko Voigt @ 2014-01-14 22:19 UTC (permalink / raw)
To: W. Trevor King
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Git, Jonathan Nieder
On Tue, Jan 14, 2014 at 01:42:09PM -0800, W. Trevor King wrote:
> On Tue, Jan 14, 2014 at 09:58:30PM +0100, Heiko Voigt wrote:
> > A typical workflow where a feature in a project needs some extension or
> > change in a submodule goes like this:
> >
> > 1. The developer does his changes locally implementing everything
> > needed. To commit he creates a local branch in the submodule and in
> > the superproject (most of the times from the current HEAD that is
> > checked out).
> >
> > 2. For convenience I usually commit the resulting commit sha1 of the
> > submodule in the commit that needs the change. That way when I switch
> > to a different branch and back I can simply say: git submodule update
> > and get the correct code everywhere.
>
> This checkout functionality is exactly what my
> submodule.<name>.localBranch is designed to automate [1]. I think
> that should be different from integrating local and external changes,
> which is what 'git submodule update' is about. For example, after you
> run 'git submodule update' here, you'll have your original commit
> checked out, but you'll be on a detached HEAD instead of your original
> branch. If you want to further develop the submodule feature branch,
> you currently have to cd into the submodule and check the branch out
> by hand.
Yes and thats exactly what my idea was about but after further thinking
am afraid that this is the wrong place. I am not sure but afraid as I
wrote in the other post that it would be way to dangerous to accidentally
merge these changes in. We would need something to prevent this
configuration from ever entering a stable branch.
Another solution (and completely different approach) would be to have
something that is outside of the tree and actually attached to a
branchname. E.g. at the gitmerge last year I though it would be nice to
have a place for a description for a branch inside git. In a short
discussion we were envisioning a special ref like the notes trees but
allowing to attach and describe branches. That place could also be where
we could store such a configuration. Once the branchname ceases to exist
so would the configuration.
I know this is a completely different piece of work so I am not sure
whether we want to pursue it at the moment. But at the moment I think
this would actually be the correct solution.
> > How about the use-case I sketched above? Is that what you are searching
> > for? In that use-case we have to update to the new master after a
> > submodule change was merged. That could be achieved by
> >
> > git submodule update --remote <submodule>
> >
> > with the wanted stable branch configured. But in practise something
> > along the lines of
> >
> > (cd <submodule> && git checkout origin/<stable>)
> >
> > is usually used and simple enough.
>
> The “gitlinked commits must be in the subproject's master” rule
> protects you from blowing stuff away here. You could use rebase- or
> merge-style integration as well, assuming the maintainer didn't have
> dirty local work in their submodule.
No we can't. Developers are not allowed to merge in some submodules.
The most central ones have maintainers and only they are allowed to
merge into the stable branch. So we need to track exact commits on the
stable branch, no local merge (except the fast-forward case of course)
allowed. Thats why the developer does an exact checkout here.
> > We have a tool in our git gui configuration that does
> >
> > git submodule foreach 'git fetch && git checkout origin/master'
>
> I agree that with 'submodule update' seems superfluous. With proper
> out-of-tree submodule configs specifying remote URLs and upstream
> branches,
>
> git submodule foreach 'git fetch && git checkout @{upstream}'
>
> (or merge/rebase/…) should cover this case more generically and with
> less mental overhead.
>
> > I hope that draws a clear picture of how we use submodules.
>
> It's certainly clearer, thanks :). I'm not sure where checkout-mode
> is specifically important, though. In your step-2, it doesn't restore
> your original branch. In your “update the superproject's master”
> step, you aren't even using 'submodule update' :p.
Ah sorry I though that was clear. The "others" are using submodule update ;-)
I mean someone who gets stuff from a stable superproject branch by
either rebasing their development branch or updating their local copy of
a stable branch (e.g. master) by using
git checkout master
git pull --ff --ff-only
git submodule update --init --recursive
This also prevents the pure "updaters" from creating unnecessary merges.
Cheers Heiko
> [1]: http://article.gmane.org/gmane.comp.version-control.git/240336
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-14 21:46 ` Re: " Heiko Voigt
@ 2014-01-14 22:22 ` W. Trevor King
2014-01-14 22:42 ` Heiko Voigt
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-14 22:22 UTC (permalink / raw)
To: Heiko Voigt
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Git, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 3445 bytes --]
On Tue, Jan 14, 2014 at 10:46:08PM +0100, Heiko Voigt wrote:
> I would like to step back a bit and get back to the original problem
> at hand: Francescos original use case of an attached head for direct
> commits on a stable branch in a submodule. How about we finish
> discussing the exact solution of that first. AFAIK that is already
> solved with the following:
>
> * Trevor's first patch[2] to create a branch on initial clone of a submodule
v1 broke a bunch of tests. Are you ok with v2 [1]? v2 still needs a
clearer commit message, a test, and a possible transition to
triggering on non-checkout submodule.<name>.update instead of
non-empty submodule.<name>.branch [2].
> That should be all (and IIRC Francesco agreed) needed for that use-case.
That was my understanding [3] ;).
> Lets not implement more than currently is needed. We can revisit the
> ideas once some other real use-case manifests.
I have most of a real use case already. I have a repository with
submodules in one branch (master) and a subtree version in another
(assembled) [4]. The *tree* is the same in each case, so I have to
'git rm -rf .' to clear the submodules out of master before I can
checkout assembled.
$ git checkout assembled
error: The following untracked working tree files would be overwritten by checkout:
modular/README.md
modular/shell/README.md
…
$ git rm -rf .
$ git checkout assembled
That leaves some extra stuff removed:
$ git status
On branch assembled
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
deleted: .gitignore
deleted: .mailmap
deleted: CONTRIBUTING.md
deleted: LICENSE.md
deleted: instructor.md
so I need to check that out by hand:
$ git reset --hard HEAD
Now I can work in the assembled branch. Going back to master is a bit
less tedious:
$ git checkout master
$ git submodule update --recursive
Luckily for me, I don't have a third superproject branch where the
submodules are on a different, so the submodule's HEADs are preserved.
As I understand it, the new recursive checkout functionality [5] would
checkout my submodules with detached HEADs. The fact that they are
only accidentally preserved now is not comforting ;).
> Also we (Jens and I) would first like to proceed with the recursive
> checkout / fetch (for which the plan is clear) as the next
> complicated step.
>
> Once that is done and people gain some experience with it we can
> still extend further.
This is quite reasonable. Given the need for backwards compatibility,
I just wanted to make sure my ideal UI was clear before we went
forward. There's no need to break fingers twice ;), but if tight
binding with localBranch is too big a chunk to bite off now, I'm happy
to kick that can down the road.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/239967
[2]: http://article.gmane.org/gmane.comp.version-control.git/239973
[3]: http://article.gmane.org/gmane.comp.version-control.git/240139
[4]: (gitweb) http://git.tremily.us/?p=swc-boot-camp.git
[5]: http://article.gmane.org/gmane.comp.version-control.git/239695
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-14 22:19 ` Heiko Voigt
@ 2014-01-14 22:39 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-14 22:39 UTC (permalink / raw)
To: Heiko Voigt
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Git, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 3020 bytes --]
On Tue, Jan 14, 2014 at 11:19:07PM +0100, Heiko Voigt wrote:
> On Tue, Jan 14, 2014 at 01:42:09PM -0800, W. Trevor King wrote:
> > The “gitlinked commits must be in the subproject's master” rule
> > protects you from blowing stuff away here. You could use rebase- or
> > merge-style integration as well, assuming the maintainer didn't have
> > dirty local work in their submodule.
>
> No we can't. Developers are not allowed to merge in some submodules.
> The most central ones have maintainers and only they are allowed to
> merge into the stable branch. So we need to track exact commits on the
> stable branch, no local merge (except the fast-forward case of course)
> allowed. Thats why the developer does an exact checkout here.
Because both sides of the merge/rebase are required (by your rule) to
be in the subproject's master, you're guaranteed to have a
fast-forward merge/rebase.
> > > We have a tool in our git gui configuration that does
> > >
> > > git submodule foreach 'git fetch && git checkout origin/master'
> >
> > I agree that with 'submodule update' seems superfluous. With proper
> > out-of-tree submodule configs specifying remote URLs and upstream
> > branches,
> >
> > git submodule foreach 'git fetch && git checkout @{upstream}'
> >
> > (or merge/rebase/…) should cover this case more generically and with
> > less mental overhead.
> >
> > > I hope that draws a clear picture of how we use submodules.
> >
> > It's certainly clearer, thanks :). I'm not sure where checkout-mode
> > is specifically important, though. In your step-2, it doesn't restore
> > your original branch. In your “update the superproject's master”
> > step, you aren't even using 'submodule update' :p.
>
> Ah sorry I though that was clear. The "others" are using submodule update ;-)
>
> I mean someone who gets stuff from a stable superproject branch by
> either rebasing their development branch or updating their local copy of
> a stable branch (e.g. master) by using
>
> git checkout master
> git pull --ff --ff-only
> git submodule update --init --recursive
>
> This also prevents the pure "updaters" from creating unnecessary merges.
Right. Folks who don't do local development in their submodules can
get away with checkout-mode updates and their detached HEADs.
Assuming the upstream superproject only advances the gitlinked commits
using fast-forwards, they could equally well use any of the other
update modes, but there is no need for them to make that assumption.
*This* is the use case that I think the current recursive-checkout
facilitates [1]. I don't think it helps folks who are actually doing
submodule development on branches from within their superproject.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/239695
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-14 22:22 ` W. Trevor King
@ 2014-01-14 22:42 ` Heiko Voigt
2014-01-15 0:02 ` Francesco Pretto
2014-01-16 4:09 ` [PATCH v4 0/6] submodule: Local branch creation in module_clone W. Trevor King
0 siblings, 2 replies; 144+ messages in thread
From: Heiko Voigt @ 2014-01-14 22:42 UTC (permalink / raw)
To: W. Trevor King
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Git, Jonathan Nieder
On Tue, Jan 14, 2014 at 02:22:31PM -0800, W. Trevor King wrote:
> On Tue, Jan 14, 2014 at 10:46:08PM +0100, Heiko Voigt wrote:
> > I would like to step back a bit and get back to the original problem
> > at hand: Francescos original use case of an attached head for direct
> > commits on a stable branch in a submodule. How about we finish
> > discussing the exact solution of that first. AFAIK that is already
> > solved with the following:
> >
> > * Trevor's first patch[2] to create a branch on initial clone of a submodule
>
> v1 broke a bunch of tests. Are you ok with v2 [1]? v2 still needs a
> clearer commit message, a test, and a possible transition to
> triggering on non-checkout submodule.<name>.update instead of
> non-empty submodule.<name>.branch [2].
Will have a look.
> > That should be all (and IIRC Francesco agreed) needed for that use-case.
>
> That was my understanding [3] ;).
Thanks for the pointer.
> > Lets not implement more than currently is needed. We can revisit the
> > ideas once some other real use-case manifests.
>
> I have most of a real use case already. I have a repository with
> submodules in one branch (master) and a subtree version in another
> (assembled) [4]. The *tree* is the same in each case, so I have to
> 'git rm -rf .' to clear the submodules out of master before I can
> checkout assembled.
>
> $ git checkout assembled
> error: The following untracked working tree files would be overwritten by checkout:
> modular/README.md
> modular/shell/README.md
> …
> $ git rm -rf .
> $ git checkout assembled
>
> That leaves some extra stuff removed:
>
> $ git status
> On branch assembled
> Changes to be committed:
> (use "git reset HEAD <file>..." to unstage)
>
> deleted: .gitignore
> deleted: .mailmap
> deleted: CONTRIBUTING.md
> deleted: LICENSE.md
> deleted: instructor.md
>
> so I need to check that out by hand:
>
> $ git reset --hard HEAD
>
> Now I can work in the assembled branch. Going back to master is a bit
> less tedious:
>
> $ git checkout master
> $ git submodule update --recursive
>
> Luckily for me, I don't have a third superproject branch where the
> submodules are on a different, so the submodule's HEADs are preserved.
> As I understand it, the new recursive checkout functionality [5] would
> checkout my submodules with detached HEADs. The fact that they are
> only accidentally preserved now is not comforting ;).
As it will be opt-in first (you will have to enable it with config
options) you can keep your current workflow. Once done with the initial
implementation we can discuss and iron out use-cases like yours.
> > Also we (Jens and I) would first like to proceed with the recursive
> > checkout / fetch (for which the plan is clear) as the next
> > complicated step.
> >
> > Once that is done and people gain some experience with it we can
> > still extend further.
>
> This is quite reasonable. Given the need for backwards compatibility,
> I just wanted to make sure my ideal UI was clear before we went
> forward. There's no need to break fingers twice ;), but if tight
> binding with localBranch is too big a chunk to bite off now, I'm happy
> to kick that can down the road.
Yes, that would be good to clearly understand and find out what we
actually want.
Cheers Heiko
> [1]: http://article.gmane.org/gmane.comp.version-control.git/239967
> [2]: http://article.gmane.org/gmane.comp.version-control.git/239973
> [3]: http://article.gmane.org/gmane.comp.version-control.git/240139
> [4]: (gitweb) http://git.tremily.us/?p=swc-boot-camp.git
> [5]: http://article.gmane.org/gmane.comp.version-control.git/239695
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: Re: [RFC v2] submodule: Respect requested branch on all clones
2014-01-14 22:42 ` Heiko Voigt
@ 2014-01-15 0:02 ` Francesco Pretto
2014-01-16 4:09 ` [PATCH v4 0/6] submodule: Local branch creation in module_clone W. Trevor King
1 sibling, 0 replies; 144+ messages in thread
From: Francesco Pretto @ 2014-01-15 0:02 UTC (permalink / raw)
To: Heiko Voigt
Cc: W. Trevor King, Jens Lehmann, Junio C Hamano, Git, Jonathan Nieder
2014/1/14 Heiko Voigt <hvoigt@hvoigt.net>:
> On Tue, Jan 14, 2014 at 02:22:31PM -0800, W. Trevor King wrote:
>> On Tue, Jan 14, 2014 at 10:46:08PM +0100, Heiko Voigt wrote:
>> > I would like to step back a bit and get back to the original problem
>> > at hand: Francescos original use case of an attached head for direct
>> > commits on a stable branch in a submodule. How about we finish
>> > discussing the exact solution of that first. AFAIK that is already
>> > solved with the following:
>> >
>> > * Trevor's first patch[2] to create a branch on initial clone of a submodule
> [...]
>
>> > That should be all (and IIRC Francesco agreed) needed for that use-case.
>>
>> That was my understanding [3] ;).
>
>
I've been silent these days but yes: I confirm Trevor's second patch
iteration[1] gives, IMO, a better meaning of the
submodule.<name>.branch property and is perfectly fine for my use
case, to the point of stopping pursuing for my non behavior changing
patch[4] (I still think it deserved some more in depth reviews, though
;) ).
Cheers,
Francesco
[1]: http://article.gmane.org/gmane.comp.version-control.git/239967
[2]: http://article.gmane.org/gmane.comp.version-control.git/239973
[3]: http://article.gmane.org/gmane.comp.version-control.git/240139
[4]: http://article.gmane.org/gmane.comp.version-control.git/239956
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v3 3/4] submodule: Teach 'add' about a configurable local-branch
2014-01-09 6:17 ` [RFC v3 3/4] submodule: Teach 'add' about a configurable local-branch W. Trevor King
@ 2014-01-15 0:18 ` Francesco Pretto
2014-01-15 1:02 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Francesco Pretto @ 2014-01-15 0:18 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Junio C Hamano, Heiko Voigt, Jens Lehmann, Jonathan Nieder
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@tremily.us>
>
> @@ -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@tremily.us>:
> 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.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [RFC v3 3/4] submodule: Teach 'add' about a configurable local-branch
2014-01-15 0:18 ` Francesco Pretto
@ 2014-01-15 1:02 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-15 1:02 UTC (permalink / raw)
To: Francesco Pretto
Cc: Git, Junio C Hamano, Heiko Voigt, Jens Lehmann, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]
On Wed, Jan 15, 2014 at 01:18:12AM +0100, Francesco Pretto wrote:
> 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).
I think the discussion is still open, but actions are postponed until
'checkout --recurse-submodules' lands [1].
> 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.
The goal is to have “I, your faithful Git command, check out for you,
oh wise developer, the superproject branch you requested, along with
the local submodule branch associated with that super project branch.”
;) Maybe that would be more clear if the localBranch settings are
purely local (stored only in out-of-tree configs), and not contained
in the superproject's .gitmodules file? As this series stands, that
would just drop step 3 from the lookup chain [2]. That step is below
all the local out-of-tree locations though, and I see no
non-psychological reason to keep folks from sharing reasonable default
names for local branches.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/240420
[2]: http://article.gmane.org/gmane.comp.version-control.git/240251
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* [PATCH v4 0/6] submodule: Local branch creation in module_clone
2014-01-14 22:42 ` Heiko Voigt
2014-01-15 0:02 ` Francesco Pretto
@ 2014-01-16 4:09 ` W. Trevor King
2014-01-16 4:10 ` [PATCH v4 1/6] submodule: Make 'checkout' update_module explicit W. Trevor King
` (5 more replies)
1 sibling, 6 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 4:09 UTC (permalink / raw)
To: Git
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, W. Trevor King
Here is the next iteration of cloning-update local branch setup. This
version is based on Francesco's fp/submodule-checkout-mode [1], and
moves back towards the weakly-bound v2 approach and away from the
tightly-bound v3 approach.
The first patch in this series extends that commit to consolidate ''
and 'checkout' update_module values. I wouldn't mind if that gets
squashed into Francesco's patch.
The meat of the series is in the third patch, which changes the v2
implementation by triggering attached HEADs based on the update-mode
instead of on the existence of a non-empty submodule.<name>.branch
[2]. There has been pushback from both Heiko [3] and Jens [4] on my
mapping checkout updaters to “developers not interested in local
submodule development”, but I still think it's the right
interpretation. I'm not clear on Heiko or Jens' current possitions,
maybe I've won them over ;).
The other patches in this series are all new in v4.
This still does a double checkout (once in module_clone to create a
local branch, and again in cmd_update to point that branch at the
correct commit), which Heiko was not excited about [5].
I'm also not sure if defaulting to $remote_name/$branch in cmd_update
is appropriate. cmd_add defaults to using the remote's HEAD, and that
makes more sense to me than defaulting to the master branch. However,
changing this logic is probably food for another series.
I still think that this series is only useful as a temporary stop-gap
[6] until we get something like my v3 [7], so the appropriate
submodule branch is automatically checked out when you change
superproject branches.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/240036
[2]: http://article.gmane.org/gmane.comp.version-control.git/239973
[3]: http://article.gmane.org/gmane.comp.version-control.git/239978
[4]: http://article.gmane.org/gmane.comp.version-control.git/240368
[5]: http://article.gmane.org/gmane.comp.version-control.git/239968
[6]: http://article.gmane.org/gmane.comp.version-control.git/240232
[7]: http://article.gmane.org/gmane.comp.version-control.git/240248
W. Trevor King (6):
submodule: Make 'checkout' update_module explicit
submodule: Document module_clone arguments in comments
submodule: Explicit local branch creation in module_clone
t7406: Just-cloned checkouts update to the gitlinked hash with 'reset'
t7406: Add explicit tests for head attachement after cloning updates
Documentation: Describe 'submodule update' modes in detail
Documentation/git-submodule.txt | 36 +++++++++++++-----
Documentation/gitmodules.txt | 4 ++
git-submodule.sh | 84 +++++++++++++++++++++++++----------------
t/t7406-submodule-update.sh | 39 ++++++++++++++++++-
4 files changed, 121 insertions(+), 42 deletions(-)
--
1.8.5.2.8.g0f6c0d1
^ permalink raw reply [flat|nested] 144+ messages in thread
* [PATCH v4 1/6] submodule: Make 'checkout' update_module explicit
2014-01-16 4:09 ` [PATCH v4 0/6] submodule: Local branch creation in module_clone W. Trevor King
@ 2014-01-16 4:10 ` W. Trevor King
2014-01-16 18:46 ` Junio C Hamano
2014-01-16 4:10 ` [PATCH v4 2/6] submodule: Document module_clone arguments in comments W. Trevor King
` (4 subsequent siblings)
5 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 4:10 UTC (permalink / raw)
To: Git
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, W. Trevor King
This avoids the current awkwardness of having either '' or 'checkout'
for checkout-mode updates, which makes testing for checkout-mode
updates (or non-checkout-mode updates) easier.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
git-submodule.sh | 27 +++++++++++----------------
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 5247f78..5e8776c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -803,17 +803,10 @@ 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
- *)
- die "$(eval_gettext "Invalid update mode '$update_module' for submodule '$name'")"
- ;;
- esac
+ if test -z "$update_module"
+ then
+ update_module="checkout"
+ fi
fi
displaypath=$(relative_path "$prefix$sm_path")
@@ -882,11 +875,16 @@ Maybe you want to use 'update --init'?")"
case ";$cloned_modules;" in
*";$name;"*)
# then there is no local change to integrate
- update_module= ;;
+ update_module=checkout ;;
esac
must_die_on_failure=
case "$update_module" in
+ checkout)
+ 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'")"
+ ;;
rebase)
command="git rebase"
die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$displaypath'")"
@@ -906,10 +904,7 @@ Maybe you want to use 'update --init'?")"
must_die_on_failure=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'")"
- ;;
+ die "$(eval_gettext "Invalid update mode '$update_module' for submodule '$name'")"
esac
if (clear_local_git_env; cd "$sm_path" && $command "$sha1")
--
1.8.5.2.8.g0f6c0d1
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v4 2/6] submodule: Document module_clone arguments in comments
2014-01-16 4:09 ` [PATCH v4 0/6] submodule: Local branch creation in module_clone W. Trevor King
2014-01-16 4:10 ` [PATCH v4 1/6] submodule: Make 'checkout' update_module explicit W. Trevor King
@ 2014-01-16 4:10 ` W. Trevor King
2014-01-16 4:10 ` [PATCH v4 3/6] submodule: Explicit local branch creation in module_clone W. Trevor King
` (3 subsequent siblings)
5 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 4:10 UTC (permalink / raw)
To: Git
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, W. Trevor King
Signed-off-by: W. Trevor King <wking@tremily.us>
---
git-submodule.sh | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/git-submodule.sh b/git-submodule.sh
index 5e8776c..68dcbe1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -241,6 +241,12 @@ module_name()
#
# Clone a submodule
#
+# $1 = submodule path
+# $2 = submodule name
+# $3 = URL to clone
+# $4 = reference repository to reuse (empty for independent)
+# $5 = depth argument for shallow clones (empty for deep)
+#
# Prior to calling, cmd_update checks that a possibly existing
# path is not a git repository.
# Likewise, cmd_add checks that path does not exist at all,
--
1.8.5.2.8.g0f6c0d1
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v4 3/6] submodule: Explicit local branch creation in module_clone
2014-01-16 4:09 ` [PATCH v4 0/6] submodule: Local branch creation in module_clone W. Trevor King
2014-01-16 4:10 ` [PATCH v4 1/6] submodule: Make 'checkout' update_module explicit W. Trevor King
2014-01-16 4:10 ` [PATCH v4 2/6] submodule: Document module_clone arguments in comments W. Trevor King
@ 2014-01-16 4:10 ` W. Trevor King
2014-01-16 19:18 ` Junio C Hamano
2014-01-16 19:43 ` Junio C Hamano
2014-01-16 4:10 ` [PATCH v4 4/6] t7406: Just-cloned checkouts update to the gitlinked hash with 'reset' W. Trevor King
` (2 subsequent siblings)
5 siblings, 2 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 4:10 UTC (permalink / raw)
To: Git
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, W. Trevor King
The previous code only checked out branches in cmd_add. This commit
moves the branch-checkout logic into module_clone, where it can be
shared by cmd_add and cmd_update. I also update the initial checkout
command to use 'reset' to preserve branches setup during module_clone.
With this change, folks cloning submodules for the first time via:
$ git submodule update ...
will get a local branch instead of a detached HEAD, unless they are
using the default checkout-mode updates. This is a change from the
previous situation where cmd_update always used checkout-mode logic
(regardless of the requested update mode) for updates that triggered
an initial clone, which always resulted in a detached HEAD.
This commit does not change the logic for updates after the initial
clone, which will continue to create detached HEADs for checkout-mode
updates, and integrate remote work with the local HEAD (detached or
not) in other modes.
The motivation for the change is that developers doing local work
inside the submodule are likely to select a non-checkout-mode for
updates so their local work is integrated with upstream work.
Developers who are not doing local submodule work stick with
checkout-mode updates so any apparently local work is blown away
during updates. For example, if upstream rolls back the remote branch
or gitlinked commit to an earlier version, the checkout-mode developer
wants their old submodule checkout to be rolled back as well, instead
of getting a no-op merge/rebase with the rolled-back reference.
By using the update mode to distinguish submodule developers from
black-box submodule consumers, we can setup local branches for the
developers who will want local branches, and stick with detached HEADs
for the developers that don't care.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
git-submodule.sh | 53 ++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 36 insertions(+), 17 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 68dcbe1..4a09951 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -246,6 +246,9 @@ module_name()
# $3 = URL to clone
# $4 = reference repository to reuse (empty for independent)
# $5 = depth argument for shallow clones (empty for deep)
+# $6 = (remote-tracking) starting point for the local branch (empty for HEAD)
+# $7 = local branch to create (empty for a detached HEAD, unless $6 is
+# also empty, in which case the local branch is left unchanged)
#
# Prior to calling, cmd_update checks that a possibly existing
# path is not a git repository.
@@ -259,6 +262,8 @@ module_clone()
url=$3
reference="$4"
depth="$5"
+ start_point="$6"
+ local_branch="$7"
quiet=
if test -n "$GIT_QUIET"
then
@@ -312,7 +317,16 @@ 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")
+ (
+ clear_local_git_env
+ cd "$sm_path" &&
+ GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
+ # ash fails to wordsplit ${local_branch:+-B "$local_branch"...}
+ case "$local_branch" in
+ '') git checkout -f -q ${start_point:+"$start_point"} ;;
+ ?*) git checkout -f -q -B "$local_branch" ${start_point:+"$start_point"} ;;
+ esac
+ ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
}
isnumber()
@@ -475,16 +489,14 @@ Use -f if you really want to add it." >&2
echo "$(eval_gettext "Reactivating local git directory for submodule '\$sm_name'.")"
fi
fi
- module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" || exit
- (
- clear_local_git_env
- cd "$sm_path" &&
- # ash fails to wordsplit ${branch:+-b "$branch"...}
- case "$branch" in
- '') git checkout -f -q ;;
- ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
- esac
- ) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
+ if test -n "$branch"
+ then
+ start_point="origin/$branch"
+ local_branch="$branch"
+ else
+ start_point=""
+ fi
+ module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" "$start_point" "$local_branch" || exit
fi
git config submodule."$sm_name".url "$realrepo"
@@ -803,7 +815,9 @@ cmd_update()
fi
name=$(module_name "$sm_path") || exit
url=$(git config submodule."$name".url)
- branch=$(get_submodule_config "$name" branch master)
+ config_branch=$(get_submodule_config "$name" branch)
+ branch="${config_branch:-master}"
+ local_branch="$branch"
if ! test -z "$update"
then
update_module=$update
@@ -817,11 +831,15 @@ cmd_update()
displaypath=$(relative_path "$prefix$sm_path")
- if test "$update_module" = "none"
- then
+ case "$update_module" in
+ none)
echo "Skipping submodule '$displaypath'"
continue
- fi
+ ;;
+ checkout)
+ local_branch=""
+ ;;
+ esac
if test -z "$url"
then
@@ -835,7 +853,8 @@ Maybe you want to use 'update --init'?")"
if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
then
- module_clone "$sm_path" "$name" "$url" "$reference" "$depth" || exit
+ start_point="origin/${branch}"
+ module_clone "$sm_path" "$name" "$url" "$reference" "$depth" "$start_point" "$local_branch" || exit
cloned_modules="$cloned_modules;$name"
subsha1=
else
@@ -881,7 +900,7 @@ Maybe you want to use 'update --init'?")"
case ";$cloned_modules;" in
*";$name;"*)
# then there is no local change to integrate
- update_module=checkout ;;
+ update_module='!git reset --hard -q'
esac
must_die_on_failure=
--
1.8.5.2.8.g0f6c0d1
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v4 4/6] t7406: Just-cloned checkouts update to the gitlinked hash with 'reset'
2014-01-16 4:09 ` [PATCH v4 0/6] submodule: Local branch creation in module_clone W. Trevor King
` (2 preceding siblings ...)
2014-01-16 4:10 ` [PATCH v4 3/6] submodule: Explicit local branch creation in module_clone W. Trevor King
@ 2014-01-16 4:10 ` W. Trevor King
2014-01-16 19:22 ` Junio C Hamano
2014-01-16 4:10 ` [PATCH v4 5/6] t7406: Add explicit tests for head attachement after cloning updates W. Trevor King
2014-01-16 4:10 ` [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail W. Trevor King
5 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 4:10 UTC (permalink / raw)
To: Git
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, W. Trevor King
To preserve the local branch, for situations where we're not on a
detached HEAD.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
t/t7406-submodule-update.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 0825a92..5aa9591 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -703,7 +703,7 @@ test_expect_success 'submodule update places git-dir in superprojects git-dir re
git clone super_update_r super_update_r2 &&
(cd super_update_r2 &&
git submodule update --init --recursive >actual &&
- test_i18ngrep "Submodule path .submodule/subsubmodule.: checked out" actual &&
+ test_i18ngrep "Submodule path .submodule/subsubmodule.: .git reset --hard -q" actual &&
(cd submodule/subsubmodule &&
git log > ../../expected
) &&
--
1.8.5.2.8.g0f6c0d1
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v4 5/6] t7406: Add explicit tests for head attachement after cloning updates
2014-01-16 4:09 ` [PATCH v4 0/6] submodule: Local branch creation in module_clone W. Trevor King
` (3 preceding siblings ...)
2014-01-16 4:10 ` [PATCH v4 4/6] t7406: Just-cloned checkouts update to the gitlinked hash with 'reset' W. Trevor King
@ 2014-01-16 4:10 ` W. Trevor King
2014-01-16 4:10 ` [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail W. Trevor King
5 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 4:10 UTC (permalink / raw)
To: Git
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, W. Trevor King
Test that cloning updates checkout the appropriate local branch for
their update-mode:
* Checkout-mode updates get detached HEADs
* Everyone else gets a local branch, matching the configured
submodule.<name>.branch and defaulting to master.
The 'initial-setup' tag makes it easy to reset the superproject to a
known state, as several earlier tests commit to submodules and commit
the changed gitlinks to the superproject, but don't push the new
submodule commits to the upstream subprojects. This makes it
impossible to checkout the current super master, because it references
submodule commits that don't exist in the upstream subprojects. For a
specific example, see the tests that currently generate the
'two_new_submodule_commits' commits.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
t/t7406-submodule-update.sh | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 5aa9591..f056c01 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -63,6 +63,9 @@ test_expect_success 'setup a submodule tree' '
git submodule add ../none none &&
test_tick &&
git commit -m "none"
+ ) &&
+ (cd super &&
+ git tag initial-setup
)
'
@@ -764,4 +767,38 @@ test_expect_success 'submodule update clone shallow submodule' '
)
)
'
+
+test_expect_success 'submodule update --checkout clones detached HEAD' '
+ git clone super super4 &&
+ echo "detached HEAD" >expected &&
+ (cd super4 &&
+ git reset --hard initial-setup &&
+ git submodule init submodule &&
+ git submodule update >> /tmp/log 2>&1 &&
+ (cd submodule &&
+ git symbolic-ref HEAD > ../../actual ||
+ echo "detached HEAD" > ../../actual
+ )
+ ) &&
+ test_cmp actual expected &&
+ rm -rf super4
+'
+
+test_expect_success 'submodule update --merge clones attached HEAD' '
+ git clone super super4 &&
+ echo "refs/heads/master" >expected &&
+ (cd super4 &&
+ git reset --hard initial-setup &&
+ git submodule init submodule &&
+ git config submodule.submodule.update merge &&
+ git submodule update --merge &&
+ (cd submodule &&
+ git symbolic-ref HEAD > ../../actual ||
+ echo "detached HEAD" > ../../actual
+ )
+ ) &&
+ test_cmp actual expected &&
+ rm -rf super4
+'
+
test_done
--
1.8.5.2.8.g0f6c0d1
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail
2014-01-16 4:09 ` [PATCH v4 0/6] submodule: Local branch creation in module_clone W. Trevor King
` (4 preceding siblings ...)
2014-01-16 4:10 ` [PATCH v4 5/6] t7406: Add explicit tests for head attachement after cloning updates W. Trevor King
@ 2014-01-16 4:10 ` W. Trevor King
2014-01-16 20:21 ` Junio C Hamano
5 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 4:10 UTC (permalink / raw)
To: Git
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, W. Trevor King
The old documentation did not distinguish between cloning and
non-cloning updates and lacked clarity on which operations would lead
to detached HEADs, and which would not. The new documentation
addresses these issues while updating the docs to reflect the changes
introduced by this branch's explicit local branch creation in
module_clone.
I also add '--checkout' to the usage summary and group the update-mode
options into a single set.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 36 +++++++++++++++++++++++++++---------
Documentation/gitmodules.txt | 4 ++++
2 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index bfef8a0..02500b4 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -15,8 +15,8 @@ SYNOPSIS
'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|--merge|--checkout] [--reference <repository>]
+ [--depth <depth>] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
[commit] [--] [<path>...]
'git submodule' [--quiet] foreach [--recursive] <command>
@@ -155,13 +155,31 @@ 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.
+ checkout the commit specified in the index of the containing
+ repository. The update mode defaults to 'checkout', but be
+ configured with the 'submodule.<name>.update' setting or the
+ '--rebase', '--merge', or 'checkout' options.
++
+For updates that clone missing submodules, checkout-mode updates will
+create submodules with detached HEADs; all other modes will create
+submodules with a local branch named after 'submodule.<path>.branch'.
++
+For updates that do not clone missing submodules, the submodule's HEAD
+is only touched when the remote reference does not match the
+submodule's HEAD (for none-mode updates, the submodule is never
+touched). The remote reference is usually the gitlinked commit from
+the superproject's tree, but with '--remote' it is the upstream
+subproject's 'submodule.<name>.branch'. This remote reference is
+integrated with the submodule's HEAD using the specified update mode.
+For checkout-mode updates, that will result in a detached HEAD. For
+rebase- and merge-mode updates, the commit referenced by the
+submodule's HEAD may change, but the symbolic reference will remain
+unchanged (i.e. checked-out branches will still be checked-out
+branches, and detached HEADs will still be detached HEADs). If none
+of the builtin modes fit your needs, set 'submodule.<name>.update' to
+'!command' to configure a custom integration command. '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
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index f7be93f..36e5447 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -53,6 +53,10 @@ submodule.<name>.branch::
A remote branch name for tracking updates in the upstream submodule.
If the option is not specified, it defaults to 'master'. See the
`--remote` documentation in linkgit:git-submodule[1] for details.
++
+This branch name is also used for the local branch created by
+non-checkout cloning updates. See the 'update' documentation in
+linkgit:git-submodule[1] for details.
submodule.<name>.fetchRecurseSubmodules::
This option can be used to control recursive fetching of this
--
1.8.5.2.8.g0f6c0d1
^ permalink raw reply related [flat|nested] 144+ messages in thread
* Re: [PATCH v4 1/6] submodule: Make 'checkout' update_module explicit
2014-01-16 4:10 ` [PATCH v4 1/6] submodule: Make 'checkout' update_module explicit W. Trevor King
@ 2014-01-16 18:46 ` Junio C Hamano
2014-01-16 19:22 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-16 18:46 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
"W. Trevor King" <wking@tremily.us> writes:
> This avoids the current awkwardness of having either '' or 'checkout'
> for checkout-mode updates, which makes testing for checkout-mode
> updates (or non-checkout-mode updates) easier.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> git-submodule.sh | 27 +++++++++++----------------
> 1 file changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 5247f78..5e8776c 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -803,17 +803,10 @@ 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
> - *)
> - die "$(eval_gettext "Invalid update mode '$update_module' for submodule '$name'")"
> - ;;
> - esac
> + if test -z "$update_module"
> + then
> + update_module="checkout"
> + fi
> fi
Is this a good change?
It removes the code to prevent a broken configuration value from
slipping through. The code used to stop early to give the user a
chance to fix it before actually letting "submodule update" to go
into the time consuming part, e.g. a call to module_clone, but that
code is now lost.
> displaypath=$(relative_path "$prefix$sm_path")
> @@ -882,11 +875,16 @@ Maybe you want to use 'update --init'?")"
> case ";$cloned_modules;" in
> *";$name;"*)
> # then there is no local change to integrate
> - update_module= ;;
> + update_module=checkout ;;
> esac
>
> must_die_on_failure=
> case "$update_module" in
> + checkout)
> + 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'")"
> + ;;
> ...
> *)
> - 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'")"
> - ;;
> + die "$(eval_gettext "Invalid update mode '$update_module' for submodule '$name'")"
> esac
These two hunks make sense. It is clear in the updated code that
"checkout" is what is implemented with that "git checkout $subforce
-q", and not any other random update mode.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 3/6] submodule: Explicit local branch creation in module_clone
2014-01-16 4:10 ` [PATCH v4 3/6] submodule: Explicit local branch creation in module_clone W. Trevor King
@ 2014-01-16 19:18 ` Junio C Hamano
2014-01-16 19:29 ` W. Trevor King
2014-01-16 19:43 ` Junio C Hamano
1 sibling, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-16 19:18 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
"W. Trevor King" <wking@tremily.us> writes:
> The previous code only checked out branches in cmd_add. This commit
> moves the branch-checkout logic into module_clone, where it can be
> shared by cmd_add and cmd_update. I also update the initial checkout
> command to use 'reset' to preserve branches setup during module_clone.
>
> With this change, folks cloning submodules for the first time via:
>
> $ git submodule update ...
>
> will get a local branch instead of a detached HEAD, unless they are
> using the default checkout-mode updates. This is a change from the
> previous situation where cmd_update always used checkout-mode logic
> (regardless of the requested update mode) for updates that triggered
> an initial clone, which always resulted in a detached HEAD.
>
> This commit does not change the logic for updates after the initial
> clone, which will continue to create detached HEADs for checkout-mode
> updates, and integrate remote work with the local HEAD (detached or
> not) in other modes.
>
> The motivation for the change is that developers doing local work
> inside the submodule are likely to select a non-checkout-mode for
> updates so their local work is integrated with upstream work.
> Developers who are not doing local submodule work stick with
> checkout-mode updates so any apparently local work is blown away
> during updates. For example, if upstream rolls back the remote branch
> or gitlinked commit to an earlier version, the checkout-mode developer
> wants their old submodule checkout to be rolled back as well, instead
> of getting a no-op merge/rebase with the rolled-back reference.
>
> By using the update mode to distinguish submodule developers from
> black-box submodule consumers, we can setup local branches for the
> developers who will want local branches, and stick with detached HEADs
> for the developers that don't care.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> git-submodule.sh | 53 ++++++++++++++++++++++++++++++++++++-----------------
> 1 file changed, 36 insertions(+), 17 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 68dcbe1..4a09951 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -246,6 +246,9 @@ module_name()
> # $3 = URL to clone
> # $4 = reference repository to reuse (empty for independent)
> # $5 = depth argument for shallow clones (empty for deep)
> +# $6 = (remote-tracking) starting point for the local branch (empty for HEAD)
> +# $7 = local branch to create (empty for a detached HEAD, unless $6 is
> +# also empty, in which case the local branch is left unchanged)
> #
> # Prior to calling, cmd_update checks that a possibly existing
> # path is not a git repository.
> @@ -259,6 +262,8 @@ module_clone()
> url=$3
> reference="$4"
> depth="$5"
> + start_point="$6"
> + local_branch="$7"
> quiet=
> if test -n "$GIT_QUIET"
> then
> @@ -312,7 +317,16 @@ 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")
> + (
> + clear_local_git_env
> + cd "$sm_path" &&
> + GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
> + # ash fails to wordsplit ${local_branch:+-B "$local_branch"...}
Interesting...
> + case "$local_branch" in
> + '') git checkout -f -q ${start_point:+"$start_point"} ;;
> + ?*) git checkout -f -q -B "$local_branch" ${start_point:+"$start_point"} ;;
> + esac
I am wondering if it makes more sense if you did this instead:
git checkout -f -q ${start_point:+"$start_point"} &&
if test -n "$local_branch"
then
git checkout -B "$local_branch" HEAD
fi
The optional "re-attaching to the local_branch" done with the second
"checkout" would be a non-destructive no-op to the working tree and
to the index, but it does distinguish between creating the branch
anew and resetting the existing branch in its output (note that
there is no "-q" to squelch it). By doing it this way, when we
later teach "git branch -f" and "git checkout -B" to report more
about what commits have been lost by such a resetting, you will get
the safety for free if you made the switching with "-B" run without
"-q" here.
> + ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
> }
>
> isnumber()
> @@ -475,16 +489,14 @@ Use -f if you really want to add it." >&2
> echo "$(eval_gettext "Reactivating local git directory for submodule '\$sm_name'.")"
> fi
> fi
> - module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" || exit
> - (
> - clear_local_git_env
> - cd "$sm_path" &&
> - # ash fails to wordsplit ${branch:+-b "$branch"...}
> - case "$branch" in
> - '') git checkout -f -q ;;
> - ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
> - esac
> - ) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
> + if test -n "$branch"
> + then
> + start_point="origin/$branch"
> + local_branch="$branch"
> + else
> + start_point=""
> + fi
I'd feel safer if the "else" clause explicitly cleared $local_branch
by assigning an empty string to it; it would make it a lot clearer
that "when $branch is an empty string here, we do not want to
trigger the new codepath to run checkout with "-B $local_branch" in
module_clone" is what you mean.
> + module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" "$start_point" "$local_branch" || exit
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 4/6] t7406: Just-cloned checkouts update to the gitlinked hash with 'reset'
2014-01-16 4:10 ` [PATCH v4 4/6] t7406: Just-cloned checkouts update to the gitlinked hash with 'reset' W. Trevor King
@ 2014-01-16 19:22 ` Junio C Hamano
2014-01-16 19:32 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-16 19:22 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
"W. Trevor King" <wking@tremily.us> writes:
> To preserve the local branch, for situations where we're not on a
> detached HEAD.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
This should be a part of some other change that actually changes how
this "git submodule update" checks out the submodule, no?
> t/t7406-submodule-update.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
> index 0825a92..5aa9591 100755
> --- a/t/t7406-submodule-update.sh
> +++ b/t/t7406-submodule-update.sh
> @@ -703,7 +703,7 @@ test_expect_success 'submodule update places git-dir in superprojects git-dir re
> git clone super_update_r super_update_r2 &&
> (cd super_update_r2 &&
> git submodule update --init --recursive >actual &&
> - test_i18ngrep "Submodule path .submodule/subsubmodule.: checked out" actual &&
> + test_i18ngrep "Submodule path .submodule/subsubmodule.: .git reset --hard -q" actual &&
> (cd submodule/subsubmodule &&
> git log > ../../expected
> ) &&
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 1/6] submodule: Make 'checkout' update_module explicit
2014-01-16 18:46 ` Junio C Hamano
@ 2014-01-16 19:22 ` W. Trevor King
2014-01-16 20:07 ` Francesco Pretto
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 19:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]
On Thu, Jan 16, 2014 at 10:46:36AM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> > @@ -803,17 +803,10 @@ 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
> > - *)
> > - die "$(eval_gettext "Invalid update mode '$update_module' for submodule '$name'")"
> > - ;;
> > - esac
> > + if test -z "$update_module"
> > + then
> > + update_module="checkout"
> > + fi
> > fi
>
> Is this a good change?
>
> It removes the code to prevent a broken configuration value from
> slipping through. The code used to stop early to give the user a
> chance to fix it before actually letting "submodule update" to go
> into the time consuming part, e.g. a call to module_clone, but that
> code is now lost.
Avoiding useless clones is probably more important than avoiding
duplicate "Invalid update mode" messages. I'll reinstate the case
statement in v5, but I think it should live outside of the “load from
config” block, in case someone adds the ability to set arbitrary
update modes from the command line (`--update merge`, `--update
'!command'`, etc.).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 3/6] submodule: Explicit local branch creation in module_clone
2014-01-16 19:18 ` Junio C Hamano
@ 2014-01-16 19:29 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 19:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 3077 bytes --]
On Thu, Jan 16, 2014 at 11:18:00AM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> > @@ -312,7 +317,16 @@ 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")
> > + (
> > + clear_local_git_env
> > + cd "$sm_path" &&
> > + GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
> > + # ash fails to wordsplit ${local_branch:+-B "$local_branch"...}
>
> Interesting...
That's copied out of the old cmd_add code ;). I don't have ash
intalled to actually confirm the comment.
> > + case "$local_branch" in
> > + '') git checkout -f -q ${start_point:+"$start_point"} ;;
> > + ?*) git checkout -f -q -B "$local_branch" ${start_point:+"$start_point"} ;;
> > + esac
>
> I am wondering if it makes more sense if you did this instead:
>
> git checkout -f -q ${start_point:+"$start_point"} &&
> if test -n "$local_branch"
> then
> git checkout -B "$local_branch" HEAD
> fi
>
> The optional "re-attaching to the local_branch" done with the second
> "checkout" would be a non-destructive no-op to the working tree and
> to the index, but it does distinguish between creating the branch
> anew and resetting the existing branch in its output (note that
> there is no "-q" to squelch it). By doing it this way, when we
> later teach "git branch -f" and "git checkout -B" to report more
> about what commits have been lost by such a resetting, you will get
> the safety for free if you made the switching with "-B" run without
> "-q" here.
This is immediately post-non-checkout-clone. There are no local
branches to clobber yet.
> > @@ -475,16 +489,14 @@ Use -f if you really want to add it." >&2
> > echo "$(eval_gettext "Reactivating local git directory for submodule '\$sm_name'.")"
> > fi
> > fi
> > - module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" || exit
> > - (
> > - clear_local_git_env
> > - cd "$sm_path" &&
> > - # ash fails to wordsplit ${branch:+-b "$branch"...}
> > - case "$branch" in
> > - '') git checkout -f -q ;;
> > - ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
> > - esac
> > - ) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
> > + if test -n "$branch"
> > + then
> > + start_point="origin/$branch"
> > + local_branch="$branch"
> > + else
> > + start_point=""
> > + fi
>
> I'd feel safer if the "else" clause explicitly cleared $local_branch
> by assigning an empty string to it; it would make it a lot clearer
> that "when $branch is an empty string here, we do not want to
> trigger the new codepath to run checkout with "-B $local_branch" in
> module_clone" is what you mean.
Ok. Will add in v5.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 4/6] t7406: Just-cloned checkouts update to the gitlinked hash with 'reset'
2014-01-16 19:22 ` Junio C Hamano
@ 2014-01-16 19:32 ` W. Trevor King
2014-01-16 20:24 ` Junio C Hamano
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 19:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
On Thu, Jan 16, 2014 at 11:22:52AM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
>
> > To preserve the local branch, for situations where we're not on a
> > detached HEAD.
> >
> > Signed-off-by: W. Trevor King <wking@tremily.us>
> > ---
>
> This should be a part of some other change that actually changes how
> this "git submodule update" checks out the submodule, no?
Sure, we can squash both this test fix and the subsequent new test
patch into patch #3 in v5. I was just splitting them out because
backwards compatibility was a concern, and separate patches makes it
easy for me to explain why the results changed here without getting
lost in patch #3's implementation details.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 3/6] submodule: Explicit local branch creation in module_clone
2014-01-16 4:10 ` [PATCH v4 3/6] submodule: Explicit local branch creation in module_clone W. Trevor King
2014-01-16 19:18 ` Junio C Hamano
@ 2014-01-16 19:43 ` Junio C Hamano
2014-01-16 21:12 ` W. Trevor King
1 sibling, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-16 19:43 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
"W. Trevor King" <wking@tremily.us> writes:
> @@ -817,11 +831,15 @@ cmd_update()
>
> displaypath=$(relative_path "$prefix$sm_path")
>
> - if test "$update_module" = "none"
> - then
> + case "$update_module" in
> + none)
> echo "Skipping submodule '$displaypath'"
> continue
> - fi
> + ;;
> + checkout)
> + local_branch=""
> + ;;
> + esac
I wonder if there is a way to avoid detaching (and you may need to
update the coddpath that resets the submodule to the commit
specified by the superproject tree) when it is safe to do so.
For an end user, running "submodule update" is similar to running
"git pull" in a project that does not use submodules, expressing "I
want to catch up with the work done by others". In a working tree
with local changes, we do allow you to run "git pull" as long as
your local changes do not overlap with the work done by others, and
the result of the pull would look as if you did not have any of the
local changes when you ran "git pull" and then you did the local
changes on top of the state that is up-to-date with their work.
Can't we design "submodule update --checkout" to work in a similar
fashion? The updated superproject may say it wants $oSHA-1 at a
submodule path P, and also its .gitmodules may say that commit is
supposed to be at the tip of branch B=submodule.P.branch in the
submodule repository. You may locally have advanced that branch in
your submodule repository in the meantime to point at $ySHA-1 while
others worked in the superproject and the submodule, and the
difference $oSHA-1...$ySHA-1 can be considered as the local change
made by you from the perspective of the superproject.
Without thinking things through, if $ySHA-1 matches or is a
descendant of $oSHA-1 (assuming that remote-tracking branch
origin/$B in the submodule does point at $oSHA-1 in either case), it
should be safe to do this update.
And in a situation where you cannot do the checkout safely, it is
perfectly fine to say "the submodules X and Y have local changes;
you cannot do 'submodule update' until you upstream them" and fail
the update, just like we fail a 'git pull' saying "you cannot do
pull until you commit them", no?
Perhaps that kind of "'git submodule update' is parallel to 'git
pull' in the project without submodules" is better done with other
update modes like --rebase or --merge. If so, how should we explain
what 'submodule update --checkout' is to the end users? Is it
supposed to be like "git fetch && git checkout origin/master"?
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 1/6] submodule: Make 'checkout' update_module explicit
2014-01-16 19:22 ` W. Trevor King
@ 2014-01-16 20:07 ` Francesco Pretto
2014-01-16 20:19 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Francesco Pretto @ 2014-01-16 20:07 UTC (permalink / raw)
To: W. Trevor King
Cc: Junio C Hamano, Git, Jens Lehmann, Heiko Voigt, Jonathan Nieder
2014/1/16 W. Trevor King <wking@tremily.us>:
> Avoiding useless clones is probably more important than avoiding
> duplicate "Invalid update mode" messages.
No, it's not duplicate code. I'll explain, please follow me:
> @@ -803,17 +803,10 @@ 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
> - *)
> - die "$(eval_gettext "Invalid update mode '$update_module' for submodule '$name'")"
> - ;;
> - esac
This is a *validation*. It's done before going more through the code
and die early.
> *)
> + die "$(eval_gettext "Invalid update mode '$update_module' for submodule '$name'")"
>
This should be an *assert* -> it means if you reach this case
statement you (programmer) have messed the code something in the code
before. In fact in my original patch I wrote something like "invalid
update_module at this flow".
Please keep both as Junio said.
Thanks,
Francesco
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 1/6] submodule: Make 'checkout' update_module explicit
2014-01-16 20:07 ` Francesco Pretto
@ 2014-01-16 20:19 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 20:19 UTC (permalink / raw)
To: Francesco Pretto
Cc: Junio C Hamano, Git, Jens Lehmann, Heiko Voigt, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]
On Thu, Jan 16, 2014 at 09:07:22PM +0100, Francesco Pretto wrote:
> 2014/1/16 W. Trevor King <wking@tremily.us>:
> > Avoiding useless clones is probably more important than avoiding
> > duplicate "Invalid update mode" messages.
>
> No, it's not duplicate code.
I meant “duplicating the "Invalid update mode" error message”. I
missed the die-early distinction, but I understand now. I think its
non-DRY to have an early case statement to validate the update_module,
and a later case statement to use it. Still, keeping those separate
statements in sync shouldn't be too hard ;).
> Please keep both as Junio said.
That's what I said I'd do in the email you're quoting ;). Are you ok
with the die-early validation checking all update_module settings
instead of just checking the loaded-from config branch?
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail
2014-01-16 4:10 ` [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail W. Trevor King
@ 2014-01-16 20:21 ` Junio C Hamano
2014-01-16 20:55 ` W. Trevor King
2014-01-16 22:18 ` [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail Philip Oakley
0 siblings, 2 replies; 144+ messages in thread
From: Junio C Hamano @ 2014-01-16 20:21 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
"W. Trevor King" <wking@tremily.us> writes:
> The old documentation did not distinguish between cloning and
> non-cloning updates and lacked clarity on which operations would lead
> to detached HEADs, and which would not. The new documentation
> addresses these issues while updating the docs to reflect the changes
> introduced by this branch's explicit local branch creation in
> module_clone.
>
> I also add '--checkout' to the usage summary and group the update-mode
> options into a single set.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/git-submodule.txt | 36 +++++++++++++++++++++++++++---------
> Documentation/gitmodules.txt | 4 ++++
> 2 files changed, 31 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index bfef8a0..02500b4 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -15,8 +15,8 @@ SYNOPSIS
> '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|--merge|--checkout] [--reference <repository>]
> + [--depth <depth>] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
> [commit] [--] [<path>...]
> 'git submodule' [--quiet] foreach [--recursive] <command>
> @@ -155,13 +155,31 @@ 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.
> + checkout the commit specified in the index of the containing
> + repository. The update mode defaults to 'checkout', but be
> + configured with the 'submodule.<name>.update' setting or the
> + '--rebase', '--merge', or 'checkout' options.
Not '--checkout'?
Other than that, the updated text above is far easier to
understand. Good job.
> ++
> +For updates that clone missing submodules, checkout-mode updates will
> +create submodules with detached HEADs; all other modes will create
> +submodules with a local branch named after 'submodule.<path>.branch'.
> ++
> +For updates that do not clone missing submodules, the submodule's HEAD
That is, updates that update submodules that are already checked out?
> +is only touched when the remote reference does not match the
> +submodule's HEAD (for none-mode updates, the submodule is never
> +touched). The remote reference is usually the gitlinked commit from
> +the superproject's tree, but with '--remote' it is the upstream
> +subproject's 'submodule.<name>.branch'. This remote reference is
> +integrated with the submodule's HEAD using the specified update mode.
I think copying some motivation from the log message of 06b1abb5
(submodule update: add --remote for submodule's upstream changes,
2012-12-19) would help the readers here. A naïve expectation from a
casual reader of the above would be "The superproject's tree ought
to point at the same commit as the tip of the branch used in the
submodule (modulo mirroring delays and somesuch), if the repository
of the superproject and submodules are maintained properly", which
would lead to "when would any sane person need to use --remote in
the first place???".
If I am reading 06b1abb5 correctly, the primary motivation behind
"--remote" seems to be that it is exactly to help the person who
wants to update superproject to satisify the "... are maintained
properly" part by fetching the latest in each of the submodules in
his superproject in preparation to 'git add .' them. I still do not
think "--remote" was a better way than the "foreach", but that is a
separate topic.
If the person who works in the superproject does not control the
progress of, and/or does not care what development is happening in,
the submodules, he can push the superproject tree out without even
bothering to update the commits in the submodules bound to his
superproject tree, and the consumers of such a superproject could
catch up with the advancement of submodule by using --remote
individually to bring themselves up to date. But I do not think
that is what you envisioned as the best recommended practice when
you wrote 06b1abb5.
> +For checkout-mode updates, that will result in a detached HEAD. For
> +rebase- and merge-mode updates, the commit referenced by the
> +submodule's HEAD may change, but the symbolic reference will remain
> +unchanged (i.e. checked-out branches will still be checked-out
> +branches, and detached HEADs will still be detached HEADs). If none
> +of the builtin modes fit your needs, set 'submodule.<name>.update' to
> +'!command' to configure a custom integration command. '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
> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
> index f7be93f..36e5447 100644
> --- a/Documentation/gitmodules.txt
> +++ b/Documentation/gitmodules.txt
> @@ -53,6 +53,10 @@ submodule.<name>.branch::
> A remote branch name for tracking updates in the upstream submodule.
> If the option is not specified, it defaults to 'master'. See the
> `--remote` documentation in linkgit:git-submodule[1] for details.
> ++
> +This branch name is also used for the local branch created by
> +non-checkout cloning updates. See the 'update' documentation in
> +linkgit:git-submodule[1] for details.
>
> submodule.<name>.fetchRecurseSubmodules::
> This option can be used to control recursive fetching of this
Other than the above minor nits, the updated text was very
readable. Thanks.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 4/6] t7406: Just-cloned checkouts update to the gitlinked hash with 'reset'
2014-01-16 19:32 ` W. Trevor King
@ 2014-01-16 20:24 ` Junio C Hamano
0 siblings, 0 replies; 144+ messages in thread
From: Junio C Hamano @ 2014-01-16 20:24 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
"W. Trevor King" <wking@tremily.us> writes:
> On Thu, Jan 16, 2014 at 11:22:52AM -0800, Junio C Hamano wrote:
>> "W. Trevor King" <wking@tremily.us> writes:
>>
>> > To preserve the local branch, for situations where we're not on a
>> > detached HEAD.
>> >
>> > Signed-off-by: W. Trevor King <wking@tremily.us>
>> > ---
>>
>> This should be a part of some other change that actually changes how
>> this "git submodule update" checks out the submodule, no?
>
> Sure, we can squash both this test fix and the subsequent new test
> patch into patch #3 in v5. I was just splitting them out because
> backwards compatibility was a concern, and separate patches makes it
> easy for me to explain why the results changed here without getting
> lost in patch #3's implementation details.
On the contrary, if we had this as part of patch #3, it would have
helped reviewing the patch itself, as that would have served as one
more clue to illustrate the effect that is externally visible to end
users.
Besides, having them separate will break bisection.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail
2014-01-16 20:21 ` Junio C Hamano
@ 2014-01-16 20:55 ` W. Trevor King
2014-01-16 21:02 ` John Keeping
2014-01-16 21:55 ` Junio C Hamano
2014-01-16 22:18 ` [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail Philip Oakley
1 sibling, 2 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 20:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 5175 bytes --]
On Thu, Jan 16, 2014 at 12:21:04PM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> > @@ -155,13 +155,31 @@ 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.
> > + checkout the commit specified in the index of the containing
> > + repository. The update mode defaults to 'checkout', but be
> > + configured with the 'submodule.<name>.update' setting or the
> > + '--rebase', '--merge', or 'checkout' options.
>
> Not '--checkout'?
Oops, will fix in v5.
> > ++
> > +For updates that clone missing submodules, checkout-mode updates will
> > +create submodules with detached HEADs; all other modes will create
> > +submodules with a local branch named after 'submodule.<path>.branch'.
> > ++
> > +For updates that do not clone missing submodules, the submodule's HEAD
>
> That is, updates that update submodules that are already checked out?
It's submodules for which $sm_path/.git does not exist.
> > +is only touched when the remote reference does not match the
> > +submodule's HEAD (for none-mode updates, the submodule is never
> > +touched). The remote reference is usually the gitlinked commit from
> > +the superproject's tree, but with '--remote' it is the upstream
> > +subproject's 'submodule.<name>.branch'. This remote reference is
> > +integrated with the submodule's HEAD using the specified update mode.
>
> I think copying some motivation from the log message of 06b1abb5
> (submodule update: add --remote for submodule's upstream changes,
> 2012-12-19) would help the readers here.
I think a brief reference to --remote is best here, mentioning that it
has something to do with the upstream subproject. More detail on when
you should use --remote should probably go under the docs for --remote
;).
> A naïve expectation from a casual reader of the above would be "The
> superproject's tree ought to point at the same commit as the tip of
> the branch used in the submodule (modulo mirroring delays and
> somesuch),
What is the branch used in the submodule? The remote subproject's
current submodule.<name>.branch? The local submodule's
submodule.<name>.branch (or localBranch) branch? The submodule's
current HEAD?
> if the repository of the superproject and submodules are maintained
> properly", which would lead to "when would any sane person need to
> use --remote in the first place???".
--remote is not for sane people (who will probably be pulling from
withing the submodule itself). --remote is for folks who track too
many submodules to care about them as individuals, who just want to
blindly update to whatever the upstream subproject maintainer has in
submodule.<name>.branch. For example, if you are a distribution with
a hundred submodules tracking all the projects you package, and want
to bump them all to a their current trunk tip in one fell swoop.
> If I am reading 06b1abb5 correctly, the primary motivation behind
> "--remote" seems to be that it is exactly to help the person who
> wants to update superproject to satisify the "... are maintained
> properly" part by fetching the latest in each of the submodules in
> his superproject in preparation to 'git add .' them. I still do not
> think "--remote" was a better way than the "foreach", but that is a
> separate topic.
I agree now ;), the problems with:
$ git submodule foreach 'git pull'
are:
1. You may not be on the “right” local branch to begin with, and
2. You may not have out-of-tree submodule configs setting up the
“right” upstream for that branch.
06b1abb did not address the former, and added a new .gitmodules-level
submodule.<name>.branch to help with the latter. I now think all of
this would be easier if we had automatic submodule local-branch
checkouts (fixing problem 1) and synchronized out-of-tree submodule
configs (fixing problem 2). Fixing problem 1 is all you need if you
aren't interested in sharing your out-of-tree configs.
I think 06b1abb was inspired by “we already have a way to integrate
changes in the gitlinked commit, we should reuse those to integrate
other changes”. In hindsight, changes in the gitlinked commit are
really a checkout-time issue, while changes in other places (like the
remote subproject) are pull-time issues. Mixing them together was
more confusing than it was worth.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail
2014-01-16 20:55 ` W. Trevor King
@ 2014-01-16 21:02 ` John Keeping
2014-01-16 21:16 ` W. Trevor King
2014-01-16 21:55 ` Junio C Hamano
1 sibling, 1 reply; 144+ messages in thread
From: John Keeping @ 2014-01-16 21:02 UTC (permalink / raw)
To: W. Trevor King
Cc: Junio C Hamano, Git, Jens Lehmann, Francesco Pretto, Heiko Voigt,
Jonathan Nieder
On Thu, Jan 16, 2014 at 12:55:21PM -0800, W. Trevor King wrote:
> On Thu, Jan 16, 2014 at 12:21:04PM -0800, Junio C Hamano wrote:
> > "W. Trevor King" <wking@tremily.us> writes:
> > > @@ -155,13 +155,31 @@ 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.
> > > + checkout the commit specified in the index of the containing
> > > + repository. The update mode defaults to 'checkout', but be
> > > + configured with the 'submodule.<name>.update' setting or the
> > > + '--rebase', '--merge', or 'checkout' options.
> >
> > Not '--checkout'?
>
> Oops, will fix in v5.
Shouldn't this also be `--checkout` (backticks), according to
CodingGuidelines. This applies to all this options in this patch I
think.
> > > ++
> > > +For updates that clone missing submodules, checkout-mode updates will
> > > +create submodules with detached HEADs; all other modes will create
> > > +submodules with a local branch named after 'submodule.<path>.branch'.
> > > ++
> > > +For updates that do not clone missing submodules, the submodule's HEAD
> >
> > That is, updates that update submodules that are already checked out?
>
> It's submodules for which $sm_path/.git does not exist.
>
> > > +is only touched when the remote reference does not match the
> > > +submodule's HEAD (for none-mode updates, the submodule is never
> > > +touched). The remote reference is usually the gitlinked commit from
> > > +the superproject's tree, but with '--remote' it is the upstream
> > > +subproject's 'submodule.<name>.branch'. This remote reference is
> > > +integrated with the submodule's HEAD using the specified update mode.
> >
> > I think copying some motivation from the log message of 06b1abb5
> > (submodule update: add --remote for submodule's upstream changes,
> > 2012-12-19) would help the readers here.
>
> I think a brief reference to --remote is best here, mentioning that it
> has something to do with the upstream subproject. More detail on when
> you should use --remote should probably go under the docs for --remote
> ;).
>
> > A naïve expectation from a casual reader of the above would be "The
> > superproject's tree ought to point at the same commit as the tip of
> > the branch used in the submodule (modulo mirroring delays and
> > somesuch),
>
> What is the branch used in the submodule? The remote subproject's
> current submodule.<name>.branch? The local submodule's
> submodule.<name>.branch (or localBranch) branch? The submodule's
> current HEAD?
>
> > if the repository of the superproject and submodules are maintained
> > properly", which would lead to "when would any sane person need to
> > use --remote in the first place???".
>
> --remote is not for sane people (who will probably be pulling from
> withing the submodule itself). --remote is for folks who track too
> many submodules to care about them as individuals, who just want to
> blindly update to whatever the upstream subproject maintainer has in
> submodule.<name>.branch. For example, if you are a distribution with
> a hundred submodules tracking all the projects you package, and want
> to bump them all to a their current trunk tip in one fell swoop.
>
> > If I am reading 06b1abb5 correctly, the primary motivation behind
> > "--remote" seems to be that it is exactly to help the person who
> > wants to update superproject to satisify the "... are maintained
> > properly" part by fetching the latest in each of the submodules in
> > his superproject in preparation to 'git add .' them. I still do not
> > think "--remote" was a better way than the "foreach", but that is a
> > separate topic.
>
> I agree now ;), the problems with:
>
> $ git submodule foreach 'git pull'
>
> are:
>
> 1. You may not be on the “right” local branch to begin with, and
> 2. You may not have out-of-tree submodule configs setting up the
> “right” upstream for that branch.
>
> 06b1abb did not address the former, and added a new .gitmodules-level
> submodule.<name>.branch to help with the latter. I now think all of
> this would be easier if we had automatic submodule local-branch
> checkouts (fixing problem 1) and synchronized out-of-tree submodule
> configs (fixing problem 2). Fixing problem 1 is all you need if you
> aren't interested in sharing your out-of-tree configs.
>
> I think 06b1abb was inspired by “we already have a way to integrate
> changes in the gitlinked commit, we should reuse those to integrate
> other changes”. In hindsight, changes in the gitlinked commit are
> really a checkout-time issue, while changes in other places (like the
> remote subproject) are pull-time issues. Mixing them together was
> more confusing than it was worth.
>
> Cheers,
> Trevor
>
> --
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 3/6] submodule: Explicit local branch creation in module_clone
2014-01-16 19:43 ` Junio C Hamano
@ 2014-01-16 21:12 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 21:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 3261 bytes --]
On Thu, Jan 16, 2014 at 11:43:44AM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
>
> > @@ -817,11 +831,15 @@ cmd_update()
> >
> > displaypath=$(relative_path "$prefix$sm_path")
> >
> > - if test "$update_module" = "none"
> > - then
> > + case "$update_module" in
> > + none)
> > echo "Skipping submodule '$displaypath'"
> > continue
> > - fi
> > + ;;
> > + checkout)
> > + local_branch=""
> > + ;;
> > + esac
>
> I wonder if there is a way to avoid detaching (and you may need to
> update the coddpath that resets the submodule to the commit
> specified by the superproject tree) when it is safe to do so.
>
> …
>
> Perhaps that kind of "'git submodule update' is parallel to 'git
> pull' in the project without submodules" is better done with other
> update modes like --rebase or --merge. If so, how should we explain
> what 'submodule update --checkout' is to the end users? Is it
> supposed to be like "git fetch && git checkout origin/master"?
It sounds like you're looking for:
submodule.<name>.update = !git merge --ff-only
That's fine for folks who want that sort of advancement, but I think
there will also be blind updaters who just want the gitlinked commit,
and don't care if that blows away local work, because they never work
locally in the submodule. They'll still prefer the current
checkout-mode with it's clobbering.
I think the best way to explain this to users is to have 'git
checkout' (with an optional '--recurse-submdules' trial period)
checkout the gitlinked commit automatically. Then there is never
local submodule work that is not committed or stashed in the
superproject (or stashed on some out-of-the-way branch in the
submodule). Currently we have:
1. Checkout a superproject branch and currently gitlinked submodule.
2. Do local work on the submodule.
3. Alter the superproject and its gitlinks.
4. 'git submodule update' to integrate your work from 2 with the
changes from 3 and checkout the appropriate submodule commit.
I think it would make more sense to:
1. Checkout a superproject branch and currently gitlinked submodule.
2. Do local work on the submodule.
3. Commit your new gitlink to the superproject (or stash it, or put
it on a temporary submodule branch and reset the submodule HEAD
to the old value).
4. Alter the superproject and its gitlinks, using the existing logic
to integrate conflicts. Automatically checkout the appropriate
submodule commit (as the appropriate submodule branch).
That shifts “dealing with local submodule changes” from an
integration-time issue (I just called submodule update, what changes
are local?) to a pre-checkout-time issue (I've got a dirty submodule
(it's HEAD is not the gitlinked commit, all of these changes are
local). I think that's a lot easier to wrap your head around.
This series is a stop-gap to avoid detached HEADs after cloning,
non-checkout updates, while we hash out the real solution ;).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail
2014-01-16 21:02 ` John Keeping
@ 2014-01-16 21:16 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 21:16 UTC (permalink / raw)
To: John Keeping
Cc: Junio C Hamano, Git, Jens Lehmann, Francesco Pretto, Heiko Voigt,
Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 772 bytes --]
On Thu, Jan 16, 2014 at 09:02:22PM +0000, John Keeping wrote:
> On Thu, Jan 16, 2014 at 12:55:21PM -0800, W. Trevor King wrote:
> > On Thu, Jan 16, 2014 at 12:21:04PM -0800, Junio C Hamano wrote:
> > > Not '--checkout'?
> >
> > Oops, will fix in v5.
>
> Shouldn't this also be `--checkout` (backticks), according to
> CodingGuidelines. This applies to all this options in this patch I
> think.
I can change that too. The existing content is inconsistent between
backticks and single quotes, but I see no mention of single quotes in
CodingGuidelines. Thanks for the reference.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail
2014-01-16 20:55 ` W. Trevor King
2014-01-16 21:02 ` John Keeping
@ 2014-01-16 21:55 ` Junio C Hamano
2014-01-17 2:37 ` W. Trevor King
1 sibling, 1 reply; 144+ messages in thread
From: Junio C Hamano @ 2014-01-16 21:55 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
"W. Trevor King" <wking@tremily.us> writes:
>> A naïve expectation from a casual reader of the above would be "The
>> superproject's tree ought to point at the same commit as the tip of
>> the branch used in the submodule (modulo mirroring delays and
>> somesuch),
>
> What is the branch used in the submodule? The remote subproject's
> current submodule.<name>.branch? The local submodule's
> submodule.<name>.branch (or localBranch) branch? The submodule's
> current HEAD?
They are good questions that such casual readers would have, and
giving answers to them in this part of the documentation would be a
good way to give them a clear picture of how the command is designed
to be used.
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail
2014-01-16 20:21 ` Junio C Hamano
2014-01-16 20:55 ` W. Trevor King
@ 2014-01-16 22:18 ` Philip Oakley
2014-01-16 22:35 ` W. Trevor King
1 sibling, 1 reply; 144+ messages in thread
From: Philip Oakley @ 2014-01-16 22:18 UTC (permalink / raw)
To: Junio C Hamano, W. Trevor King
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
From: "Junio C Hamano" <gitster@pobox.com>
> "W. Trevor King" <wking@tremily.us> writes:
>
[...]
>> @@ -155,13 +155,31 @@ 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.
>> + checkout the commit specified in the index of the containing
>> + repository. The update mode defaults to 'checkout', but be
nit: s/but be/but can be/ ?
>> + configured with the 'submodule.<name>.update' setting or the
>> + '--rebase', '--merge', or 'checkout' options.
>
[...]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail
2014-01-16 22:18 ` [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail Philip Oakley
@ 2014-01-16 22:35 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-16 22:35 UTC (permalink / raw)
To: Philip Oakley
Cc: Junio C Hamano, Git, Jens Lehmann, Francesco Pretto, Heiko Voigt,
Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
On Thu, Jan 16, 2014 at 10:18:06PM -0000, Philip Oakley wrote:
> From: "Junio C Hamano" <gitster@pobox.com>
> > "W. Trevor King" <wking@tremily.us> writes:
> >> + repository. The update mode defaults to 'checkout', but be
>
> nit: s/but be/but can be/ ?
Thanks. Queuing for v5.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail
2014-01-16 21:55 ` Junio C Hamano
@ 2014-01-17 2:37 ` W. Trevor King
2014-01-26 20:45 ` [PATCH v5 0/4] submodule: Local branch creation in module_clone W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-17 2:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Jens Lehmann, Francesco Pretto, Heiko Voigt, Jonathan Nieder
[-- Attachment #1: Type: text/plain, Size: 2321 bytes --]
On Thu, Jan 16, 2014 at 01:55:37PM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
> > On Thu, Jan 16, 2014 at 12:21:04PM -0800, Junio C Hamano wrote:
> >> "W. Trevor King" <wking@tremily.us> writes:
> >>> +is only touched when the remote reference does not match the
> >>> +submodule's HEAD (for none-mode updates, the submodule is never
> >>> +touched). The remote reference is usually the gitlinked commit from
> >>> +the superproject's tree, but with '--remote' it is the upstream
> >>> +subproject's 'submodule.<name>.branch'. This remote reference is
> >>> +integrated with the submodule's HEAD using the specified update mode.
> >> …
> >> A naïve expectation from a casual reader of the above would be
> >> "The superproject's tree ought to point at the same commit as the
> >> tip of the branch used in the submodule (modulo mirroring delays
> >> and somesuch),
> >
> > What is the branch used in the submodule? The remote subproject's
> > current submodule.<name>.branch? The local submodule's
> > submodule.<name>.branch (or localBranch) branch? The submodule's
> > current HEAD?
>
> They are good questions that such casual readers would have, and
> giving answers to them in this part of the documentation would be a
> good way to give them a clear picture of how the command is designed
> to be used.
How about:
Note that the update command only interacts with the submodule's
HEAD. It doesn't care what this head points to. If the submodule
has a branch checked out, HEAD will reference that branch. If the
submodule's HEAD is detached, it will reference a commit. After
following any references, the commit referenced by the submodule's
HEAD may resolve to the commit gitlinked by the superproject, or it
may not (if you have made local submodule changes, or checked out a
different superproject branch). The update command does not adjust
your submodule's HEAD to point at the gitlinked commit before
performing any integration. It just takes your submodle's HEAD,
whatever it points to, and integrates the remote reference.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
* [PATCH v5 0/4] submodule: Local branch creation in module_clone
2014-01-17 2:37 ` W. Trevor King
@ 2014-01-26 20:45 ` W. Trevor King
2014-01-26 20:45 ` [PATCH v5 1/4] submodule: Make 'checkout' update_module explicit W. Trevor King
` (3 more replies)
0 siblings, 4 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-26 20:45 UTC (permalink / raw)
To: Git
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, Philip Oakley, John Keeping, W. Trevor King
Changes since v4:
In git-submodule.sh:
* Explicitly set an empty $local_branch in cmd_add if $branch is empty
[1].
* Restore die-early checking for invalid $update_module [2]. This
check is now outside the load-from-config branch, ensuring we have a
valid update_module, regardless of how it was set.
In Documentation/git-submodule.txt:
* Fix “but be” → “but can be” [3].
* Fix “checkout” → “--checkout” [4].
* New text on why you'd use --remote [5] (new commit #4).
In Documentation/git-submodule.txt and Documentation/gitmodules.txt:
* Use backticks (instead of single quotes) for command line options
[6].
I also squashed the implementation, testing fixes, new tests, and
documentation for the new local_branch stuff (v4's #3, #4, #5, and #6)
into a single commit (v5's #3) [7].
[1]: http://article.gmane.org/gmane.comp.version-control.git/240524
[2]: http://article.gmane.org/gmane.comp.version-control.git/240522
[3]: http://article.gmane.org/gmane.comp.version-control.git/240543
[4]: http://article.gmane.org/gmane.comp.version-control.git/240531
[5]: http://article.gmane.org/gmane.comp.version-control.git/240529
[6]: http://article.gmane.org/gmane.comp.version-control.git/240536
[7]: http://article.gmane.org/gmane.comp.version-control.git/240530
W. Trevor King (4):
submodule: Make 'checkout' update_module explicit
submodule: Document module_clone arguments in comments
submodule: Explicit local branch creation in module_clone
Documentation: Describe 'submodule update --remote' use case
Documentation/git-submodule.txt | 46 ++++++++++++++++-----
Documentation/gitmodules.txt | 4 ++
git-submodule.sh | 89 ++++++++++++++++++++++++++---------------
t/t7406-submodule-update.sh | 39 +++++++++++++++++-
4 files changed, 136 insertions(+), 42 deletions(-)
--
1.8.5.2.8.g0f6c0d1
^ permalink raw reply [flat|nested] 144+ messages in thread
* [PATCH v5 1/4] submodule: Make 'checkout' update_module explicit
2014-01-26 20:45 ` [PATCH v5 0/4] submodule: Local branch creation in module_clone W. Trevor King
@ 2014-01-26 20:45 ` W. Trevor King
2014-01-27 1:32 ` Eric Sunshine
2014-01-26 20:45 ` [PATCH v5 2/4] submodule: Document module_clone arguments in comments W. Trevor King
` (2 subsequent siblings)
3 siblings, 1 reply; 144+ messages in thread
From: W. Trevor King @ 2014-01-26 20:45 UTC (permalink / raw)
To: Git
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, Philip Oakley, John Keeping, W. Trevor King
This avoids the current awkwardness of having either '' or 'checkout'
for checkout-mode updates, which makes testing for checkout-mode
updates (or non-checkout-mode updates) easier.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
git-submodule.sh | 27 +++++++++++----------------
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 5247f78..5e8776c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -803,17 +803,10 @@ 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
- *)
- die "$(eval_gettext "Invalid update mode '$update_module' for submodule '$name'")"
- ;;
- esac
+ if test -z "$update_module"
+ then
+ update_module="checkout"
+ fi
fi
displaypath=$(relative_path "$prefix$sm_path")
@@ -882,11 +875,16 @@ Maybe you want to use 'update --init'?")"
case ";$cloned_modules;" in
*";$name;"*)
# then there is no local change to integrate
- update_module= ;;
+ update_module=checkout ;;
esac
must_die_on_failure=
case "$update_module" in
+ checkout)
+ 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'")"
+ ;;
rebase)
command="git rebase"
die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$displaypath'")"
@@ -906,10 +904,7 @@ Maybe you want to use 'update --init'?")"
must_die_on_failure=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'")"
- ;;
+ die "$(eval_gettext "Invalid update mode '$update_module' for submodule '$name'")"
esac
if (clear_local_git_env; cd "$sm_path" && $command "$sha1")
--
1.8.5.2.8.g0f6c0d1
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v5 2/4] submodule: Document module_clone arguments in comments
2014-01-26 20:45 ` [PATCH v5 0/4] submodule: Local branch creation in module_clone W. Trevor King
2014-01-26 20:45 ` [PATCH v5 1/4] submodule: Make 'checkout' update_module explicit W. Trevor King
@ 2014-01-26 20:45 ` W. Trevor King
2014-01-26 20:45 ` [PATCH v5 3/4] submodule: Explicit local branch creation in module_clone W. Trevor King
2014-01-26 20:45 ` [PATCH v5 4/4] Documentation: Describe 'submodule update --remote' use case W. Trevor King
3 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-26 20:45 UTC (permalink / raw)
To: Git
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, Philip Oakley, John Keeping, W. Trevor King
Signed-off-by: W. Trevor King <wking@tremily.us>
---
git-submodule.sh | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/git-submodule.sh b/git-submodule.sh
index 5e8776c..68dcbe1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -241,6 +241,12 @@ module_name()
#
# Clone a submodule
#
+# $1 = submodule path
+# $2 = submodule name
+# $3 = URL to clone
+# $4 = reference repository to reuse (empty for independent)
+# $5 = depth argument for shallow clones (empty for deep)
+#
# Prior to calling, cmd_update checks that a possibly existing
# path is not a git repository.
# Likewise, cmd_add checks that path does not exist at all,
--
1.8.5.2.8.g0f6c0d1
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v5 3/4] submodule: Explicit local branch creation in module_clone
2014-01-26 20:45 ` [PATCH v5 0/4] submodule: Local branch creation in module_clone W. Trevor King
2014-01-26 20:45 ` [PATCH v5 1/4] submodule: Make 'checkout' update_module explicit W. Trevor King
2014-01-26 20:45 ` [PATCH v5 2/4] submodule: Document module_clone arguments in comments W. Trevor King
@ 2014-01-26 20:45 ` W. Trevor King
2014-01-26 20:45 ` [PATCH v5 4/4] Documentation: Describe 'submodule update --remote' use case W. Trevor King
3 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-26 20:45 UTC (permalink / raw)
To: Git
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, Philip Oakley, John Keeping, W. Trevor King
The previous code only checked out branches in cmd_add. This commit
moves the branch-checkout logic into module_clone, where it can be
shared by cmd_add and cmd_update. I also update the initial checkout
command to use 'reset' to preserve branches setup during module_clone.
With this change, folks cloning submodules for the first time via:
$ git submodule update ...
will get a local branch instead of a detached HEAD, unless they are
using the default checkout-mode updates. This is a change from the
previous situation where cmd_update always used checkout-mode logic
(regardless of the requested update mode) for updates that triggered
an initial clone, which always resulted in a detached HEAD.
This commit does not change the logic for updates after the initial
clone, which will continue to create detached HEADs for checkout-mode
updates, and integrate remote work with the local HEAD (detached or
not) in other modes.
The motivation for the change is that developers doing local work
inside the submodule are likely to select a non-checkout-mode for
updates so their local work is integrated with upstream work.
Developers who are not doing local submodule work stick with
checkout-mode updates so any apparently local work is blown away
during updates. For example, if upstream rolls back the remote branch
or gitlinked commit to an earlier version, the checkout-mode developer
wants their old submodule checkout to be rolled back as well, instead
of getting a no-op merge/rebase with the rolled-back reference.
By using the update mode to distinguish submodule developers from
black-box submodule consumers, we can setup local branches for the
developers who will want local branches, and stick with detached HEADs
for the developers that don't care.
Testing
=======
In t7406, just-cloned checkouts now update to the gitlinked hash with
'reset', to preserve the local branch for situations where we're not
on a detached HEAD.
I also added explicit tests to t7406 for HEAD attachement after
cloning updates, showing that it depends on their update mode:
* Checkout-mode updates get detached HEADs
* Everyone else gets a local branch, matching the configured
submodule.<name>.branch and defaulting to master.
The 'initial-setup' tag makes it easy to reset the superproject to a
known state, as several earlier tests commit to submodules and commit
the changed gitlinks to the superproject, but don't push the new
submodule commits to the upstream subprojects. This makes it
impossible to checkout the current super master, because it references
submodule commits that don't exist in the upstream subprojects. For a
specific example, see the tests that currently generate the
'two_new_submodule_commits' commits.
Documentation
=============
I updated the docs to describe the 'submodule update' modes in detail.
The old documentation did not distinguish between cloning and
non-cloning updates and lacked clarity on which operations would lead
to detached HEADs, and which would not. The new documentation
addresses these issues while updating the docs to reflect the changes
introduced by this commit's explicit local branch creation in
module_clone.
I also add '--checkout' to the usage summary and group the update-mode
options into a single set.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 36 ++++++++++++++++++-------
Documentation/gitmodules.txt | 4 +++
git-submodule.sh | 58 +++++++++++++++++++++++++++++------------
t/t7406-submodule-update.sh | 39 ++++++++++++++++++++++++++-
4 files changed, 110 insertions(+), 27 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index bfef8a0..2e1c7a2 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -15,8 +15,8 @@ SYNOPSIS
'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|--merge|--checkout] [--reference <repository>]
+ [--depth <depth>] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
[commit] [--] [<path>...]
'git submodule' [--quiet] foreach [--recursive] <command>
@@ -155,13 +155,31 @@ 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.
+ checkout the commit specified in the index of the containing
+ repository. The update mode defaults to `checkout`, but can be
+ configured with the `submodule.<name>.update` setting or the
+ `--rebase`, `--merge`, or `--checkout` options.
++
+For updates that clone missing submodules, checkout-mode updates will
+create submodules with detached HEADs; all other modes will create
+submodules with a local branch named after `submodule.<path>.branch`.
++
+For updates that do not clone missing submodules, the submodule's HEAD
+is only touched when the remote reference does not match the
+submodule's HEAD (for none-mode updates, the submodule is never
+touched). The remote reference is usually the gitlinked commit from
+the superproject's tree, but with `--remote` it is the upstream
+subproject's `submodule.<name>.branch`. This remote reference is
+integrated with the submodule's HEAD using the specified update mode.
+For checkout-mode updates, that will result in a detached HEAD. For
+rebase- and merge-mode updates, the commit referenced by the
+submodule's HEAD may change, but the symbolic reference will remain
+unchanged (i.e. checked-out branches will still be checked-out
+branches, and detached HEADs will still be detached HEADs). If none
+of the builtin modes fit your needs, set `submodule.<name>.update` to
+`!command` to configure a custom integration command. `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
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index f7be93f..385f35d 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -53,6 +53,10 @@ submodule.<name>.branch::
A remote branch name for tracking updates in the upstream submodule.
If the option is not specified, it defaults to 'master'. See the
`--remote` documentation in linkgit:git-submodule[1] for details.
++
+This branch name is also used for the local branch created by
+non-checkout cloning updates. See the `update` documentation in
+linkgit:git-submodule[1] for details.
submodule.<name>.fetchRecurseSubmodules::
This option can be used to control recursive fetching of this
diff --git a/git-submodule.sh b/git-submodule.sh
index 68dcbe1..626a746 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -246,6 +246,9 @@ module_name()
# $3 = URL to clone
# $4 = reference repository to reuse (empty for independent)
# $5 = depth argument for shallow clones (empty for deep)
+# $6 = (remote-tracking) starting point for the local branch (empty for HEAD)
+# $7 = local branch to create (empty for a detached HEAD, unless $6 is
+# also empty, in which case the local branch is left unchanged)
#
# Prior to calling, cmd_update checks that a possibly existing
# path is not a git repository.
@@ -259,6 +262,8 @@ module_clone()
url=$3
reference="$4"
depth="$5"
+ start_point="$6"
+ local_branch="$7"
quiet=
if test -n "$GIT_QUIET"
then
@@ -312,7 +317,16 @@ 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")
+ (
+ clear_local_git_env
+ cd "$sm_path" &&
+ GIT_WORK_TREE=. git config core.worktree "$rel/$b" &&
+ # ash fails to wordsplit ${local_branch:+-B "$local_branch"...}
+ case "$local_branch" in
+ '') git checkout -f -q ${start_point:+"$start_point"} ;;
+ ?*) git checkout -f -q -B "$local_branch" ${start_point:+"$start_point"} ;;
+ esac
+ ) || die "$(eval_gettext "Unable to setup cloned submodule '\$sm_path'")"
}
isnumber()
@@ -475,16 +489,15 @@ Use -f if you really want to add it." >&2
echo "$(eval_gettext "Reactivating local git directory for submodule '\$sm_name'.")"
fi
fi
- module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" || exit
- (
- clear_local_git_env
- cd "$sm_path" &&
- # ash fails to wordsplit ${branch:+-b "$branch"...}
- case "$branch" in
- '') git checkout -f -q ;;
- ?*) git checkout -f -q -B "$branch" "origin/$branch" ;;
- esac
- ) || die "$(eval_gettext "Unable to checkout submodule '\$sm_path'")"
+ if test -n "$branch"
+ then
+ start_point="origin/$branch"
+ local_branch="$branch"
+ else
+ start_point=""
+ local_branch=""
+ fi
+ module_clone "$sm_path" "$sm_name" "$realrepo" "$reference" "$depth" "$start_point" "$local_branch" || exit
fi
git config submodule."$sm_name".url "$realrepo"
@@ -803,7 +816,9 @@ cmd_update()
fi
name=$(module_name "$sm_path") || exit
url=$(git config submodule."$name".url)
- branch=$(get_submodule_config "$name" branch master)
+ config_branch=$(get_submodule_config "$name" branch)
+ branch="${config_branch:-master}"
+ local_branch="$branch"
if ! test -z "$update"
then
update_module=$update
@@ -817,11 +832,19 @@ cmd_update()
displaypath=$(relative_path "$prefix$sm_path")
- if test "$update_module" = "none"
- then
+ case "$update_module" in
+ none)
echo "Skipping submodule '$displaypath'"
continue
- fi
+ ;;
+ checkout)
+ local_branch=""
+ ;;
+ rebase | merge | !*)
+ ;;
+ *)
+ die "$(eval_gettext "Invalid update mode '$update_module' for submodule '$name'")"
+ esac
if test -z "$url"
then
@@ -835,7 +858,8 @@ Maybe you want to use 'update --init'?")"
if ! test -d "$sm_path"/.git -o -f "$sm_path"/.git
then
- module_clone "$sm_path" "$name" "$url" "$reference" "$depth" || exit
+ start_point="origin/${branch}"
+ module_clone "$sm_path" "$name" "$url" "$reference" "$depth" "$start_point" "$local_branch" || exit
cloned_modules="$cloned_modules;$name"
subsha1=
else
@@ -881,7 +905,7 @@ Maybe you want to use 'update --init'?")"
case ";$cloned_modules;" in
*";$name;"*)
# then there is no local change to integrate
- update_module=checkout ;;
+ update_module='!git reset --hard -q'
esac
must_die_on_failure=
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 0825a92..f056c01 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -63,6 +63,9 @@ test_expect_success 'setup a submodule tree' '
git submodule add ../none none &&
test_tick &&
git commit -m "none"
+ ) &&
+ (cd super &&
+ git tag initial-setup
)
'
@@ -703,7 +706,7 @@ test_expect_success 'submodule update places git-dir in superprojects git-dir re
git clone super_update_r super_update_r2 &&
(cd super_update_r2 &&
git submodule update --init --recursive >actual &&
- test_i18ngrep "Submodule path .submodule/subsubmodule.: checked out" actual &&
+ test_i18ngrep "Submodule path .submodule/subsubmodule.: .git reset --hard -q" actual &&
(cd submodule/subsubmodule &&
git log > ../../expected
) &&
@@ -764,4 +767,38 @@ test_expect_success 'submodule update clone shallow submodule' '
)
)
'
+
+test_expect_success 'submodule update --checkout clones detached HEAD' '
+ git clone super super4 &&
+ echo "detached HEAD" >expected &&
+ (cd super4 &&
+ git reset --hard initial-setup &&
+ git submodule init submodule &&
+ git submodule update >> /tmp/log 2>&1 &&
+ (cd submodule &&
+ git symbolic-ref HEAD > ../../actual ||
+ echo "detached HEAD" > ../../actual
+ )
+ ) &&
+ test_cmp actual expected &&
+ rm -rf super4
+'
+
+test_expect_success 'submodule update --merge clones attached HEAD' '
+ git clone super super4 &&
+ echo "refs/heads/master" >expected &&
+ (cd super4 &&
+ git reset --hard initial-setup &&
+ git submodule init submodule &&
+ git config submodule.submodule.update merge &&
+ git submodule update --merge &&
+ (cd submodule &&
+ git symbolic-ref HEAD > ../../actual ||
+ echo "detached HEAD" > ../../actual
+ )
+ ) &&
+ test_cmp actual expected &&
+ rm -rf super4
+'
+
test_done
--
1.8.5.2.8.g0f6c0d1
^ permalink raw reply related [flat|nested] 144+ messages in thread
* [PATCH v5 4/4] Documentation: Describe 'submodule update --remote' use case
2014-01-26 20:45 ` [PATCH v5 0/4] submodule: Local branch creation in module_clone W. Trevor King
` (2 preceding siblings ...)
2014-01-26 20:45 ` [PATCH v5 3/4] submodule: Explicit local branch creation in module_clone W. Trevor King
@ 2014-01-26 20:45 ` W. Trevor King
3 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-26 20:45 UTC (permalink / raw)
To: Git
Cc: Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, Philip Oakley, John Keeping, W. Trevor King
On Thu, Jan 16, 2014 at 12:21:04PM -0800, Junio C Hamano wrote [1]:
> I think copying some motivation from the log message of 06b1abb5
> (submodule update: add --remote for submodule's upstream changes,
> 2012-12-19) would help the readers here. A naïve expectation from a
> casual reader of the above would be "The superproject's tree ought
> to point at the same commit as the tip of the branch used in the
> submodule (modulo mirroring delays and somesuch), if the repository
> of the superproject and submodules are maintained properly", which
> would lead to "when would any sane person need to use --remote in
> the first place???".
There have been other interpretation issues with the --remote option
as well. With this commit, I try to make it clear that there is no
implicit floating going on; --remote lets you explicitly integrate the
upstream branch in your current HEAD (just like running 'git pull' in
the submodule). The only distinction with the current 'git pull' is
the config location/setting used for the upstream branch, which is
hopefully clear now.
With syncing between the out-of-tree submodule config and the in-tree
superproject .gitmodules [2], you wouldn't have to chose between (or
manually sync) "easily distributable .gitmodules settings" and "native
submodule pull", but this patch is my take on the current situation.
[1]: http://article.gmane.org/gmane.comp.version-control.git/240529
[2]: http://article.gmane.org/gmane.comp.version-control.git/240336
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 2e1c7a2..21cb59a 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -299,6 +299,16 @@ In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. If you don't want to fetch, you should use `submodule update
--remote --no-fetch`.
++
+Use this option to integrate changes from the upstream subproject with
+your submodule's current HEAD. Alternatively, you can run `git pull`
+from the submodule, which is equivalent except for the remote branch
+name: `update --remote` uses the default upstream repository and
+`submodule.<name>.branch`, while `git pull` uses the submodule's
+`branch.<name>.merge`. Prefer `submodule.<name>.branch` if you want
+to distribute the default upstream branch with the superproject and
+`branch.<name>.merge` if you want a more native feel while working in
+the submodule itself.
-N::
--no-fetch::
--
1.8.5.2.8.g0f6c0d1
^ permalink raw reply related [flat|nested] 144+ messages in thread
* Re: [PATCH v5 1/4] submodule: Make 'checkout' update_module explicit
2014-01-26 20:45 ` [PATCH v5 1/4] submodule: Make 'checkout' update_module explicit W. Trevor King
@ 2014-01-27 1:32 ` Eric Sunshine
2014-01-27 1:59 ` W. Trevor King
0 siblings, 1 reply; 144+ messages in thread
From: Eric Sunshine @ 2014-01-27 1:32 UTC (permalink / raw)
To: W. Trevor King
Cc: Git, Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, Philip Oakley, John Keeping
On Sun, Jan 26, 2014 at 3:45 PM, W. Trevor King <wking@tremily.us> wrote:
> This avoids the current awkwardness of having either '' or 'checkout'
> for checkout-mode updates, which makes testing for checkout-mode
> updates (or non-checkout-mode updates) easier.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> git-submodule.sh | 27 +++++++++++----------------
> 1 file changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 5247f78..5e8776c 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -803,17 +803,10 @@ 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
> - *)
> - die "$(eval_gettext "Invalid update mode '$update_module' for submodule '$name'")"
> - ;;
> - esac
> + if test -z "$update_module"
> + then
> + update_module="checkout"
Here, you (unnecessarily) quote 'checkout'...
> + fi
> fi
>
> displaypath=$(relative_path "$prefix$sm_path")
> @@ -882,11 +875,16 @@ Maybe you want to use 'update --init'?")"
> case ";$cloned_modules;" in
> *";$name;"*)
> # then there is no local change to integrate
> - update_module= ;;
> + update_module=checkout ;;
But here you use bare (unquoted) 'checkout'. Bare is probably more idiomatic.
> esac
>
> must_die_on_failure=
> case "$update_module" in
> + checkout)
> + 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'")"
> + ;;
> rebase)
> command="git rebase"
> die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$displaypath'")"
> @@ -906,10 +904,7 @@ Maybe you want to use 'update --init'?")"
> must_die_on_failure=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'")"
> - ;;
> + die "$(eval_gettext "Invalid update mode '$update_module' for submodule '$name'")"
> esac
>
> if (clear_local_git_env; cd "$sm_path" && $command "$sha1")
> --
> 1.8.5.2.8.g0f6c0d1
^ permalink raw reply [flat|nested] 144+ messages in thread
* Re: [PATCH v5 1/4] submodule: Make 'checkout' update_module explicit
2014-01-27 1:32 ` Eric Sunshine
@ 2014-01-27 1:59 ` W. Trevor King
0 siblings, 0 replies; 144+ messages in thread
From: W. Trevor King @ 2014-01-27 1:59 UTC (permalink / raw)
To: Eric Sunshine
Cc: Git, Jens Lehmann, Francesco Pretto, Junio C Hamano, Heiko Voigt,
Jonathan Nieder, Philip Oakley, John Keeping
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]
On Sun, Jan 26, 2014 at 08:32:04PM -0500, Eric Sunshine wrote:
> On Sun, Jan 26, 2014 at 3:45 PM, W. Trevor King <wking@tremily.us> wrote:
> > + update_module="checkout"
>
> Here, you (unnecessarily) quote 'checkout'...
>
> > - update_module= ;;
> > + update_module=checkout ;;
>
> But here you use bare (unquoted) 'checkout'. Bare is probably more
> idiomatic.
Whatever you want ;). Queued for v6.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 144+ messages in thread
end of thread, other threads:[~2014-01-27 2:00 UTC | newest]
Thread overview: 144+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-30 1:49 [PATCH/RFC] Introduce git submodule add|update --attach Francesco Pretto
2013-12-31 20:05 ` Phil Hord
2014-01-02 18:48 ` Francesco Pretto
2014-01-13 17:31 ` Junio C Hamano
2014-01-02 20:07 ` Junio C Hamano
2014-01-02 23:42 ` Francesco Pretto
2014-01-03 0:26 ` Francesco Pretto
2014-01-03 8:49 ` Francesco Pretto
2014-01-03 18:06 ` [PATCH] submodule: Respect reqested branch on all clones W. Trevor King
2014-01-04 22:09 ` Heiko Voigt
2014-01-04 22:54 ` W. Trevor King
2014-01-05 0:39 ` Heiko Voigt
2014-01-05 1:08 ` W. Trevor King
2014-01-05 3:53 ` Francesco Pretto
2014-01-05 16:17 ` [RFC v2] submodule: Respect requested " W. Trevor King
2014-01-05 19:48 ` Heiko Voigt
2014-01-05 21:24 ` W. Trevor King
2014-01-05 22:57 ` Heiko Voigt
2014-01-05 23:39 ` W. Trevor King
2014-01-06 0:33 ` W. Trevor King
2014-01-06 1:12 ` W. Trevor King
2014-01-06 16:02 ` Heiko Voigt
2014-01-06 23:10 ` Francesco Pretto
2014-01-06 23:32 ` Francesco Pretto
2014-01-07 18:27 ` Junio C Hamano
2014-01-07 19:19 ` Francesco Pretto
2014-01-07 19:45 ` W. Trevor King
2014-01-07 19:48 ` Francesco Pretto
2014-01-07 21:37 ` W. Trevor King
2014-01-07 21:51 ` Francesco Pretto
2014-01-07 22:38 ` Heiko Voigt
2014-01-08 0:17 ` Francesco Pretto
2014-01-08 1:05 ` W. Trevor King
2014-01-08 2:12 ` Francesco Pretto
2014-01-08 23:07 ` Francesco Pretto
2014-01-09 0:03 ` W. Trevor King
2014-01-09 1:09 ` Francesco Pretto
2014-01-09 2:22 ` W. Trevor King
2014-01-09 8:31 ` Jens Lehmann
2014-01-09 17:32 ` W. Trevor King
2014-01-09 19:23 ` Jens Lehmann
2014-01-09 19:55 ` W. Trevor King
2014-01-09 21:40 ` Jens Lehmann
2014-01-09 22:18 ` W. Trevor King
2014-01-14 10:24 ` Heiko Voigt
2014-01-14 16:57 ` W. Trevor King
2014-01-14 20:58 ` Heiko Voigt
2014-01-14 21:42 ` W. Trevor King
2014-01-14 22:19 ` Heiko Voigt
2014-01-14 22:39 ` W. Trevor King
2014-01-14 21:46 ` Re: " Heiko Voigt
2014-01-14 22:22 ` W. Trevor King
2014-01-14 22:42 ` Heiko Voigt
2014-01-15 0:02 ` Francesco Pretto
2014-01-16 4:09 ` [PATCH v4 0/6] submodule: Local branch creation in module_clone W. Trevor King
2014-01-16 4:10 ` [PATCH v4 1/6] submodule: Make 'checkout' update_module explicit W. Trevor King
2014-01-16 18:46 ` Junio C Hamano
2014-01-16 19:22 ` W. Trevor King
2014-01-16 20:07 ` Francesco Pretto
2014-01-16 20:19 ` W. Trevor King
2014-01-16 4:10 ` [PATCH v4 2/6] submodule: Document module_clone arguments in comments W. Trevor King
2014-01-16 4:10 ` [PATCH v4 3/6] submodule: Explicit local branch creation in module_clone W. Trevor King
2014-01-16 19:18 ` Junio C Hamano
2014-01-16 19:29 ` W. Trevor King
2014-01-16 19:43 ` Junio C Hamano
2014-01-16 21:12 ` W. Trevor King
2014-01-16 4:10 ` [PATCH v4 4/6] t7406: Just-cloned checkouts update to the gitlinked hash with 'reset' W. Trevor King
2014-01-16 19:22 ` Junio C Hamano
2014-01-16 19:32 ` W. Trevor King
2014-01-16 20:24 ` Junio C Hamano
2014-01-16 4:10 ` [PATCH v4 5/6] t7406: Add explicit tests for head attachement after cloning updates W. Trevor King
2014-01-16 4:10 ` [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail W. Trevor King
2014-01-16 20:21 ` Junio C Hamano
2014-01-16 20:55 ` W. Trevor King
2014-01-16 21:02 ` John Keeping
2014-01-16 21:16 ` W. Trevor King
2014-01-16 21:55 ` Junio C Hamano
2014-01-17 2:37 ` W. Trevor King
2014-01-26 20:45 ` [PATCH v5 0/4] submodule: Local branch creation in module_clone W. Trevor King
2014-01-26 20:45 ` [PATCH v5 1/4] submodule: Make 'checkout' update_module explicit W. Trevor King
2014-01-27 1:32 ` Eric Sunshine
2014-01-27 1:59 ` W. Trevor King
2014-01-26 20:45 ` [PATCH v5 2/4] submodule: Document module_clone arguments in comments W. Trevor King
2014-01-26 20:45 ` [PATCH v5 3/4] submodule: Explicit local branch creation in module_clone W. Trevor King
2014-01-26 20:45 ` [PATCH v5 4/4] Documentation: Describe 'submodule update --remote' use case W. Trevor King
2014-01-16 22:18 ` [PATCH v4 6/6] Documentation: Describe 'submodule update' modes in detail Philip Oakley
2014-01-16 22:35 ` W. Trevor King
2014-01-08 23:54 ` Re: [RFC v2] submodule: Respect requested branch on all clones Francesco Pretto
2014-01-09 0:23 ` W. Trevor King
2014-01-07 19:52 ` Francesco Pretto
2014-01-06 15:47 ` Re: " Heiko Voigt
2014-01-06 17:22 ` W. Trevor King
2014-01-05 21:27 ` Francesco Pretto
2014-01-05 21:47 ` W. Trevor King
2014-01-05 22:01 ` W. Trevor King
2014-01-06 14:47 ` Heiko Voigt
2014-01-06 16:56 ` Junio C Hamano
2014-01-06 17:37 ` W. Trevor King
2014-01-06 21:32 ` Junio C Hamano
2014-01-07 0:55 ` Francesco Pretto
2014-01-07 18:15 ` Junio C Hamano
2014-01-07 18:47 ` W. Trevor King
2014-01-07 19:21 ` Junio C Hamano
2014-01-07 19:50 ` W. Trevor King
2014-01-05 2:50 ` [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command Francesco Pretto
2014-01-05 2:50 ` [PATCH 2/2] Introduce git submodule attached update Francesco Pretto
2014-01-05 19:55 ` Francesco Pretto
2014-01-05 20:33 ` Heiko Voigt
2014-01-05 21:46 ` Francesco Pretto
2014-01-06 14:06 ` Heiko Voigt
2014-01-06 17:47 ` Francesco Pretto
2014-01-06 19:21 ` David Engster
2014-01-07 19:27 ` W. Trevor King
2014-01-07 4:10 ` W. Trevor King
2014-01-07 22:36 ` Preferred local submodule branches (was: Introduce git submodule attached update) W. Trevor King
2014-01-07 23:52 ` W. Trevor King
2014-01-08 3:47 ` Preferred local submodule branches W. Trevor King
2014-01-08 4:06 ` W. Trevor King
2014-01-09 6:17 ` [RFC v3 0/4] " W. Trevor King
2014-01-09 6:17 ` [RFC v3 1/4] submodule: Add helpers for configurable local branches W. Trevor King
2014-01-09 6:17 ` [RFC v3 2/4] submodule: Teach 'update' to preserve " W. Trevor King
2014-01-09 6:17 ` [RFC v3 3/4] submodule: Teach 'add' about a configurable local-branch W. Trevor King
2014-01-15 0:18 ` Francesco Pretto
2014-01-15 1:02 ` W. Trevor King
2014-01-09 6:17 ` [RFC v3 4/4] submodule: Add a new 'checkout' command W. Trevor King
2014-01-12 1:08 ` Tight submodule bindings (was: Preferred local submodule branches) W. Trevor King
2014-01-13 19:37 ` Tight submodule bindings Jens Lehmann
2014-01-13 20:07 ` W. Trevor King
2014-01-13 22:13 ` Junio C Hamano
2014-01-14 2:44 ` W. Trevor King
2014-01-07 22:51 ` Re: [PATCH 2/2] Introduce git submodule attached update Heiko Voigt
2014-01-07 23:14 ` W. Trevor King
2014-01-07 18:56 ` Junio C Hamano
2014-01-07 19:44 ` Francesco Pretto
2014-01-07 19:07 ` Junio C Hamano
2014-01-07 19:25 ` Francesco Pretto
2014-01-05 23:22 ` Francesco Pretto
2014-01-06 14:18 ` Heiko Voigt
2014-01-06 15:58 ` W. Trevor King
2014-01-05 20:20 ` [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command Heiko Voigt
2014-01-05 20:44 ` W. Trevor King
2014-01-06 16:20 ` Junio C Hamano
2014-01-06 17:42 ` Junio C Hamano
2014-01-06 17:52 ` Francesco Pretto
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.