{"thread":{"id":"32045","subject":"[PATCH v3 1/3] git-submodule add: Add -r/--record option","startedAt":"2012-11-09T03:35:11Z","lastAt":"2012-11-29T18:51:25Z","messageCount":49,"participants":["W. Trevor King","Junio C Hamano","Heiko Voigt","Sascha Cunz","Jens Lehmann","Phil Hord"],"isPatch":true,"patchVersion":3,"patchTotal":3},"messages":[{"id":"202681","messageId":"cover.1352431674.git.wking@tremily.us","threadId":"32045","inReplyTo":"20121029222759.GI20513@sigill.intra.peff.net","subject":"[PATCH v3 0/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-09T03:35:11Z","receivedAt":"2012-11-09T03:35:11Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nHere's my revised patch. Changes from v2:\n\n* Revised Ævar-vs-Gerrit usage to show agreement, following Shawn's\n comments.\n* Added a cleaned up version of Phil's $submodule_* export patch, with\n docs and tests.\n* Added a caveat to the -r/--record documentation to make it explicit\n that submodule..branch is not used internally by Git. Give an\n example of how the user may use it explicitly for Ævar-style\n updates.\n\nW. Trevor King (3):\n git-submodule add: Add -r/--record option\n git-submodule foreach: export .gitmodules settings as variables\n git-submodule: Motivate --record with an example use case\n\n Documentation/git-submodule.txt | 22 +++++++++++++++++++++-\n git-sh-setup.sh | 20 ++++++++++++++++++++\n git-submodule.sh | 35 ++++++++++++++++++++++++++++++++++-\n t/t7400-submodule-basic.sh | 25 +++++++++++++++++++++++++\n t/t7407-submodule-foreach.sh | 29 +++++++++++++++++++++++++++++\n 5 files changed, 129 insertions(+), 2 deletions(-)\n mode change 100644 => 100755 git-sh-setup.sh\n\n-- \n1.8.0.3.gc2eb43a\n"},{"id":"202679","messageId":"fb2d915cf60160c200b84df88c6112c1c2d4eefd.1352431674.git.wking@tremily.us","threadId":"32045","inReplyTo":"cover.1352431674.git.wking@tremily.us","subject":"[PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-09T03:35:12Z","receivedAt":"2012-11-09T03:35:12Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nThis option allows you to record a submodule..branch option in\n.gitmodules. Git does not currently use this configuration option for\nanything, but users have used it for several things, so it makes sense\nto add some syntactic sugar for initializing the value.\n\nCurrent consumers:\n\nÆvar uses this setting to designate the upstream branch for pulling\nsubmodule updates:\n\n $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n\nas he describes in\n\n commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f\n Author: Ævar Arnfjörð Bjarmason \n Date: Fri May 21 16:10:10 2010 +0000\n\n git-submodule foreach: Add $toplevel variable\n\nGerrit uses the same interpretation for the setting, but because\nGerrit has direct access to the subproject repositories, it updates\nthe superproject repositories automatically when a subproject changes.\nGerrit also accepts the special value '.', which it expands into the\nsuperproject's branch name.\n\nBy remaining agnostic on the variable usage, this patch makes\nsubmodule setup more convenient for all parties.\n\n[1] https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt\n\nSigned-off-by: W. Trevor King \n---\n Documentation/git-submodule.txt | 11 ++++++++++-\n git-submodule.sh | 19 ++++++++++++++++++-\n t/t7400-submodule-basic.sh | 25 +++++++++++++++++++++++++\n 3 files changed, 53 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex b4683bb..cbec363 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules\n SYNOPSIS\n --------\n [verse]\n-'git submodule' [--quiet] add [-b branch] [-f|--force]\n+'git submodule' [--quiet] add [-b branch] [--record[=]] [-f|--force]\n \t [--reference ] [--] []\n 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]\n 'git submodule' [--quiet] init [--] [...]\n@@ -209,6 +209,15 @@ OPTIONS\n --branch::\n \tBranch of repository to add as submodule.\n \n+-r::\n+--record::\n+\tRecord a branch name used as `submodule..branch` in\n+\t`.gitmodules` for future reference. If you do not list an explicit\n+\tname here, the name given with `--branch` will be recorded. If that\n+\tis not set either, `HEAD` will be recorded. Because the branch name\n+\tis optional, you must use the equal-sign form (`-r=`), not\n+\t`-r `.\n+\n -f::\n --force::\n \tThis option is only valid for add and update commands.\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex ab6b110..bc33112 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -5,7 +5,7 @@\n # Copyright (c) 2007 Lars Hjemli\n \n dashless=$(basename \"$0\" | sed -e 's/-/ /')\n-USAGE=\"[--quiet] add [-b branch] [-f|--force] [--reference ] [--] []\n+USAGE=\"[--quiet] add [-b branch] [--record[=]] [-f|--force] [--reference ] [--] []\n or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]\n or: $dashless [--quiet] init [--] [...]\n or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n@@ -20,6 +20,8 @@ require_work_tree\n \n command=\n branch=\n+record_branch=\n+record_branch_empty=\n force=\n reference=\n cached=\n@@ -257,6 +259,12 @@ cmd_add()\n \t\t\tbranch=$2\n \t\t\tshift\n \t\t\t;;\n+\t\t-r | --record)\n+\t\t\trecord_branch_empty=true\n+\t\t\t;;\n+\t\t-r=* | --record=*)\n+\t\t\trecord_branch=\"${1#*=}\"\n+\t\t\t;;\n \t\t-f | --force)\n \t\t\tforce=$1\n \t\t\t;;\n@@ -328,6 +336,11 @@ cmd_add()\n \tgit ls-files --error-unmatch \"$sm_path\" > /dev/null 2>&1 &&\n \tdie \"$(eval_gettext \"'\\$sm_path' already exists in the index\")\"\n \n+\tif test -z \"$record_branch\" && test \"$record_branch_empty\" = \"true\"\n+\tthen\n+\t\trecord_branch=\"${branch:=HEAD}\"\n+\tfi\n+\n \tif test -z \"$force\" && ! git add --dry-run --ignore-missing \"$sm_path\" > /dev/null 2>&1\n \tthen\n \t\teval_gettextln \"The following path is ignored by one of your .gitignore files:\n@@ -366,6 +379,10 @@ Use -f if you really want to add it.\" >&2\n \n \tgit config -f .gitmodules submodule.\"$sm_path\".path \"$sm_path\" &&\n \tgit config -f .gitmodules submodule.\"$sm_path\".url \"$repo\" &&\n+\tif test -n \"$branch\"\n+\tthen\n+\t\tgit config -f .gitmodules submodule.\"$sm_path\".branch \"$record_branch\"\n+\tfi &&\n \tgit add --force .gitmodules ||\n \tdie \"$(eval_gettext \"Failed to register submodule '\\$sm_path'\")\"\n }\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex 5397037..88ae74c 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -133,6 +133,7 @@ test_expect_success 'submodule add --branch' '\n \t(\n \t\tcd addtest &&\n \t\tgit submodule add -b initial \"$submodurl\" submod-branch &&\n+\t\ttest -z \"$(git config -f .gitmodules submodule.submod-branch.branch)\" &&\n \t\tgit submodule init\n \t) &&\n \n@@ -211,6 +212,30 @@ test_expect_success 'submodule add with ./, /.. and // in path' '\n \ttest_cmp empty untracked\n '\n \n+test_expect_success 'submodule add --record' '\n+\t(\n+\t\tcd addtest &&\n+\t\tgit submodule add -r \"$submodurl\" submod-record-head &&\n+\t\ttest \"$(git config -f .gitmodules submodule.submod-record-head.branch)\" = \"HEAD\"\n+\t)\n+'\n+\n+test_expect_success 'submodule add --record --branch' '\n+\t(\n+\t\tcd addtest &&\n+\t\tgit submodule add -r -b initial \"$submodurl\" submod-auto-record &&\n+\t\ttest \"$(git config -f .gitmodules submodule.submod-auto-record.branch)\" = \"initial\"\n+\t)\n+'\n+\n+test_expect_success 'submodule add --record= --branch' '\n+\t(\n+\t\tcd addtest &&\n+\t\tgit submodule add -r=final -b initial \"$submodurl\" submod-record &&\n+\t\ttest \"$(git config -f .gitmodules submodule.submod-record.branch)\" = \"final\"\n+\t)\n+'\n+\n test_expect_success 'setup - add an example entry to .gitmodules' '\n \tGIT_CONFIG=.gitmodules \\\n \tgit config submodule.example.url git://example.com/init.git\n-- \n1.8.0.3.gc2eb43a\n"},{"id":"202683","messageId":"2121ce36cf4eb02385255cbd5b0bbd1dcc803113.1352431675.git.wking@tremily.us","threadId":"32045","inReplyTo":"cover.1352431674.git.wking@tremily.us","subject":"[PATCH v3 2/3] git-submodule foreach: export .gitmodules settings as variables","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-09T03:35:13Z","receivedAt":"2012-11-09T03:35:13Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nThis makes it easy to access per-submodule variables. For example,\n\n git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n\ncan now be reduced to\n\n git submodule foreach 'git checkout $submodule_branch && git pull'\n\nEvery submodule.. setting from .gitmodules is available as\na $submodule_ variable. These variables are not\npropagated recursively into nested submodules.\n\nSigned-off-by: W. Trevor King \nBased-on-patch-by: Phil Hord \n---\n Documentation/git-submodule.txt | 3 +++\n git-sh-setup.sh | 20 ++++++++++++++++++++\n git-submodule.sh | 16 ++++++++++++++++\n t/t7407-submodule-foreach.sh | 29 +++++++++++++++++++++++++++++\n 4 files changed, 68 insertions(+)\n mode change 100644 => 100755 git-sh-setup.sh\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex cbec363..9a99826 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -175,6 +175,9 @@ foreach::\n \t$path is the name of the submodule directory relative to the\n \tsuperproject, $sha1 is the commit as recorded in the superproject,\n \tand $toplevel is the absolute path to the top-level of the superproject.\n+\tIn addition, every submodule.. setting from .gitmodules\n+\tis available as the variable $submodule_. These\n+\tvariables are not propagated recursively into nested submodules.\n \tAny submodules defined in the superproject but not checked out are\n \tignored by this command. Unless given `--quiet`, foreach prints the name\n \tof each submodule before evaluating the command.\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nold mode 100644\nnew mode 100755\nindex ee0e0bc..179a920\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -222,6 +222,26 @@ clear_local_git_env() {\n \tunset $(git rev-parse --local-env-vars)\n }\n \n+# Remove any suspect characters from a user-generated variable name.\n+sanitize_variable_name() {\n+\tVAR_NAME=\"$1\"\n+\tprintf '%s' \"$VAR_NAME\" |\n+\tsed -e 's/^[^a-zA-Z]/_/' -e 's/[^a-zA-Z0-9]/_/g'\n+}\n+\n+# Return a command for setting a new variable.\n+# Neither the variable name nor the variable value passed to this\n+# function need to be sanitized. You need to eval the returned\n+# string, because new variables set by the function itself don't\n+# effect the calling process.\n+set_user_variable() {\n+\tVAR_NAME=\"$1\"\n+\tVAR_VALUE=\"$2\"\n+\tVAR_NAME=$(sanitize_variable_name \"$VAR_NAME\")\n+\tVAR_VALUE=$(printf '%s' \"$VAR_VALUE\" |\n+\t\tsed -e 's/\\\\/\\\\\\\\/g' -e 's/\"/\\\\\"/g')\n+\tprintf '%s=%s;\\n' \"$VAR_NAME\" \"\\\"$VAR_VALUE\\\"\"\n+}\n \n # Platform specific tweaks to work around some commands\n case $(uname -s) in\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex bc33112..e4d26f9 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -434,8 +434,24 @@ cmd_foreach()\n \t\t\t\tclear_local_git_env\n \t\t\t\t# we make $path available to scripts ...\n \t\t\t\tpath=$sm_path\n+\n+\t\t\t\t# make all submodule variables available to scripts\n+\t\t\t\teval $(\n+\t\t\t\t\tgit config -f .gitmodules --get-regexp \"^submodule\\.${name}\\..*\" |\n+\t\t\t\t\tsed -e \"s|^submodule\\.${name}\\.||\" |\n+\t\t\t\t\twhile read VAR_NAME VAR_VALUE ; do\n+\t\t\t\t\t\tVAR_NAME=$(printf '%s' \"$VAR_NAME\" | tr A-Z a-z)\n+\t\t\t\t\t\tset_user_variable \"submodule_${VAR_NAME}\" \"$VAR_VALUE\"\n+\t\t\t\t\tdone)\n+\t\t\t\tUNSET_CMD=$(set |\n+\t\t\t\t\tsed -n -e 's|^\\(submodule_[a-z_]*\\)=.*$|\\1|p' |\n+\t\t\t\t\twhile read VAR_NAME ; do\n+\t\t\t\t\t\tprintf 'unset %s;\\n' \"$VAR_NAME\"\n+\t\t\t\t\tdone)\n+\n \t\t\t\tcd \"$sm_path\" &&\n \t\t\t\teval \"$@\" &&\n+\t\t\t\teval \"$UNSET_CMD\" &&\n \t\t\t\tif test -n \"$recursive\"\n \t\t\t\tthen\n \t\t\t\t\tcmd_foreach \"--recursive\" \"$@\"\ndiff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh\nindex 9b69fe2..46ac746 100755\n--- a/t/t7407-submodule-foreach.sh\n+++ b/t/t7407-submodule-foreach.sh\n@@ -313,4 +313,33 @@ test_expect_success 'command passed to foreach --recursive retains notion of std\n \ttest_cmp expected actual\n '\n \n+cat > expect < ../actual\n+\t) &&\n+\ttest_i18ncmp expect actual\n+'\n+#\n+#\"echo \\$toplevel-\\$name-\\$submodule_path-\\$submodule_url\"\n+\n test_done\n-- \n1.8.0.3.gc2eb43a\n"},{"id":"202680","messageId":"ca0fc739741b72b50641e382a6162a829447237f.1352431675.git.wking@tremily.us","threadId":"32045","inReplyTo":"cover.1352431674.git.wking@tremily.us","subject":"[PATCH v3 3/3] git-submodule: Motivate --record with an example use case","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-09T03:35:14Z","receivedAt":"2012-11-09T03:35:14Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nSigned-off-by: W. Trevor King \n---\n Documentation/git-submodule.txt | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 9a99826..d4e993f 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -220,6 +220,14 @@ OPTIONS\n \tis not set either, `HEAD` will be recorded. Because the branch name\n \tis optional, you must use the equal-sign form (`-r=`), not\n \t`-r `.\n++\n+The recorded setting is not actually used by git; however, some\n+external tools and workflows may make use of it. For example, if the\n+upstream branches still exist and you have a recorded branch setting\n+for each of your submodules, you can update all of the submodules to\n+the current branch tips with:\n++\n+\tgit submodule foreach 'git checkout $submodule_branch && git pull'\n \n -f::\n --force::\n-- \n1.8.0.3.gc2eb43a\n"},{"id":"202685","messageId":"7v390jqlep.fsf@alter.siamese.dyndns.org","threadId":"32045","inReplyTo":"fb2d915cf60160c200b84df88c6112c1c2d4eefd.1352431674.git.wking@tremily.us","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-09T07:34:54Z","receivedAt":"2012-11-09T07:34:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n> By remaining agnostic on the variable usage, this patch makes\n> submodule setup more convenient for all parties.\n\nI personally do not think \"remaining agnostic on the usage\" is a\ngood thing, at least for any option to commands at the higher level\non the stack, such as \"git submodule\". I am afraid that giving an\neasier way to set up a variable with undefined semantics may make\nsetup more confusing for all parties. One party gives one specific\nmeaning to the field, while another party uses it for something\nslightly different.\n\nI would not object to \"git config submodule.$name.branch $value\", on\nthe other hand. \"git config\" can be used to set a piece of data\nthat has specific meaning, but as a low-level tool, it is not\n_limited_ to variables that have defined meaning.\n"},{"id":"202705","messageId":"20121109162919.GA922@book.hvoigt.net","threadId":"32045","inReplyTo":"7v390jqlep.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-11-09T16:29:27Z","receivedAt":"2012-11-09T16:29:27Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote:\n> \"W. Trevor King\" writes:\n> \n> > By remaining agnostic on the variable usage, this patch makes\n> > submodule setup more convenient for all parties.\n> \n> I personally do not think \"remaining agnostic on the usage\" is a\n> good thing, at least for any option to commands at the higher level\n> on the stack, such as \"git submodule\". I am afraid that giving an\n> easier way to set up a variable with undefined semantics may make\n> setup more confusing for all parties. One party gives one specific\n> meaning to the field, while another party uses it for something\n> slightly different.\n> \n> I would not object to \"git config submodule.$name.branch $value\", on\n> the other hand. \"git config\" can be used to set a piece of data\n> that has specific meaning, but as a low-level tool, it is not\n> _limited_ to variables that have defined meaning.\n\nI think we should agree on a behavior for this option and implement it\nthe same time when add learns about it. When we were discussing floating\nsubmodules as an important option for the gerrit people I already started\nto implement a proof of concept. Please have a look here:\n\nhttps://github.com/hvoigt/git/commits/hv/floating_submodules\n\nAFAIK this does not yet implement the same behaviour the gerrit tools\noffer for this option. The main reason behind that was because I do not\nknow the typical workflow behind such an option. So I am open to\nchanges.\n\nMaybe you can use or base your work on this implementation for submodule\nupdate.\n\nWithout submodule update using this option I think it would be better to\nimplement this option in the tool you are using instead of submodule add.\nEverything else feels incomplete to me.\n\nCheers Heiko\n"},{"id":"202708","messageId":"20121109164516.GB922@book.hvoigt.net","threadId":"32045","inReplyTo":"2121ce36cf4eb02385255cbd5b0bbd1dcc803113.1352431675.git.wking@tremily.us","subject":"Re: [PATCH v3 2/3] git-submodule foreach: export .gitmodules settings as variables","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-11-09T16:45:22Z","receivedAt":"2012-11-09T16:45:22Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Thu, Nov 08, 2012 at 10:35:13PM -0500, W. Trevor King wrote:\n> From: \"W. Trevor King\" \n> \n> This makes it easy to access per-submodule variables. For example,\n> \n> git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n> \n> can now be reduced to\n> \n> git submodule foreach 'git checkout $submodule_branch && git pull'\n\nWhat other use cases are there? Would the need for this maybe go away\nonce you had floating submodules following branches?\n\nThe whole thing looks like its adding some complex code which is not so\neasy to read. I would like to make sure its worth it.\n\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index bc33112..e4d26f9 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -434,8 +434,24 @@ cmd_foreach()\n> \t\t\t\tclear_local_git_env\n> \t\t\t\t# we make $path available to scripts ...\n> \t\t\t\tpath=$sm_path\n> +\n> +\t\t\t\t# make all submodule variables available to scripts\n> +\t\t\t\teval $(\n> +\t\t\t\t\tgit config -f .gitmodules --get-regexp \"^submodule\\.${name}\\..*\" |\n\nFor completeness you should make the variables possible to override by\nrepository from the local repository configuration like all other\nsubmodule options that are read directly from .gitmodules.\n\nCheers Heiko\n"},{"id":"202768","messageId":"20121110184437.GC2739@mjolnir","threadId":"32045","inReplyTo":"7v390jqlep.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-10T18:44:37Z","receivedAt":"2012-11-10T18:44:37Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote:\n> \"W. Trevor King\" writes:\n> \n> > By remaining agnostic on the variable usage, this patch makes\n> > submodule setup more convenient for all parties.\n> \n> I personally do not think \"remaining agnostic on the usage\" is a\n> good thing, at least for any option to commands at the higher level\n> on the stack, such as \"git submodule\". I am afraid that giving an\n> easier way to set up a variable with undefined semantics may make\n> setup more confusing for all parties. One party gives one specific\n> meaning to the field, while another party uses it for something\n> slightly different.\n> \n> I would not object to \"git config submodule.$name.branch $value\", on\n> the other hand. \"git config\" can be used to set a piece of data\n> that has specific meaning, but as a low-level tool, it is not\n> _limited_ to variables that have defined meaning.\n\nThis is what I'm doing now:\n\n $ git submodule add -b \n $ git config --file .gitmodules submodule..branch \n $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n\nWith my second patch (Phil's config export), that becomes\n\n $ git submodule add -b \n $ git config --file .gitmodules submodule..branch \n $ git submodule foreach 'git checkout $submodule_branch && git pull'\n\nWith my first patch, that becomes\n\n $ git submodule add -rb \n $ git submodule foreach 'git checkout $submodule_branch && git pull'\n\nThis seems pretty useful to me, but I'm still using\nsubmodule..branch explicitly as a user, and Git is not\ninterpreting the option directly. Users are free to store whatever\nthey like in that option, and use it however they wish:\n\n $ git submodule foreach 'do-crazy-stuff.sh $submodule_branch'\n\nIf we need a semantic interpretation to justify -r/--record, everyone\nthat's chimed in so far has agreed on the same interpretation. I\nwouldn't be averse to\n\n $ git submodule add -rb \n $ git submodule pull-branch\n\nwhich makes the foreach pull logic internal. However, there has been\na reasonable amount of resistance to this workflow in the past, so I\nthought that a patch series that avoided a semantic interpretation\nwould be more acceptable.\n\nIf neither an agnostic -r/--record or a semantic pull-branch command\nare acceptable, I suppose we'll have to drop my first and third\npatches and only keep the second.\n\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"202771","messageId":"20121110190232.GD2739@mjolnir","threadId":"32045","inReplyTo":"20121110184437.GC2739@mjolnir","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-10T19:02:32Z","receivedAt":"2012-11-10T19:02:32Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Nov 09, 2012 at 05:29:27PM +0100, Heiko Voigt wrote:\n> I think we should agree on a behavior for this option and implement it\n> the same time when add learns about it. When we were discussing floating\n> submodules as an important option for the gerrit people I already started\n> to implement a proof of concept. Please have a look here:\n> \n> https://github.com/hvoigt/git/commits/hv/floating_submodules\n\nAfter skimming through this, something like\n\n $ git submodule update --pull\n\nwould probably be better than introducing a new command:\n\nOn Sat, Nov 10, 2012 at 01:44:37PM -0500, W. Trevor King wrote:\n> $ git submodule pull-branch\n\nI think \"floating submodules\" is a misleading name for this feature\nthough, since the checkout SHA is explicitly specified. We're just\nmaking it more convenient to explicitly update the SHA. How about\n\"tracking submodules\"?\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"202769","messageId":"20121110191111.GE2739@mjolnir","threadId":"32045","inReplyTo":"20121109104607.GC4406@ftbfs.org","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-10T19:11:11Z","receivedAt":"2012-11-10T19:11:11Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Nov 09, 2012 at 02:46:07AM -0800, Matt Kraai wrote:\n> On Thu, Nov 08, 2012 at 10:35:12PM -0500, W. Trevor King wrote:\n> > @@ -366,6 +379,10 @@ Use -f if you really want to add it.\" >&2\n> > \n> > \tgit config -f .gitmodules submodule.\"$sm_path\".path \"$sm_path\" &&\n> > \tgit config -f .gitmodules submodule.\"$sm_path\".url \"$repo\" &&\n> > +\tif test -n \"$branch\"\n> > +\tthen\n> > +\t\tgit config -f .gitmodules submodule.\"$sm_path\".branch \"$record_branch\"\n> > +\tfi &&\n> > \tgit add --force .gitmodules ||\n> > \tdie \"$(eval_gettext \"Failed to register submodule '\\$sm_path'\")\"\n> > }\n> \n> Should the if condition test that $record_branch is not the empty\n> string instead of testing that $branch is not the empty string? It\n> seems like this will set submodule.\"$sm_path\".branch to the empty\n> string if -b is specified and no -r option is specified.\n\nOops, thanks for catching that. Will fix with v4, once we figure out\nwhat to do about the semantic-pull situation.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"202775","messageId":"20121110192135.GF2739@mjolnir","threadId":"32045","inReplyTo":"20121109164516.GB922@book.hvoigt.net","subject":"Re: [PATCH v3 2/3] git-submodule foreach: export .gitmodules settings as variables","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-10T19:21:35Z","receivedAt":"2012-11-10T19:21:35Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Nov 09, 2012 at 05:45:22PM +0100, Heiko Voigt wrote:\n> > can now be reduced to\n> > \n> > git submodule foreach 'git checkout $submodule_branch && git pull'\n> \n> What other use cases are there? Would the need for this maybe go away\n> once you had floating submodules following branches?\n\nNone that I can think of, but I don't use submodules very much. The\nidea of easily-accessible per-submodule configuration variables\nstrikes me as pretty useful, but I agree the code is a bit ugly.\nActually, I think exporting environment variables and calling the\nforeach command in a subshell would be better than the current local\nvariables and eval. The subshell would also make variable cleanup\nirrelevant, which would make for a cleaner patch.\n\n> For completeness you should make the variables possible to override by\n> repository from the local repository configuration like all other\n> submodule options that are read directly from .gitmodules.\n\nGood idea (I wasn't aware of the override before). Will do in v4.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"202809","messageId":"7vzk2oo2d2.fsf@alter.siamese.dyndns.org","threadId":"32045","inReplyTo":"20121110184437.GC2739@mjolnir","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-11T10:33:45Z","receivedAt":"2012-11-11T10:33:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n> On Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote:\n>\n>> I would not object to \"git config submodule.$name.branch $value\", on\n>> the other hand. \"git config\" can be used to set a piece of data\n>> that has specific meaning, but as a low-level tool, it is not\n>> _limited_ to variables that have defined meaning.\n>\n> This is what I'm doing now:\n>\n> $ git submodule add -b \n> $ git config --file .gitmodules submodule..branch \n> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n>\n> With my second patch (Phil's config export), that becomes\n>\n> $ git submodule add -b \n> $ git config --file .gitmodules submodule..branch \n> $ git submodule foreach 'git checkout $submodule_branch && git pull'\n>\n> With my first patch, that becomes\n>\n> $ git submodule add -rb \n> $ git submodule foreach 'git checkout $submodule_branch && git pull'\n>\n> This seems pretty useful to me,...\n\nAh, this reminds me of another thing I noticed when I saw that\npatch. The change seems to think \"branch\" is the _only_ thing the\nuser might want to record per submodule upon \"git submodule add\".\nAs an interface to muck with an uninterpreted random configuration,\nit squats on a good option name for setting one single and arbitrary\nvariable---quite a selfish change that is not acceptable.\n\nCalling the option \"--record-branch-for-submodule\" or something more\nspecific might alleviate the problem, but then it would become even\nless useful as a short-hand for \"config submodule.$name.branch\", I\nwould suspect.\n\nOn the other hand, if this were one small part of a series to define\nthe \"tip following mode\" where (at least)\n\n (1) \"git submodule update [$path]\" makes sure that the checkout of\n the submodule at $path matches the commit at the tip of the\n branch named by submodule.$name.branch in .gitmodules of the\n superproject, instead of the commit that is recorded in the\n index of the superproject; and\n\n (2) \"git diff [$path]\" and friends in the superproject compares the\n HEAD of the checkout of the submodule at $path with the tip of\n the branch named by submodule.$name.branch in .gitmodules of\n the superproject, instead of the commit that is recorded in the\n index of the superproject.\n\nand the option were called something like \"--follow-branch=$branch\",\nit would make much more sense for its initial implementation to set\nthe name of the branch to submodule.$name.branch variable. Later\niterations of such a feature may want to do more than just setting\nthat single variable but that is a part of the implementation detail\nof the tip following mode the users do not have to know about, just\nlike setting the submodule.$name.branch variable is.\n\nSo in that sense, too, I would be somewhat unhappy to see this\nchange in the current form to go in.\n"},{"id":"202865","messageId":"20121111150047.GA22608@odin.tremily.us","threadId":"32045","inReplyTo":"7vzk2oo2d2.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-11T15:00:48Z","receivedAt":"2012-11-11T15:00:48Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sun, Nov 11, 2012 at 02:33:45AM -0800, Junio C Hamano wrote:\n> The change seems to think \"branch\" is the _only_ thing the user\n> might want to record per submodule upon \"git submodule add\".\n\nI felt that earlier floating/tracking submodule patches were biting\noff more than they could chew, so I was looking for a lightweight fix\nto make the tracking workflow easier. It seems like I ended up with\nsomething that is too lightweight ;).\n\n> On the other hand, if this were one small part of a series to define\n> the \"tip following mode\" where (at least)\n> \n> (1) \"git submodule update [$path]\" makes sure that the checkout of\n> the submodule at $path matches the commit at the tip of the\n> branch named by submodule.$name.branch in .gitmodules of the\n> superproject, instead of the commit that is recorded in the\n> index of the superproject; and\n\nAs I mentioned earlier, I think\n\n $ git submodule update [$path]\n\nshould keep its current “checkout the already-registered SHA”\nfunctionality, with\n\n $ git submodule update --pull [$path]\n\npulling the tracked branch. I'll add a patch implementing this to v4.\n\nIn order to avoid losing (or creating) local-only submodule commits,\nI'll probably bail (with an error) on non-fast-forward pulls. Can\nanyone else think of other safety concerns?\n\nThis means that I'll probably drop Phil's $submodule_* export in v4,\nbecause the only explicit use we have for it is this branch tracking.\nI still think it is a useful idea, but it may not be useful enough to\nbe worth the complexity.\n\n> (2) \"git diff [$path]\" and friends in the superproject compares the\n> HEAD of the checkout of the submodule at $path with the tip of\n> the branch named by submodule.$name.branch in .gitmodules of\n> the superproject, instead of the commit that is recorded in the\n> index of the superproject.\n> \n\nHmm. “git diff” compares the working tree with the local HEAD (just a\nSHA for submodules), so I don't think it should care about the status\nof a remote branch. This sounds like you want something like:\n\n $ git submodule foreach 'git diff origin/$submodule_branch'\n\nPerhaps this is enough motivation for keeping $submodule_* exports?\n\n> and the option were called something like \"--follow-branch=$branch\",\n> …\n\nI'll replace -r/--record with --follow-branch in v4.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"203425","messageId":"20121117150441.GA7695@book.hvoigt.net","threadId":"32045","inReplyTo":"20121110190232.GD2739@mjolnir","subject":"Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-11-17T15:04:42Z","receivedAt":"2012-11-17T15:04:42Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nsorry for the late reply but my git time is limited.\n\nOn Sat, Nov 10, 2012 at 02:02:32PM -0500, W. Trevor King wrote:\n> On Fri, Nov 09, 2012 at 05:29:27PM +0100, Heiko Voigt wrote:\n> > I think we should agree on a behavior for this option and implement it\n> > the same time when add learns about it. When we were discussing floating\n> > submodules as an important option for the gerrit people I already started\n> > to implement a proof of concept. Please have a look here:\n> > \n> > https://github.com/hvoigt/git/commits/hv/floating_submodules\n> \n> After skimming through this, something like\n> \n> $ git submodule update --pull\n> \n> would probably be better than introducing a new command:\n\nYeah along the lines of that, but one thing to keep in mind:\n\nWe already have --rebase and --merge which do slightly different things\n(I think). Adding --pull here should behave similar to them. Like fetch\nand merge is the same to pull without submodules.\n\nIf I am understanding your goal correctly your --pull would be\ndifferent. On the other hand: A --pull makes no sense if we apply it to\nthe existing --merge option since it merges the recorded sha1 into the\ncurrent HEAD. Just a fetch would not really make a difference.\n\nThinking along the existing options I would probably still expect --pull\nto merge something into the current HEAD. So maybe we have to iron out\nwhere this command/option should go. But changing that once we have a\npatch to discuss should not be that much work. So please proceed with\n--pull and once we know exactly what it does we can polish that.\n\n> On Sat, Nov 10, 2012 at 01:44:37PM -0500, W. Trevor King wrote:\n> > $ git submodule pull-branch\n> \n> I think \"floating submodules\" is a misleading name for this feature\n> though, since the checkout SHA is explicitly specified. We're just\n> making it more convenient to explicitly update the SHA. How about\n> \"tracking submodules\"?\n\nUntil now we have always called this workflow floating submodules. I\nimaging since the submodule floats to the newest revision (whatever the\nuser chooses that to be) instead of staying at the recorded sha1.\n\n\"tracking submodules\" sounds strange to me since the term tracked in git\nis mainly used in combination with exact recorded history (e.g. tracking\nbranch). Since it is about *not* checking out the recorded sha1 but\nsomething that can change I think that could cause confusion.\n\nI think floating is a more unambiguous term and already known on the\nlist.\n\nCheers Heiko\n"},{"id":"203426","messageId":"20121117153007.GB7695@book.hvoigt.net","threadId":"32045","inReplyTo":"20121111150047.GA22608@odin.tremily.us","subject":"Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-11-17T15:30:07Z","receivedAt":"2012-11-17T15:30:07Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Sun, Nov 11, 2012 at 10:00:48AM -0500, W. Trevor King wrote:\n> On Sun, Nov 11, 2012 at 02:33:45AM -0800, Junio C Hamano wrote:\n> In order to avoid losing (or creating) local-only submodule commits,\n> I'll probably bail (with an error) on non-fast-forward pulls. Can\n> anyone else think of other safety concerns?\n\nThat sounds like a good thing to do. We can allow more flexibility later\nif people come up with usecases.\n\n> This means that I'll probably drop Phil's $submodule_* export in v4,\n> because the only explicit use we have for it is this branch tracking.\n> I still think it is a useful idea, but it may not be useful enough to\n> be worth the complexity.\n\nYes lets concentrate on the branch following first.\n\n> > (2) \"git diff [$path]\" and friends in the superproject compares the\n> > HEAD of the checkout of the submodule at $path with the tip of\n> > the branch named by submodule.$name.branch in .gitmodules of\n> > the superproject, instead of the commit that is recorded in the\n> > index of the superproject.\n> > \n> \n> Hmm. ???git diff??? compares the working tree with the local HEAD (just a\n> SHA for submodules), so I don't think it should care about the status\n> of a remote branch. This sounds like you want something like:\n> \n> $ git submodule foreach 'git diff origin/$submodule_branch'\n> \n> Perhaps this is enough motivation for keeping $submodule_* exports?\n> \n> > and the option were called something like \"--follow-branch=$branch\",\n> > ???\n\nI am not sure if hiding changes to the recorded SHA1 from the user is\nsuch a useful thing. In the first step I would like it if it was kept\nsimple and only the submodule update machinery learned to follow a\nbranch. If that results in local changes that should be shown. The user\nis still in charge of recording the updated SHA1 in his commit.\n\n>From what I have heard of projects using this: They usually still have\nsomething that records the SHA1s on a regular basis. Thinking further,\nwhy not record them in git? We could add an option to update which\ncreates such a commit.\n\nSince git is all about changes I am hesitant to hide them from the user.\n\n> I'll replace -r/--record with --follow-branch in v4.\n\nSounds good.\n\nCheers Heiko\n"},{"id":"203431","messageId":"20121117192026.GI22234@odin.tremily.us","threadId":"32045","inReplyTo":"20121117153007.GB7695@book.hvoigt.net","subject":"Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-17T19:20:27Z","receivedAt":"2012-11-17T19:20:27Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sat, Nov 17, 2012 at 04:04:42PM +0100, Heiko Voigt wrote:\n> > On Sat, Nov 10, 2012 at 01:44:37PM -0500, W. Trevor King wrote:\n> > > $ git submodule pull-branch\n> > \n> > I think \"floating submodules\" is a misleading name for this feature\n> > though, since the checkout SHA is explicitly specified. We're just\n> > making it more convenient to explicitly update the SHA. How about\n> > \"tracking submodules\"?\n> \n> Until now we have always called this workflow floating submodules. I\n> imaging since the submodule floats to the newest revision (whatever the\n> user chooses that to be) instead of staying at the recorded sha1.\n> \n> \"tracking submodules\" sounds strange to me since the term tracked in git\n> is mainly used in combination with exact recorded history (e.g. tracking\n> branch). Since it is about *not* checking out the recorded sha1 but\n> something that can change I think that could cause confusion.\n> \n> I think floating is a more unambiguous term and already known on the\n> list.\n\nI had been getting the impression that floating submodules would\nautomatically update without explicit user intervention. After\nre-reading your initial floating submodules post, it looks like we do\nmatch up after the mapping:\n\n Git Heiko Trevor\n --------- ----------------- -------------\n update update --checkout update\n update update --pull\n\nSo I'll go back to \"floating\" ;).\n\nOn Sat, Nov 17, 2012 at 04:30:07PM +0100, Heiko Voigt wrote:\n> > > (2) \"git diff [$path]\" and friends in the superproject compares the\n> > > HEAD of the checkout of the submodule at $path with the tip of\n> > > the branch named by submodule.$name.branch in .gitmodules of\n> > > the superproject, instead of the commit that is recorded in the\n> > > index of the superproject.\n> > > \n> > \n> > Hmm. ???git diff??? compares the working tree with the local HEAD (just a\n> > SHA for submodules), so I don't think it should care about the status\n> > of a remote branch. This sounds like you want something like:\n> > \n> > $ git submodule foreach 'git diff origin/$submodule_branch'\n> > \n> > Perhaps this is enough motivation for keeping $submodule_* exports?\n> > \n> > > and the option were called something like \"--follow-branch=$branch\",\n> > > ???\n> \n> I am not sure if hiding changes to the recorded SHA1 from the user is\n> such a useful thing. In the first step I would like it if it was kept\n> simple and only the submodule update machinery learned to follow a\n> branch. If that results in local changes that should be shown. The user\n> is still in charge of recording the updated SHA1 in his commit.\n\nI understand what you're warning against here, or what it has to do\nwith \"git diff\".\n\n> From what I have heard of projects using this: They usually still have\n> something that records the SHA1s on a regular basis. Thinking further,\n> why not record them in git? We could add an option to update which\n> creates such a commit.\n\nI think it's best to have users craft their own commit messages\nexplaining why the branch was updated. That said, an auto-generated\nhint (a la \"git merge\") would probably be a useful extra feature.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"203442","messageId":"20121117213130.GC7695@book.hvoigt.net","threadId":"32045","inReplyTo":"20121117192026.GI22234@odin.tremily.us","subject":"Re: Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-11-17T21:31:30Z","receivedAt":"2012-11-17T21:31:30Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Sat, Nov 17, 2012 at 02:20:27PM -0500, W. Trevor King wrote:\n> On Sat, Nov 17, 2012 at 04:30:07PM +0100, Heiko Voigt wrote:\n> > > > (2) \"git diff [$path]\" and friends in the superproject compares the\n> > > > HEAD of thecheckout of the submodule at $path with the tip of\n> > > > the branch named by submodule.$name.branch in .gitmodules of\n> > > > the superproject, instead of the commit that is recorded in the\n> > > > index of the superproject.\n> > > > \n> > > \n> > > Hmm. ???git diff??? compares the working tree with the local HEAD (just a\n> > > SHA for submodules), so I don't think it should care about the status\n> > > of a remote branch. This sounds like you want something like:\n> > > \n> > > $ git submodule foreach 'git diff origin/$submodule_branch'\n> > > \n> > > Perhaps this is enough motivation for keeping $submodule_* exports?\n> > > \n> > > > and the option were called something like \"--follow-branch=$branch\",\n> > > > ???\n> > \n> > I am not sure if hiding changes to the recorded SHA1 from the user is\n> > such a useful thing. In the first step I would like it if it was kept\n> > simple and only the submodule update machinery learned to follow a\n> > branch. If that results in local changes that should be shown. The user\n> > is still in charge of recording the updated SHA1 in his commit.\n> \n> I understand what you're warning against here, or what it has to do\n> with \"git diff\".\n\nIs there a not missing here? Reads somehow like that. What I am talking\nabout is the suggestion of Junio. Instead of showing a diff if the\nSHA1 is different we show a diff if the checkout in the worktree is\ndifferent from the tip of the configured branch. That would hide the\nfact that a submodule has changed during a submodule update operation.\n\n> > From what I have heard of projects using this: They usually still have\n> > something that records the SHA1s on a regular basis. Thinking further,\n> > why not record them in git? We could add an option to update which\n> > creates such a commit.\n> \n> I think it's best to have users craft their own commit messages\n> explaining why the branch was updated. That said, an auto-generated\n> hint (a la \"git merge\") would probably be a useful extra feature.\n\nI have the same opinion. Commits should always be created by humans so\nyou have someone to blame/ask why. But I guess there are people that\nexpect this to be automatic.\n\nOne argument somehow goes along the lines:\n\"I already created a commit in the submodule why do I need to create\nanother one in the superproject? Just follow the HEAD revision!\" They\nthink in subversions \"submodules\" which are merely pointers to other svn\nrepositories without any revision information. I am unsure if its good\nto support this the same way.\n\nAnother use case is big projects that have so many submodules that\ncreating superproject commits would create to much maintenance work.\nThey want to have their integration server make those commits. That\nwould already be supported with update checking out the branch tips and\nthe commit is just one extra thing to do by the integration server.\n\nSo I think it should be fine just to teach update to checkout the\nconfigured branch tips (or forward them to their tracking branch tips)\nand leave the rest to the user.\n\nCheers Heiko\n"},{"id":"203444","messageId":"20121117220007.GJ22234@odin.tremily.us","threadId":"32045","inReplyTo":"20121117213130.GC7695@book.hvoigt.net","subject":"Re: Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-17T22:00:07Z","receivedAt":"2012-11-17T22:00:07Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sat, Nov 17, 2012 at 10:31:30PM +0100, Heiko Voigt wrote:\n> On Sat, Nov 17, 2012 at 02:20:27PM -0500, W. Trevor King wrote:\n> > On Sat, Nov 17, 2012 at 04:30:07PM +0100, Heiko Voigt wrote:\n> > > > > (2) \"git diff [$path]\" and friends in the superproject compares the\n> > > > > HEAD of thecheckout of the submodule at $path with the tip of\n> > > > > the branch named by submodule.$name.branch in .gitmodules of\n> > > > > the superproject, instead of the commit that is recorded in the\n> > > > > index of the superproject.\n> > > > > \n> > > > \n> > > > Hmm. ???git diff??? compares the working tree with the local HEAD (just a\n> > > > SHA for submodules), so I don't think it should care about the status\n> > > > of a remote branch. This sounds like you want something like:\n> > > > \n> > > > $ git submodule foreach 'git diff origin/$submodule_branch'\n> > > > \n> > > > Perhaps this is enough motivation for keeping $submodule_* exports?\n> > > > \n> > > > > and the option were called something like \"--follow-branch=$branch\",\n> > > > > ???\n> > > \n> > > I am not sure if hiding changes to the recorded SHA1 from the user is\n> > > such a useful thing. In the first step I would like it if it was kept\n> > > simple and only the submodule update machinery learned to follow a\n> > > branch. If that results in local changes that should be shown. The user\n> > > is still in charge of recording the updated SHA1 in his commit.\n> > \n> > I understand what you're warning against here, or what it has to do\n> > with \"git diff\".\n> \n> Is there a not missing here?\n\nThanks. I'd meant to say \"I don't understand…\".\n\n> What I am talking about is the suggestion of Junio. Instead of\n> showing a diff if the SHA1 is different we show a diff if the\n> checkout in the worktree is different from the tip of the configured\n> branch. That would hide the fact that a submodule has changed during\n> a submodule update operation.\n\nAhh, now I understand. I agree that comparing to the remote tip is a\nbad idea.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"203533","messageId":"7vd2z9t7y2.fsf@alter.siamese.dyndns.org","threadId":"32045","inReplyTo":"20121117192026.GI22234@odin.tremily.us","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-20T00:49:09Z","receivedAt":"2012-11-20T00:49:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n>> From what I have heard of projects using this: They usually still have\n>> something that records the SHA1s on a regular basis. Thinking further,\n>> why not record them in git? We could add an option to update which\n>> creates such a commit.\n>\n> I think it's best to have users craft their own commit messages\n> explaining why the branch was updated. That said, an auto-generated\n> hint (a la \"git merge\") would probably be a useful extra feature.\n\nI am not quite sure I agree. When the project says \"Use the tip of\n'bar' branch for the submodule 'foo'\" at the top-level, does an\nindividual user who is not working on the submodule 'foo' but merely\nis using it have any clue as to why the submodule's 'foo' branch\n'foo' moved, or does he necessarily even care?\n\nFor such a user working at the top-level superproject, or working on\none part of the project, possibly on a submodule other than 'foo',\nwouldn't the natural thing to do would be to run \"git pull\" at the\ntop-level, maybe with \"--recursive\" to update the top-level and all\nthe submodules to start the day.\n\nNow, since somebody created the top-level commit you have just\npulled and checked out, other people may have worked on submodule\n'foo' [*1*]. What should happen on \"git submodule update foo\"? It\nwould notice that the submodule 'foo' is set to float, and would\ncheck out the tip of the branch 'bar', not the commit recorded in\nthe top-level superproject, in the working tree for 'foo', no?\n\nWhat should appear in \"git diff\"? The working tree taken as a whole\nis different from what the superproject's commit describes (which is\nthe state the person who created the superproject wanted to record)\neven though this user does not have anything to do with the change\nat 'foo' from the recorded commit to the current tip of 'bar'. What\nwould his description for the reason why the branch was updated?\n\nI think I would agree that \"git diff\" should not hide such changes\n(after all, when this user records his change to the overall project\nin the top-level supermodule, he will be recording the state with\nthe commit at the tip of 'bar' checked out in the working tree of\nthe submodule 'foo'), but I am not sure if the user can say anything\nsensible, other than \"tip of 'bar' branch in submodule 'foo' was\nchanged by others\", in the resulting commit.\n\n\n[Footnote]\n\n*1* This may look like a non-issue if you assume that the person who\nupdates the 'bar' branch of submodule 'foo' always updates the\ngitlink in the superproject's commit to point at that updated\ncommit, but that assumption is flawed; the submodule project is a\nproject on its own and can be worked on without what other projects\nbind it as their submodules.\n"},{"id":"203534","messageId":"20121120011628.GD321@odin.tremily.us","threadId":"32045","inReplyTo":"7vd2z9t7y2.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-20T01:16:28Z","receivedAt":"2012-11-20T01:16:28Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote:\n> \"W. Trevor King\" writes:\n> \n> >> From what I have heard of projects using this: They usually still have\n> >> something that records the SHA1s on a regular basis. Thinking further,\n> >> why not record them in git? We could add an option to update which\n> >> creates such a commit.\n> >\n> > I think it's best to have users craft their own commit messages\n> > explaining why the branch was updated. That said, an auto-generated\n> > hint (a la \"git merge\") would probably be a useful extra feature.\n> \n> I am not quite sure I agree. When the project says \"Use the tip of\n> 'bar' branch for the submodule 'foo'\" at the top-level, does an\n> individual user who is not working on the submodule 'foo' but merely\n> is using it have any clue as to why the submodule's 'foo' branch\n> 'foo' moved, or does he necessarily even care?\n\nIf he doesn't care, why is he updating the submodule gitlink?\n\n> Now, since somebody created the top-level commit you have just\n> pulled and checked out, other people may have worked on submodule\n> 'foo' [*1*]. What should happen on \"git submodule update foo\"?\n\nIf the 'foo' checkout is not the one listed in the superproject's\n.gitmodules, the update should bail with an appropriate error message,\nand let the user sort things out.\n\n $ git submodule update --pull foo\n error: Your local changes to the following submodule would be\n overwritten by update:…\n\nThis is similar to how Git currently bails on dirty-tree branch\nswitches:\n\n $ git checkout my-branch\n error: Your local changes to the following files would be\n overwritten by checkout:…\n\nWithout \"--pull\", the update command is intended to checkout the hash\nspecified in .gitmodules. If you've committed some local work in foo\nand then explicitly ask for an update, I suppose you get clobbered.\n\n> What should appear in \"git diff\"? The working tree taken as a whole\n> is different from what the superproject's commit describes (which is\n> the state the person who created the superproject wanted to record)\n> even though this user does not have anything to do with the change\n> at 'foo' from the recorded commit to the current tip of 'bar'. What\n> would his description for the reason why the branch was updated?\n\nThe submodule content is not part of the superproject. All the\nsuperproject has is a gitlink. If the gitlink hasn't changed, \"git\ndiff\" in the superproject shouldn't say anything.\n\nI'll probably have time to write up v4 over the weekend. Maybe having\na more explicit example will clear things up.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"203537","messageId":"7v1ufou92h.fsf@alter.siamese.dyndns.org","threadId":"32045","inReplyTo":"20121120011628.GD321@odin.tremily.us","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-20T05:39:34Z","receivedAt":"2012-11-20T05:39:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n> On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote:\n>> \"W. Trevor King\" writes:\n>> ...\n>> > I think it's best to have users craft their own commit messages\n>> > explaining why the branch was updated. That said, an auto-generated\n>> > hint (a la \"git merge\") would probably be a useful extra feature.\n>> \n>> I am not quite sure I agree. When the project says \"Use the tip of\n>> 'bar' branch for the submodule 'foo'\" at the top-level, does an\n>> individual user who is not working on the submodule 'foo' but merely\n>> is using it have any clue as to why the submodule's 'foo' branch\n>> 'foo' moved, or does he necessarily even care?\n>\n> If he doesn't care, why is he updating the submodule gitlink?\n\nHe may not be updating the gitlink with \"git add foo\" at the\ntop-level superproject level. He is just using that submodule as\npart of the larger whole as he is working on either the top-level or\nsome other submodule. And checkout of 'foo' is necessary in the\nworking tree for him to work in the larger context of the project,\nand 'foo' is set to float at the tip of its 'bar' branch. And that\ncheckout results in a commit that is different from the commit the\ngitlink suggests, perhaps because somebody worked in 'foo' submodule\nand advanced the tip of branch 'bar'.\n\nSo:\n\n - at the top-level superproject level, entry 'foo' in the HEAD tree\n points at an older commit;\n\n - 'foo/.git/HEAD' points at refs/heads/bar, which matches the\n working tree of 'foo' and the index foo/.git/index..\n\nI am not sure what should happen to the entry 'foo' in the index of\nthe top-level superproject after such a 'submodule floats at the\ntip' checkout, but I imagine that it must match the contents of\nfoo/.git/HEAD's tree. Otherwise, \"git diff\" at the top-level would\nreport local changes.\n\nWhen committing his work at the top-level, he will see that 'foo'\ngitlink is updated in that commit; after all that combination is the\ncontext in which his work was done.\n\nOr are you envisioning that such a check-out will and should show a\nlocal difference at the submodule 'foo' by leaving the index of the\ntop-level superproject unchanged, and the user should refrain from\nusing \"git commit -a\" to avoid having to describe the changes made\non the 'bar' branch in the meantime in his top-level commit? That\nis certainly fine by me (I am no a heavy submodule user to begin\nwith), but I am not sure if that is useful and helpful to the\nsubmodule users.\n"},{"id":"203556","messageId":"20121120121912.GC7096@odin.tremily.us","threadId":"32045","inReplyTo":"7v1ufou92h.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-20T12:19:12Z","receivedAt":"2012-11-20T12:19:12Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Mon, Nov 19, 2012 at 09:39:34PM -0800, Junio C Hamano wrote:\n> \"W. Trevor King\" writes:\n> \n> > On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote:\n> >> \"W. Trevor King\" writes:\n> >> ...\n> >> > I think it's best to have users craft their own commit messages\n> >> > explaining why the branch was updated. That said, an auto-generated\n> >> > hint (a la \"git merge\") would probably be a useful extra feature.\n> >> \n> >> I am not quite sure I agree. When the project says \"Use the tip of\n> >> 'bar' branch for the submodule 'foo'\" at the top-level, does an\n> >> individual user who is not working on the submodule 'foo' but merely\n> >> is using it have any clue as to why the submodule's 'foo' branch\n> >> 'foo' moved, or does he necessarily even care?\n> >\n> > If he doesn't care, why is he updating the submodule gitlink?\n> \n> He may not be updating the gitlink with \"git add foo\" at the\n> top-level superproject level. He is just using that submodule as\n> part of the larger whole as he is working on either the top-level or\n> some other submodule. And checkout of 'foo' is necessary in the\n> working tree for him to work in the larger context of the project,\n> and 'foo' is set to float at the tip of its 'bar' branch. And that\n> checkout results in a commit that is different from the commit the\n> gitlink suggests, perhaps because somebody worked in 'foo' submodule\n> and advanced the tip of branch 'bar'.\n\nThe superproject gitlink should only be updated after\n\n $ git submodule update --pull\n\nA plain\n\n $ git submodule update\n\nwould still checkout the previously-recorded SHA, not the new upstream\ntip. The uncaring user should skip the \"--pull\", and there will be no\nsuperproject changes to worry about.\n\n> Or are you envisioning that such a check-out will and should show a\n> local difference at the submodule 'foo' by leaving the index of the\n> top-level superproject unchanged,\n\nA plain \"git submodule update\" will, yes. And this will clobber any\nchanges that have happened in the submodule directory and its index\n(because the user explicitly asked to checkout the\nsuperproject-recorded SHA)\n\n> and the user should refrain from using \"git commit -a\" to avoid\n> having to describe the changes made on the 'bar' branch in the\n> meantime in his top-level commit?\n\nWhat would \"git commit -a\" be picking up? Nothing in the superproject\nhas changed?\n\n> That is certainly fine by me (I am no a heavy submodule user to\n> begin with), but I am not sure if that is useful and helpful to the\n> submodule users.\n\nThe benefit is that Ævar's\n\n $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n\nbecomes\n\n $ git submodule update --pull\n\nStill an explicit pull, but much easier to remember.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"203566","messageId":"7vhaokrr01.fsf@alter.siamese.dyndns.org","threadId":"32045","inReplyTo":"20121120121912.GC7096@odin.tremily.us","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-20T19:52:46Z","receivedAt":"2012-11-20T19:52:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n> The superproject gitlink should only be updated after\n>\n> $ git submodule update --pull\n>\n> A plain\n>\n> $ git submodule update\n>\n> would still checkout the previously-recorded SHA, not the new upstream\n> tip.\n\nHrm, doesn't it make the \"float at the tip of a branch\" mode\nuseless, though?\n"},{"id":"203706","messageId":"20121123155521.GB14509@book.hvoigt.net","threadId":"32045","inReplyTo":"7vhaokrr01.fsf@alter.siamese.dyndns.org","subject":"Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-11-23T15:55:21Z","receivedAt":"2012-11-23T15:55:21Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote:\n> \"W. Trevor King\" writes:\n> \n> > The superproject gitlink should only be updated after\n> >\n> > $ git submodule update --pull\n> >\n> > A plain\n> >\n> > $ git submodule update\n> >\n> > would still checkout the previously-recorded SHA, not the new upstream\n> > tip.\n> \n> Hrm, doesn't it make the \"float at the tip of a branch\" mode\n> useless, though?\n\nHow about having a branch config option and reusing our\nsubmodule.$name.update option for specifying whether the user wants to\nalways float to the tip of the branch?\n\n1. If submodule.$name.update is pull it would checkout the specified tip.\n\n2. If submodule.$name.update is checkout or none it would do the usual\n thing and you need to specify --pull to get the tip.\n\nI am still a little bit undecided about an automatically crafted commit.\n\nAt $dayjob we sometimes update submodules to their tip without any\nsuperproject changes just to make sure we use the newest version. Most\nof the time the commit messages are along the lines of \"updated\nsubmodule x to master\".\n\nOn one hand Junio is right that the person updating to the newest\nsubmodule stuff has no clue what to write in this message. On the other\nhand someone might as well just use this functionality to get all the\ntips of all the submodules checked out. He then individually decides\nwhich changes to take by using add but will then still use a commit\nmessage like the one above.\n\nSo currently I am more on the \"have an automatically generated\ncommit message\" side. Its in a similar corner like merge commits, that\nare also generated, for me. We could have it as the default and a\n--no-commit option (like merge) for people that want to stage submodules\nindividually.\n\nCheers Heiko\n"},{"id":"203707","messageId":"20121123160301.GC14509@book.hvoigt.net","threadId":"32045","inReplyTo":"20121120121912.GC7096@odin.tremily.us","subject":"Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-11-23T16:03:01Z","receivedAt":"2012-11-23T16:03:01Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Tue, Nov 20, 2012 at 07:19:12AM -0500, W. Trevor King wrote:\n> The benefit is that Ævar's\n> \n> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n> \n> becomes\n> \n> $ git submodule update --pull\n\nThere is an important question still unanswered here for me: How does\nthe submodule get the configuration what the local branch tracks on the\nremote side?\n\nCheers Heiko\n"},{"id":"203708","messageId":"20121123162329.GF2806@odin.tremily.us","threadId":"32045","inReplyTo":"20121123160301.GC14509@book.hvoigt.net","subject":"Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-23T16:23:29Z","receivedAt":"2012-11-23T16:23:29Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Nov 23, 2012 at 04:55:21PM +0100, Heiko Voigt wrote:\n> On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote:\n> > \"W. Trevor King\" writes:\n> > \n> > > The superproject gitlink should only be updated after\n> > >\n> > > $ git submodule update --pull\n> > >\n> > > A plain\n> > >\n> > > $ git submodule update\n> > >\n> > > would still checkout the previously-recorded SHA, not the new upstream\n> > > tip.\n> > \n> > Hrm, doesn't it make the \"float at the tip of a branch\" mode\n> > useless, though?\n> \n> How about having a branch config option and reusing our\n> submodule.$name.update option for specifying whether the user wants to\n> always float to the tip of the branch?\n\nI'm adding \"update --pull\" as one of the update options in v4, which I\nam writing up as we speak ;).\n\n> 1. If submodule.$name.update is pull it would checkout the specified tip.\n\nand pull from the submodule's upstream. This doesn't need the\nrecorded $sha1, so I may have to rework the current\n\n if (clear_local_git_env; cd \"$sm_path\" && $command \"$sha1\")\n\n> 2. If submodule.$name.update is checkout or none it would do the usual\n> thing and you need to specify --pull to get the tip.\n\nExactly.\n\n> So currently I am more on the \"have an automatically generated\n> commit message\" side. Its in a similar corner like merge commits, that\n> are also generated, for me. We could have it as the default and a\n> --no-commit option (like merge) for people that want to stage submodules\n> individually.\n\nThis sounds reasonable, but I'd like to postpone message-generation\nsugar until we get the basic functionality ironed out.\n\nOn Fri, Nov 23, 2012 at 05:03:01PM +0100, Heiko Voigt wrote:\n> On Tue, Nov 20, 2012 at 07:19:12AM -0500, W. Trevor King wrote:\n> > The benefit is that Ævar's\n> > \n> > $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n> > \n> > becomes\n> > \n> > $ git submodule update --pull\n> \n> There is an important question still unanswered here for me: How does\n> the submodule get the configuration what the local branch tracks on the\n> remote side?\n\nA good point ;). I'm actaully using submodule..branch to store\nthe submodule's local branch name. The remote branch name for the\npull is implicit, and defaults to something setup according to\nbranch.autosetupmerge (I think). If you want to get more complicated\nthan this, we'll probably have to add submodule..branch and\nsubmodule..remote sections to augment the\nsubmodule..branch setting. I'm not sure this is worth it.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"203710","messageId":"20121123163024.GG2806@odin.tremily.us","threadId":"32045","inReplyTo":"20121123162329.GF2806@odin.tremily.us","subject":"Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-23T16:30:24Z","receivedAt":"2012-11-23T16:30:24Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Nov 23, 2012 at 11:23:29AM -0500, W. Trevor King wrote:\n> On Fri, Nov 23, 2012 at 05:03:01PM +0100, Heiko Voigt wrote:\n> > There is an important question still unanswered here for me: How does\n> > the submodule get the configuration what the local branch tracks on the\n> > remote side?\n> \n> A good point ;). I'm actaully using submodule..branch to store\n> the submodule's local branch name. The remote branch name for the\n> pull is implicit, and defaults to something setup according to\n> branch.autosetupmerge (I think). If you want to get more complicated\n> than this, we'll probably have to add submodule..branch and\n> submodule..remote sections to augment the\n> submodule..branch setting. I'm not sure this is worth it.\n\nThese settings are currently stored in\n\n .git/modules//config\n\nWhat we're missing is a place to store them in the .gitmodules file.\nI'll poke around in the module-config initialization and wait for\ninspiration ;).\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"203712","messageId":"10919221.ErD9qLRjsD@blacky","threadId":"32045","inReplyTo":"20121123155521.GB14509@book.hvoigt.net","subject":"Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"Sascha Cunz","fromEmail":"sascha-ml@babbelbox.org","sentAt":"2012-11-23T17:24:33Z","receivedAt":"2012-11-23T17:24:33Z","isPatch":true,"sender":{"key":"sascha-ml@babbelbox.org","avatar":null},"body":"Am Freitag, 23. November 2012, 16:55:21 schrieb Heiko Voigt:\n> I am still a little bit undecided about an automatically crafted commit.\n> \n> At $dayjob we sometimes update submodules to their tip without any\n> superproject changes just to make sure we use the newest version. Most\n> of the time the commit messages are along the lines of \"updated\n> submodule x to master\".\n>\n> On one hand Junio is right that the person updating to the newest\n> submodule stuff has no clue what to write in this message.\n\nI've been thinking about that for a while, when I started using submodules. In \nthe end, I concluded, that what I really want to see in the commit message, is \nsomething similar to $(git shortlog $OLD_SHA1..$NEW_SHA1).\n\nI've scripted that and taught my CI-Server to do it automatically, if \npossible. So most of the time, I really don't want an \"automatically crafted \ncommit\" whenever something causes the tip of a submodule to be at a new SHA1.\n\nJust my $.02, though.\n\nSascha\n"},{"id":"203713","messageId":"20121123175402.GH2806@odin.tremily.us","threadId":"32045","inReplyTo":"20121123162329.GF2806@odin.tremily.us","subject":"Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-23T17:54:02Z","receivedAt":"2012-11-23T17:54:02Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Nov 23, 2012 at 11:23:29AM -0500, W. Trevor King wrote:\n> On Fri, Nov 23, 2012 at 04:55:21PM +0100, Heiko Voigt wrote:\n> > On Tue, Nov 20, 2012 at 11:52:46AM -0800, Junio C Hamano wrote:\n> > > \"W. Trevor King\" writes:\n> > > \n> > > > The superproject gitlink should only be updated after\n> > > >\n> > > > $ git submodule update --pull\n> > > >\n> > > > A plain\n> > > >\n> > > > $ git submodule update\n> > > >\n> > > > would still checkout the previously-recorded SHA, not the new upstream\n> > > > tip.\n> > > \n> > > Hrm, doesn't it make the \"float at the tip of a branch\" mode\n> > > useless, though?\n> > \n> > How about having a branch config option and reusing our\n> > submodule.$name.update option for specifying whether the user wants to\n> > always float to the tip of the branch?\n> \n> I'm adding \"update --pull\" as one of the update options in v4, which I\n> am writing up as we speak ;).\n\nOn second thought, this does not seem to be a good idea. The current\nfancy update styles (--rebase, --merge) are both for cases where you\nhave local commits in the submodule and are trying to incorporate new\ngitlinks from an updated superproject into the submodule's checked out\nbranch:\n\n superproject $ cd submod\n superproject $ git checkout next\n submod $ …hack hack hack…\n submod $ git commit …\n submod $ cd ..\n …upstream superproject changes…\n superproject $ git pull\n …updated SHA1 for submod gitlink…\n superproject $ git submodule update --merge\n …merge superproject's gitlink SHA1 into local submod branch…\n\nMy submodule..branch option gives a local branch to\ncheck out:\n\n …upstream submod changes…\n superproject $ git cd ssubmodule update --pull\n …fetch upstream submod changes and ff-merge into local submodule..branch…\n\nThis seems suitably distinct that bundling it with the other update\noptions will just add confusion.\n\nSo, let's rethink this approach. I'm trying to pull the upstream\nversion of my local submod branch. The difficulties with this are:\n\n1. Checking out a local branch (from the default detached state)\n to do something on it requires an ungainly:\n\n $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && …'\n\n2. The remote pulling behavior is configured in\n .git/modules//config, which is not tracked in the repository\n itself.\n\nI'm ok with forcing local users to handle 2 manually (or implicitly),\nbut 1 is crazy. Addin submodule..branch explicitly to\n.gitmodules is a step towards fixing 1, but submod pull doesn't match\nan existing submodules-implemented workflow. Perhaps a better choice\nwould be to borrow the implicit-local-checkout behaviour used by\n--rebase and --merge. We could add\n\n $ git submodule update --branch\n\nto checkout the gitlinked SHA1 as submodule..branch in each of\nthe submodules, leaving the submodules on the .gitmodules-configured\nbranch. Effectively (for each submodule):\n\n $ git branch -f $branch $sha1\n $ git checkout $branch\n\nThen I could use\n\n $ git submodule foreach 'git pull'\n\nto update my submodule tracking branches (without further \"git\nsubmodule\" restructuring).\n\nThis would help everyone that doesn't like the detached head state (me\nand --rebase/--merge users). I could avoid implementing \"update\n--pull\", and all of the difficulty in configuring upstream merge\nchoices (2) would be punted to the user making local edits in\n.git/modules//config.\n\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"203927","messageId":"cover.1353962698.git.wking@tremily.us","threadId":"32045","inReplyTo":"20121123175402.GH2806@odin.tremily.us","subject":"[PATCH v4 0/4] git-submodule add: Add --local-branch option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-26T21:00:15Z","receivedAt":"2012-11-26T21:00:15Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nOn Fri, Nov 23, 2012 at 12:54:02PM -0500, W. Trevor King wrote:\n> We could add\n>\n> $ git submodule update --branch\n>\n> to checkout the gitlinked SHA1 as submodule..branch in each of\n> the submodules, leaving the submodules on the .gitmodules-configured\n> branch. Effectively (for each submodule):\n>\n> $ git branch -f $branch $sha1\n> $ git checkout $branch\n\nI haven't gotten any feedback on this as an idea, but perhaps someone\nwill comment on it as a patch series ;).\n\nChanges since v3:\n\n* --record=… is now --local-branch=…\n* Dropped patches 2 ($submodule_ export) and 3 (motivating documentation)\n* Added local git-config overrides of .gitmodules' submodule..branch\n* Added `submodule update --branch`\n\nBecause you need to recurse through submodules for `update --branch`\neven if \"$subsha1\" == \"$sha1\", I had to amend the conditional\ncontrolling that block. This broke one of the existing tests, which I\n\"fixed\" in patch 4. I think a proper fix would involve rewriting\n\n (clear_local_git_env; cd \"$sm_path\" &&\n ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&\n test -z \"$rev\") || git-fetch)) ||\n die \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n\nbut I'm not familiar enough with rev-list to want to dig into that\nyet. If feedback for the earlier three patches is positive, I'll work\nup a clean fix and resubmit.\n\nW. Trevor King (4):\n git-submodule add: Add --local-branch option\n git-submodule init: Record submodule..branch in repository\n config.\n git-submodule update: Add --branch option\n Hack fix for 'submodule update does not fetch already present\n commits'\n\n Documentation/config.txt | 9 ++---\n Documentation/git-submodule.txt | 32 ++++++++++++-----\n Documentation/gitmodules.txt | 5 +++\n git-submodule.sh | 76 +++++++++++++++++++++++++++++++++--------\n t/t7400-submodule-basic.sh | 43 +++++++++++++++++++++++\n t/t7406-submodule-update.sh | 50 ++++++++++++++++++++++++++-\n 6 files changed, 187 insertions(+), 28 deletions(-)\n\n-- \n1.8.0.3.g95edff1.dirty\n"},{"id":"203926","messageId":"15e0581e0cb0bb42bf84e8e195597e46d3457a93.1353962698.git.wking@tremily.us","threadId":"32045","inReplyTo":"cover.1353962698.git.wking@tremily.us","subject":"[PATCH v4 1/4] git-submodule add: Add --local-branch option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-26T21:00:16Z","receivedAt":"2012-11-26T21:00:16Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nThis option allows you to record a submodule..branch option in\n.gitmodules. Git does not currently use this configuration option for\nanything, but users have used it for several things, so it makes sense\nto add some syntactic sugar for initializing the value.\n\nCurrent consumers:\n\nÆvar uses this setting to designate the local branch to checkout when\npulling submodule updates:\n\n $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n\nas he describes in\n\n commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f\n Author: Ævar Arnfjörð Bjarmason \n Date: Fri May 21 16:10:10 2010 +0000\n\n git-submodule foreach: Add $toplevel variable\n\nGerrit uses the same interpretation for the setting, but because\nGerrit has direct access to the subproject repositories, it updates\nthe superproject repositories automatically when a subproject changes.\nGerrit also accepts the special value '.', which it expands into the\nsuperproject's branch name.\n\nEarlier version of this patch remained agnostic on the variable usage,\nbut this was deemed potentially confusing. Future patches in this\nseries will extend the submodule command to use the stored value\ninternally.\n\n[1] https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt\n\nSigned-off-by: W. Trevor King \n---\n Documentation/git-submodule.txt | 12 ++++++++++--\n Documentation/gitmodules.txt | 5 +++++\n git-submodule.sh | 19 ++++++++++++++++++-\n t/t7400-submodule-basic.sh | 25 +++++++++++++++++++++++++\n 4 files changed, 58 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex b4683bb..d0b4436 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -9,8 +9,8 @@ git-submodule - Initialize, update or inspect submodules\n SYNOPSIS\n --------\n [verse]\n-'git submodule' [--quiet] add [-b branch] [-f|--force]\n-\t [--reference ] [--] []\n+'git submodule' [--quiet] add [-b branch] [--local-branch[=]]\n+\t [-f|--force] [--reference ] [--] []\n 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]\n 'git submodule' [--quiet] init [--] [...]\n 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]\n@@ -209,6 +209,14 @@ OPTIONS\n --branch::\n \tBranch of repository to add as submodule.\n \n+--local-branch::\n+\tRecord a branch name used as `submodule..branch` in\n+\t`.gitmodules` for future reference. If you do not list an explicit\n+\tname here, the name given with `--branch` will be recorded. If that\n+\tis not set either, `HEAD` will be recorded. Because the branch name\n+\tis optional, you must use the equal-sign form\n+\t(`--local-branch=`), not `--local-branch `.\n+\n -f::\n --force::\n \tThis option is only valid for add and update commands.\ndiff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt\nindex 4effd78..840ccfe 100644\n--- a/Documentation/gitmodules.txt\n+++ b/Documentation/gitmodules.txt\n@@ -47,6 +47,11 @@ submodule..update::\n \tThis config option is overridden if 'git submodule update' is given\n \tthe '--merge', '--rebase' or '--checkout' options.\n \n+submodule..branch::\n+\tA local branch name for the submodule (to avoid headless operation).\n+\tSet with the \"--local-branch\" option to \"git submodule add\", or\n+\tdirectly using \"git config\".\n+\n submodule..fetchRecurseSubmodules::\n \tThis option can be used to control recursive fetching of this\n \tsubmodule. If this option is also present in the submodules entry in\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex ab6b110..6eed008 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -5,7 +5,7 @@\n # Copyright (c) 2007 Lars Hjemli\n \n dashless=$(basename \"$0\" | sed -e 's/-/ /')\n-USAGE=\"[--quiet] add [-b branch] [-f|--force] [--reference ] [--] []\n+USAGE=\"[--quiet] add [-b branch] [--local-branch[=]] [-f|--force] [--reference ] [--] []\n or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]\n or: $dashless [--quiet] init [--] [...]\n or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n@@ -20,6 +20,8 @@ require_work_tree\n \n command=\n branch=\n+local_branch=\n+local_branch_empty=\n force=\n reference=\n cached=\n@@ -257,6 +259,12 @@ cmd_add()\n \t\t\tbranch=$2\n \t\t\tshift\n \t\t\t;;\n+\t\t--local-branch)\n+\t\t\tlocal_branch_empty=true\n+\t\t\t;;\n+\t\t--local-branch=*)\n+\t\t\tlocal_branch=\"${1#*=}\"\n+\t\t\t;;\n \t\t-f | --force)\n \t\t\tforce=$1\n \t\t\t;;\n@@ -328,6 +336,11 @@ cmd_add()\n \tgit ls-files --error-unmatch \"$sm_path\" > /dev/null 2>&1 &&\n \tdie \"$(eval_gettext \"'\\$sm_path' already exists in the index\")\"\n \n+\tif test -z \"$local_branch\" && test \"$local_branch_empty\" = \"true\"\n+\tthen\n+\t\tlocal_branch=\"${branch:=HEAD}\"\n+\tfi\n+\n \tif test -z \"$force\" && ! git add --dry-run --ignore-missing \"$sm_path\" > /dev/null 2>&1\n \tthen\n \t\teval_gettextln \"The following path is ignored by one of your .gitignore files:\n@@ -366,6 +379,10 @@ Use -f if you really want to add it.\" >&2\n \n \tgit config -f .gitmodules submodule.\"$sm_path\".path \"$sm_path\" &&\n \tgit config -f .gitmodules submodule.\"$sm_path\".url \"$repo\" &&\n+\tif test -n \"$local_branch\"\n+\tthen\n+\t\tgit config -f .gitmodules submodule.\"$sm_path\".branch \"$local_branch\"\n+\tfi &&\n \tgit add --force .gitmodules ||\n \tdie \"$(eval_gettext \"Failed to register submodule '\\$sm_path'\")\"\n }\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex 5397037..fc08647 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -133,6 +133,7 @@ test_expect_success 'submodule add --branch' '\n \t(\n \t\tcd addtest &&\n \t\tgit submodule add -b initial \"$submodurl\" submod-branch &&\n+\t\ttest -z \"$(git config -f .gitmodules submodule.submod-branch.branch)\" &&\n \t\tgit submodule init\n \t) &&\n \n@@ -211,6 +212,30 @@ test_expect_success 'submodule add with ./, /.. and // in path' '\n \ttest_cmp empty untracked\n '\n \n+test_expect_success 'submodule add --local-branch' '\n+\t(\n+\t\tcd addtest &&\n+\t\tgit submodule add --local-branch \"$submodurl\" submod-follow-head &&\n+\t\ttest \"$(git config -f .gitmodules submodule.submod-follow-head.branch)\" = \"HEAD\"\n+\t)\n+'\n+\n+test_expect_success 'submodule add --local-branch --branch' '\n+\t(\n+\t\tcd addtest &&\n+\t\tgit submodule add --local-branch -b initial \"$submodurl\" submod-auto-follow &&\n+\t\ttest \"$(git config -f .gitmodules submodule.submod-auto-follow.branch)\" = \"initial\"\n+\t)\n+'\n+\n+test_expect_success 'submodule add --local-branch= --branch' '\n+\t(\n+\t\tcd addtest &&\n+\t\tgit submodule add --local-branch=final -b initial \"$submodurl\" submod-follow &&\n+\t\ttest \"$(git config -f .gitmodules submodule.submod-follow.branch)\" = \"final\"\n+\t)\n+'\n+\n test_expect_success 'setup - add an example entry to .gitmodules' '\n \tGIT_CONFIG=.gitmodules \\\n \tgit config submodule.example.url git://example.com/init.git\n-- \n1.8.0.3.g95edff1.dirty\n"},{"id":"203928","messageId":"6734714e90064b3932126565e3027d7edcf45d51.1353962698.git.wking@tremily.us","threadId":"32045","inReplyTo":"cover.1353962698.git.wking@tremily.us","subject":"[PATCH v4 2/4] git-submodule init: Record submodule..branch in repository config.","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-26T21:00:17Z","receivedAt":"2012-11-26T21:00:17Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nThis allows users to override the .gitmodules value with a\nper-repository value.\n\nSigned-off-by: W. Trevor King \n---\n Documentation/config.txt | 9 +++++----\n git-submodule.sh | 7 +++++++\n t/t7400-submodule-basic.sh | 18 ++++++++++++++++++\n 3 files changed, 30 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 11f320b..1304499 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1994,10 +1994,11 @@ status.submodulesummary::\n submodule..path::\n submodule..url::\n submodule..update::\n-\tThe path within this project, URL, and the updating strategy\n-\tfor a submodule. These variables are initially populated\n-\tby 'git submodule init'; edit them to override the\n-\tURL and other values found in the `.gitmodules` file. See\n+submodule..branch::\n+\tThe path within this project, URL, the updating strategy, and the\n+\tlocal branch name for a submodule. These variables are initially\n+\tpopulated by 'git submodule init'; edit them to override the URL and\n+\tother values found in the `.gitmodules` file. See\n \tlinkgit:git-submodule[1] and linkgit:gitmodules[5] for details.\n \n submodule..fetchRecurseSubmodules::\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 6eed008..c51b6ae 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -505,6 +505,13 @@ cmd_init()\n \t\ttest -n \"$(git config submodule.\"$name\".update)\" ||\n \t\tgit config submodule.\"$name\".update \"$upd\" ||\n \t\tdie \"$(eval_gettext \"Failed to register update mode for submodule path '\\$sm_path'\")\"\n+\n+\t\t# Copy \"branch\" setting when it is not set yet\n+\t\tbranch=\"$(git config -f .gitmodules submodule.\"$name\".branch)\"\n+\t\ttest -z \"$branch\" ||\n+\t\ttest -n \"$(git config submodule.\"$name\".branch)\" ||\n+\t\tgit config submodule.\"$name\".branch \"$branch\" ||\n+\t\tdie \"$(eval_gettext \"Failed to register branch for submodule path '\\$sm_path'\")\"\n \tdone\n }\n \ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex fc08647..3dc8237 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -236,6 +236,24 @@ test_expect_success 'submodule add --local-branch= --branch' '\n \t)\n '\n \n+test_expect_success 'init should register submodule branch in .git/config' '\n+\t(\n+\t\tcd addtest &&\n+\t\tgit submodule init &&\n+\t\ttest \"$(git config submodule.submod-follow.branch)\" = \"final\"\n+\t)\n+'\n+\n+test_expect_success 'local config should override .gitmodules branch' '\n+\t(\n+\t\tcd addtest &&\n+\t\trm -fr submod-follow &&\n+\t\tgit config submodule.submod-follow.branch initial\n+\t\tgit submodule init &&\n+\t\ttest \"$(git config submodule.submod-follow.branch)\" = \"initial\"\n+\t)\n+'\n+\n test_expect_success 'setup - add an example entry to .gitmodules' '\n \tGIT_CONFIG=.gitmodules \\\n \tgit config submodule.example.url git://example.com/init.git\n-- \n1.8.0.3.g95edff1.dirty\n"},{"id":"203930","messageId":"95edff1c97c513c555652014f9c2bbf61c8e7560.1353962698.git.wking@tremily.us","threadId":"32045","inReplyTo":"cover.1353962698.git.wking@tremily.us","subject":"[PATCH v4 3/4] git-submodule update: Add --branch option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-26T21:00:18Z","receivedAt":"2012-11-26T21:00:18Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nThis allows users to checkout the current\nsuperproject-recorded-submodule-sha as a branch, avoiding the detached\nhead state that the standard submodule update creates. This may be\nuseful for the existing --rebase/--merge workflows which already avoid\ndetached heads.\n\nIt is also useful if you want easy tracking of upstream branches. The\nparticular upstream branch to be tracked is configured locally with\n.git/modules//config. With the new option Ævar's suggested\n\n $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitm\nodules submodule.$name.branch) && git pull'\n\nreduces to a\n\n $ git submodule update --branch\n\nafter each supermodule .gitmodules edit, and a\n\n $ git submodule foreach 'git pull'\n\nwhenever you feel like updating the submodules. Your still on you're\nown to commit (or not) the updated submodule hashes in the\nsuperproject's .gitmodules.\n\nSigned-off-by: W. Trevor King \n---\n Documentation/git-submodule.txt | 20 +++++++++++------\n git-submodule.sh | 48 +++++++++++++++++++++++++++++----------\n t/t7406-submodule-update.sh | 50 ++++++++++++++++++++++++++++++++++++++++-\n 3 files changed, 98 insertions(+), 20 deletions(-)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex d0b4436..34392a1 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -13,7 +13,7 @@ SYNOPSIS\n \t [-f|--force] [--reference ] [--] []\n 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]\n 'git submodule' [--quiet] init [--] [...]\n-'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]\n+'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--branch] [--rebase]\n \t [--reference ] [--merge] [--recursive] [--] [...]\n 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]\n \t [commit] [--] [...]\n@@ -136,11 +136,11 @@ init::\n \n update::\n \tUpdate the registered submodules, i.e. clone missing submodules and\n-\tcheckout the commit specified in the index of the containing repository.\n-\tThis will make the submodules HEAD be detached unless `--rebase` or\n-\t`--merge` is specified or the key `submodule.$name.update` is set to\n-\t`rebase`, `merge` or `none`. `none` can be overridden by specifying\n-\t`--checkout`.\n+\tcheckout the commit specified in the index of the containing\n+\trepository. This will make the submodules HEAD be detached unless\n+\t`--branch`, `--rebase`, `--merge` is specified or the key\n+\t`submodule.$name.update` is set to `branch`, `rebase`, `merge` or\n+\t`none`. `none` can be overridden by specifying `--checkout`.\n +\n If the submodule is not yet initialized, and you just want to use the\n setting as stored in .gitmodules, you can automatically initialize the\n@@ -207,7 +207,13 @@ OPTIONS\n \n -b::\n --branch::\n-\tBranch of repository to add as submodule.\n+\tWhen used with the add command, gives the branch of repository to\n+\tadd as submodule.\n++\n+When used with the update command, checks out a branch named\n+`submodule..branch` (as set by `--local-branch`) pointing at the\n+current HEAD SHA-1. This is useful for commands like `update\n+--rebase` that do not work on detached heads.\n \n --local-branch::\n \tRecord a branch name used as `submodule..branch` in\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex c51b6ae..28eb4b1 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -8,7 +8,7 @@ dashless=$(basename \"$0\" | sed -e 's/-/ /')\n USAGE=\"[--quiet] add [-b branch] [--local-branch[=]] [-f|--force] [--reference ] [--] []\n or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]\n or: $dashless [--quiet] init [--] [...]\n- or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n+ or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--branch] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ] [commit] [--] [...]\n or: $dashless [--quiet] foreach [--recursive] \n or: $dashless [--quiet] sync [--] [...]\"\n@@ -539,6 +539,9 @@ cmd_update()\n \t\t-f|--force)\n \t\t\tforce=$1\n \t\t\t;;\n+\t\t-b|--branch)\n+\t\t\tupdate=\"branch\"\n+\t\t\t;;\n \t\t-r|--rebase)\n \t\t\tupdate=\"rebase\"\n \t\t\t;;\n@@ -593,6 +596,7 @@ cmd_update()\n \t\tfi\n \t\tname=$(module_name \"$sm_path\") || exit\n \t\turl=$(git config submodule.\"$name\".url)\n+\t\tbranch=$(git config submodule.\"$name\".branch)\n \t\tif ! test -z \"$update\"\n \t\tthen\n \t\t\tupdate_module=$update\n@@ -627,7 +631,7 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\tdie \"$(eval_gettext \"Unable to find current revision in submodule path '\\$sm_path'\")\"\n \t\tfi\n \n-\t\tif test \"$subsha1\" != \"$sha1\" -o -n \"$force\"\n+\t\tif test \"$subsha1\" != \"$sha1\" -o -n \"$force\" -o \"$update_module\" = \"branch\"\n \t\tthen\n \t\t\tsubforce=$force\n \t\t\t# If we don't already have a -f flag and the submodule has never been checked out\n@@ -650,16 +654,21 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\tcase \";$cloned_modules;\" in\n \t\t\t*\";$name;\"*)\n \t\t\t\t# then there is no local change to integrate\n-\t\t\t\tupdate_module= ;;\n+\t\t\t\tcase \"$update_module\" in\n+\t\t\t\t\trebase|merge)\n+\t\t\t\t\t\tupdate_module=\n+\t\t\t\t\t\t;;\n+\t\t\t\tesac\n+\t\t\t\t;;\n \t\t\tesac\n \n \t\t\tmust_die_on_failure=\n \t\t\tcase \"$update_module\" in\n \t\t\trebase)\n \t\t\t\tcommand=\"git rebase\"\n-\t\t\t\tdie_msg=\"$(eval_gettext \"Unable to rebase '\\$sha1' in submodule path '\\$sm_path'\")\"\n+\t\t\t\tdie_msg=\"$(eval_gettext \"Unable to rebase '\\$sha1' in submodule path '\\$sm_path'\")\"\t\n \t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$sm_path': rebased into '\\$sha1'\")\"\n-\t\t\t\tmust_die_on_failure=yes\n+\t\t\tmust_die_on_failure=yes\n \t\t\t\t;;\n \t\t\tmerge)\n \t\t\t\tcommand=\"git merge\"\n@@ -674,15 +683,30 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\t\t;;\n \t\t\tesac\n \n-\t\t\tif (clear_local_git_env; cd \"$sm_path\" && $command \"$sha1\")\n+\t\t\tif test \"$subsha1\" != \"$sha1\" -o -n \"$force\"\n \t\t\tthen\n-\t\t\t\tsay \"$say_msg\"\n-\t\t\telif test -n \"$must_die_on_failure\"\n+\t\t\t\tif (clear_local_git_env; cd \"$sm_path\" && $command \"$sha1\")\n+\t\t\t\tthen\n+\t\t\t\t\tsay \"$say_msg\"\n+\t\t\t\telif test -n \"$must_die_on_failure\"\n+\t\t\t\tthen\n+\t\t\t\t\tdie_with_status 2 \"$die_msg\"\n+\t\t\t\telse\n+\t\t\t\t\terr=\"${err};$die_msg\"\n+\t\t\t\t\tcontinue\n+\t\t\t\tfi\n+\t\t\tfi\n+\n+\t\t\tif test \"$update_module\" = \"branch\" -a -n \"$branch\"\n \t\t\tthen\n-\t\t\t\tdie_with_status 2 \"$die_msg\"\n-\t\t\telse\n-\t\t\t\terr=\"${err};$die_msg\"\n-\t\t\t\tcontinue\n+\t\t\t\tif (clear_local_git_env; cd \"$sm_path\" &&\n+\t\t\t\t\tgit branch -f \"$branch\" \"$sha1\" &&\n+\t\t\t\t\tgit checkout \"$branch\")\n+\t\t\t\tthen\n+\t\t\t\t\tsay \"$(eval_gettext \"Submodule path '\\$sm_path': checked out branch '\\$branch'\")\"\n+\t\t\t\telse\n+\t\t\t\t\terr=\"${err};$(eval_gettext \"Unable to checkout branch '\\$branch' in submodule path '\\$sm_path'\")\"\n+\t\t\t\tfi\n \t\t\tfi\n \t\tfi\n \ndiff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\nindex 1542653..c876a8b 100755\n--- a/t/t7406-submodule-update.sh\n+++ b/t/t7406-submodule-update.sh\n@@ -6,7 +6,8 @@\n test_description='Test updating submodules\n \n This test verifies that \"git submodule update\" detaches the HEAD of the\n-submodule and \"git submodule update --rebase/--merge\" does not detach the HEAD.\n+submodule and \"git submodule update --branch/--rebase/--merge\" does not\n+detach the HEAD.\n '\n \n . ./test-lib.sh\n@@ -135,6 +136,53 @@ test_expect_success 'submodule update --force forcibly checks out submodules' '\n \t)\n '\n \n+test_expect_success 'submodule update --branch detaches without submodule..branch' '\n+\t(cd super/submodule &&\n+\t git checkout master\n+\t) &&\n+\t(cd super &&\n+\t (cd submodule &&\n+\t compare_head\n+\t ) &&\n+\t git submodule update --branch submodule &&\n+\t (cd submodule &&\n+\t test \"$(git status -s file)\" = \"\"\n+\t )\n+\t)\n+'\n+\n+test_expect_success 'submodule update --branch staying on master' '\n+\t(cd super/submodule &&\n+\t git checkout master\n+\t) &&\n+\t(cd super &&\n+\t (cd submodule &&\n+\t compare_head\n+\t ) &&\n+\t git config submodule.submodule.branch master\n+\t git submodule update --branch submodule &&\n+\t cd submodule &&\n+\t test \"refs/heads/master\" = \"$(git symbolic-ref -q HEAD)\" &&\n+\t compare_head\n+\t)\n+'\n+\n+test_expect_success 'submodule update --branch creating a new branch' '\n+\t(cd super/submodule &&\n+\t git checkout master\n+\t) &&\n+\t(cd super &&\n+\t (cd submodule &&\n+\t compare_head\n+\t ) &&\n+\t git config submodule.submodule.branch new-branch\n+\t git submodule update --branch submodule &&\n+\t cd submodule &&\n+\t test \"refs/heads/new-branch\" = \"$(git symbolic-ref -q HEAD)\" &&\n+\t compare_head\n+\t)\n+'\n+\n test_expect_success 'submodule update --rebase staying on master' '\n \t(cd super/submodule &&\n \t git checkout master\n-- \n1.8.0.3.g95edff1.dirty\n"},{"id":"203929","messageId":"30459164cc221165a20cd4a54daac76ddb101269.1353962698.git.wking@tremily.us","threadId":"32045","inReplyTo":"cover.1353962698.git.wking@tremily.us","subject":"[PATCH v4 4/4] Hack fix for 'submodule update does not fetch already present commits'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-26T21:00:19Z","receivedAt":"2012-11-26T21:00:19Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\n---\n git-submodule.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 28eb4b1..f4a681c 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -640,7 +640,7 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\t\tsubforce=\"-f\"\n \t\t\tfi\n \n-\t\t\tif test -z \"$nofetch\"\n+\t\t\tif test -z \"$nofetch\" -a \"$subsha1\" != \"$sha1\"\n \t\t\tthen\n \t\t\t\t# Run fetch only if $sha1 isn't present or it\n \t\t\t\t# is not reachable from a ref.\n-- \n1.8.0.3.g95edff1.dirty\n"},{"id":"204012","messageId":"20121127183125.GA4185@book.hvoigt.net","threadId":"32045","inReplyTo":"cover.1353962698.git.wking@tremily.us","subject":"Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-11-27T18:31:25Z","receivedAt":"2012-11-27T18:31:25Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote:\n> From: \"W. Trevor King\" \n> \n> On Fri, Nov 23, 2012 at 12:54:02PM -0500, W. Trevor King wrote:\n> > We could add\n> >\n> > $ git submodule update --branch\n> >\n> > to checkout the gitlinked SHA1 as submodule..branch in each of\n> > the submodules, leaving the submodules on the .gitmodules-configured\n> > branch. Effectively (for each submodule):\n> >\n> > $ git branch -f $branch $sha1\n> > $ git checkout $branch\n> \n> I haven't gotten any feedback on this as an idea, but perhaps someone\n> will comment on it as a patch series ;).\n\nI am not sure I understand you correctly. You are suggesting that the\nbranch option as an alias for the registered SHA1 in the superproject?\n\nI though the goal of your series was that you want to track submodules\nbranch which come from the remote side?\n\nDoing the above does not assist you much in that does it?\n\nI would think more of some convention like:\n\n\t$ git checkout -t origin/$branch\n\nwhen first initialising the submodule with e.g.\n\n\t$ git submodule update --init --branch\n\nThen later calls of\n\n\t$ git submodule update --branch\n\nwould have a branch configured to pull from. I imagine that results in\na similar behavior gerrit is doing on the server side?\n\n> Changes since v3:\n> \n> * --record=??? is now --local-branch=???\n> * Dropped patches 2 ($submodule_ export) and 3 (motivating documentation)\n> * Added local git-config overrides of .gitmodules' submodule..branch\n> * Added `submodule update --branch`\n\nI would prefer if we could squash all these commits together into one\nsince it seems to me one logical step, using the new variable for update\nbelongs together with its configuration on initialization.\n\nHow about reusing the -b|--branch option for add? Since we only change\nthe behavior when submodule.$name.update is set to branch it seems\nreasonable to me. Opinions?\n\n> Because you need to recurse through submodules for `update --branch`\n> even if \"$subsha1\" == \"$sha1\", I had to amend the conditional\n> controlling that block. This broke one of the existing tests, which I\n> \"fixed\" in patch 4. I think a proper fix would involve rewriting\n> \n> (clear_local_git_env; cd \"$sm_path\" &&\n> ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&\n> test -z \"$rev\") || git-fetch)) ||\n> die \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n> \n> but I'm not familiar enough with rev-list to want to dig into that\n> yet. If feedback for the earlier three patches is positive, I'll work\n> up a clean fix and resubmit.\n\nYou probably need to separate your handling here. The comparison of the\ncurrently checked out sha1 and the recorded sha1 is an optimization\nwhich skips unnecessary fetching in case the submodules commits are\nalready correct. This code snippet checks whether the to be checked out\nsha1 is already local and also skips the fetch if it is. We should not\nbreak that.\n\nMaybe we need an else block here and possibly extract the current code\ninside the if statement into a function. E.g. that the final code looks\nsomething like this:\n\n\tif test \"$subsha1\" != \"$sha1\"\n\tthen\n\t\thandle_on_demand_fetch_update ...\n\telse\n\t\thandle_tracked_branch_update ...\n\tfi\n\nNot sure about the function names though. If we decide to go that route:\nThe extraction into a function should go in an extra preparation patch\nwhich does not change any functionality.\n\nI will reply to the patches for further comments.\n\nCheers Heiko\n"},{"id":"204014","messageId":"20121127185142.GB4185@book.hvoigt.net","threadId":"32045","inReplyTo":"95edff1c97c513c555652014f9c2bbf61c8e7560.1353962698.git.wking@tremily.us","subject":"Re: [PATCH v4 3/4] git-submodule update: Add --branch option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-11-27T18:51:42Z","receivedAt":"2012-11-27T18:51:42Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Mon, Nov 26, 2012 at 04:00:18PM -0500, W. Trevor King wrote:\n> From: \"W. Trevor King\" \n> \n> This allows users to checkout the current\n> superproject-recorded-submodule-sha as a branch, avoiding the detached\n> head state that the standard submodule update creates. This may be\n> useful for the existing --rebase/--merge workflows which already avoid\n> detached heads.\n> \n> It is also useful if you want easy tracking of upstream branches. The\n> particular upstream branch to be tracked is configured locally with\n> .git/modules//config. With the new option Ævar's suggested\n> \n> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitm\n> odules submodule.$name.branch) && git pull'\n> \n> reduces to a\n> \n> $ git submodule update --branch\n> \n> after each supermodule .gitmodules edit, and a\n> \n> $ git submodule foreach 'git pull'\n> \n> whenever you feel like updating the submodules. Your still on you're\n> own to commit (or not) the updated submodule hashes in the\n> superproject's .gitmodules.\n> \n> Signed-off-by: W. Trevor King \n> ---\n> Documentation/git-submodule.txt | 20 +++++++++++------\n> git-submodule.sh | 48 +++++++++++++++++++++++++++++----------\n> t/t7406-submodule-update.sh | 50 ++++++++++++++++++++++++++++++++++++++++-\n> 3 files changed, 98 insertions(+), 20 deletions(-)\n> \n> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> index d0b4436..34392a1 100644\n> --- a/Documentation/git-submodule.txt\n> +++ b/Documentation/git-submodule.txt\n> @@ -13,7 +13,7 @@ SYNOPSIS\n> \t [-f|--force] [--reference ] [--] []\n> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]\n> 'git submodule' [--quiet] init [--] [...]\n> -'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]\n> +'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--branch] [--rebase]\n> \t [--reference ] [--merge] [--recursive] [--] [...]\n> 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]\n> \t [commit] [--] [...]\n> @@ -136,11 +136,11 @@ init::\n> \n> update::\n> \tUpdate the registered submodules, i.e. clone missing submodules and\n> -\tcheckout the commit specified in the index of the containing repository.\n> -\tThis will make the submodules HEAD be detached unless `--rebase` or\n> -\t`--merge` is specified or the key `submodule.$name.update` is set to\n> -\t`rebase`, `merge` or `none`. `none` can be overridden by specifying\n> -\t`--checkout`.\n> +\tcheckout the commit specified in the index of the containing\n> +\trepository. This will make the submodules HEAD be detached unless\n> +\t`--branch`, `--rebase`, `--merge` is specified or the key\n> +\t`submodule.$name.update` is set to `branch`, `rebase`, `merge` or\n> +\t`none`. `none` can be overridden by specifying `--checkout`.\n> +\n> If the submodule is not yet initialized, and you just want to use the\n> setting as stored in .gitmodules, you can automatically initialize the\n> @@ -207,7 +207,13 @@ OPTIONS\n> \n> -b::\n> --branch::\n> -\tBranch of repository to add as submodule.\n> +\tWhen used with the add command, gives the branch of repository to\n> +\tadd as submodule.\n> ++\n> +When used with the update command, checks out a branch named\n> +`submodule..branch` (as set by `--local-branch`) pointing at the\n> +current HEAD SHA-1. This is useful for commands like `update\n> +--rebase` that do not work on detached heads.\n\nSince you are reusing this option for update it further convinces me\nthat reusing it for add makes sense and simplifies the logic for users.\n\nI think an optional argument for --branch would be nice in the update\ncase:\n\n\t$ git submodule update --branch=master\n\nwould then allow a user that has not configured anything (except the\nbranch tracking info in the submodule of course) to pull all submodules\nmaster branches.\n\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index c51b6ae..28eb4b1 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -627,7 +631,7 @@ Maybe you want to use 'update --init'?\")\"\n> \t\t\tdie \"$(eval_gettext \"Unable to find current revision in submodule path '\\$sm_path'\")\"\n> \t\tfi\n> \n> -\t\tif test \"$subsha1\" != \"$sha1\" -o -n \"$force\"\n> +\t\tif test \"$subsha1\" != \"$sha1\" -o -n \"$force\" -o \"$update_module\" = \"branch\"\n\nAs said before I think separating your code from the current update\nlogic will simplify the handling below.\n\n> \t\tthen\n> \t\t\tsubforce=$force\n> \t\t\t# If we don't already have a -f flag and the submodule has never been checked out\n> @@ -650,16 +654,21 @@ Maybe you want to use 'update --init'?\")\"\n> \t\t\tcase \";$cloned_modules;\" in\n> \t\t\t*\";$name;\"*)\n> \t\t\t\t# then there is no local change to integrate\n> -\t\t\t\tupdate_module= ;;\n> +\t\t\t\tcase \"$update_module\" in\n> +\t\t\t\t\trebase|merge)\n> +\t\t\t\t\t\tupdate_module=\n> +\t\t\t\t\t\t;;\n> +\t\t\t\tesac\n> +\t\t\t\t;;\n> \t\t\tesac\n> \n> \t\t\tmust_die_on_failure=\n> \t\t\tcase \"$update_module\" in\n> \t\t\trebase)\n> \t\t\t\tcommand=\"git rebase\"\n> -\t\t\t\tdie_msg=\"$(eval_gettext \"Unable to rebase '\\$sha1' in submodule path '\\$sm_path'\")\"\n> +\t\t\t\tdie_msg=\"$(eval_gettext \"Unable to rebase '\\$sha1' in submodule path '\\$sm_path'\")\"\t\n> \t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$sm_path': rebased into '\\$sha1'\")\"\n> -\t\t\t\tmust_die_on_failure=yes\n> +\t\t\tmust_die_on_failure=yes\n\nPlease always cleanup whitespace changes.\n\n> \t\t\t\t;;\n> \t\t\tmerge)\n> \t\t\t\tcommand=\"git merge\"\n> @@ -674,15 +683,30 @@ Maybe you want to use 'update --init'?\")\"\n> \t\t\t\t;;\n> \t\t\tesac\n> \n> \t\t\tthen\n> -\t\t\t\tdie_with_status 2 \"$die_msg\"\n> -\t\t\telse\n> -\t\t\t\terr=\"${err};$die_msg\"\n> -\t\t\t\tcontinue\n> +\t\t\t\tif (clear_local_git_env; cd \"$sm_path\" &&\n> +\t\t\t\t\tgit branch -f \"$branch\" \"$sha1\" &&\n> +\t\t\t\t\tgit checkout \"$branch\")\n\nYou wrote in earlier emails that you wanted to protect the user from\nnon-fastforward changes. So I would expect a\n\n\t$ git pull --ff-only\n\nhere and the setup of that in the initialization of the submodule.\n\nBTW, I am more and more convinced that an automatically manufactured\ncommit on update with --branch should be the default. What do other\nthink? Sascha raised a concern that he would not want this, but as far as\nI understood he let the CI-server do that so I see no downside to\nnatively adding that to git. People who want to manually craft those\ncommits can still amend the generated commit. Since this is all about\nhelping people keeping their submodules updated why not go the full way?\n\nCheers Heiko\n"},{"id":"204018","messageId":"20121127190105.GQ10656@odin.tremily.us","threadId":"32045","inReplyTo":"20121127183125.GA4185@book.hvoigt.net","subject":"Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-27T19:01:05Z","receivedAt":"2012-11-27T19:01:05Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:\n> On Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote:\n> > From: \"W. Trevor King\" \n> > \n> > On Fri, Nov 23, 2012 at 12:54:02PM -0500, W. Trevor King wrote:\n> > > We could add\n> > >\n> > > $ git submodule update --branch\n> > >\n> > > to checkout the gitlinked SHA1 as submodule..branch in each of\n> > > the submodules, leaving the submodules on the .gitmodules-configured\n> > > branch. Effectively (for each submodule):\n> > >\n> > > $ git branch -f $branch $sha1\n> > > $ git checkout $branch\n> > \n> > I haven't gotten any feedback on this as an idea, but perhaps someone\n> > will comment on it as a patch series ;).\n> \n> I am not sure I understand you correctly. You are suggesting that the\n> branch option as an alias for the registered SHA1 in the superproject?\n> \n> I though the goal of your series was that you want to track submodules\n> branch which come from the remote side?\n\nThat's what I'd initially thought, but when I went to implement\n`update --pull`, I realized that\n\n $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && …'\n\nis using submodule..branch as the local branch name. The remote\nbranch name was actually setup in .git/modules//config during\nthe initial \"clone -b …\".\n\nThe v4 series leaves the remote branch amigious, but it helps you\npoint the local branch at the right hash so that future calls to\n\n $ git submodule foreach 'git pull'\n\ncan use the branch's .git/modules//config settings.\n\n> I would think more of some convention like:\n> \n> \t$ git checkout -t origin/$branch\n> \n> when first initialising the submodule with e.g.\n> \n> \t$ git submodule update --init --branch\n> \n> Then later calls of\n> \n> \t$ git submodule update --branch\n> \n> would have a branch configured to pull from. I imagine that results in\n> a similar behavior gerrit is doing on the server side?\n\nThat sounds like it's doing pretty much the same thing. Can you think\nof a test that would distinguish it from my current v4 implementation?\n\n> > Changes since v3:\n> > \n> > * --record=??? is now --local-branch=???\n> > * Dropped patches 2 ($submodule_ export) and 3 (motivating documentation)\n> > * Added local git-config overrides of .gitmodules' submodule..branch\n> > * Added `submodule update --branch`\n> \n> I would prefer if we could squash all these commits together into one\n> since it seems to me one logical step, using the new variable for update\n> belongs together with its configuration on initialization.\n> \n> How about reusing the -b|--branch option for add? Since we only change\n> the behavior when submodule.$name.update is set to branch it seems\n> reasonable to me. Opinions?\n\nThat was the approach I used in v1, but people were concerned that we\nwould be stomping on previously unclaimed config space. Since noone\nhas pointed out other uses besides Gerrit's very similar case, I'm not\nsure if that is still an issue.\n\n> > Because you need to recurse through submodules for `update --branch`\n> > even if \"$subsha1\" == \"$sha1\", I had to amend the conditional\n> > controlling that block. This broke one of the existing tests, which I\n> > \"fixed\" in patch 4. I think a proper fix would involve rewriting\n> > \n> > (clear_local_git_env; cd \"$sm_path\" &&\n> > ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&\n> > test -z \"$rev\") || git-fetch)) ||\n> > die \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n> > \n> > but I'm not familiar enough with rev-list to want to dig into that\n> > yet. If feedback for the earlier three patches is positive, I'll work\n> > up a clean fix and resubmit.\n> \n> You probably need to separate your handling here. The comparison of the\n> currently checked out sha1 and the recorded sha1 is an optimization\n> which skips unnecessary fetching in case the submodules commits are\n> already correct. This code snippet checks whether the to be checked out\n> sha1 is already local and also skips the fetch if it is. We should not\n> break that.\n\nAgreed. However, determining if the target $sha1 is local should have\nnothing to do with the current checked out $subsha1.\n\nThanks for the feedback!\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"204015","messageId":"20121127190400.GA15213@odin.tremily.us","threadId":"32045","inReplyTo":"20121127183125.GA4185@book.hvoigt.net","subject":"Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-27T19:04:00Z","receivedAt":"2012-11-27T19:04:00Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:\n> I would prefer if we could squash all these commits together into\n> one since it seems to me one logical step, using the new variable\n> for update belongs together with its configuration on\n> initialization.\n\nWorks for me. I could also try to rework the patch boundaries if a\nmonolithic patch is not acceptable. I agree that the current\ndocumentation assignments are fairly arbitrary. If I don't hear from\nanyone in favor of keeping them separate, v5 will be monolithic.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"204017","messageId":"20121127191628.GC4185@book.hvoigt.net","threadId":"32045","inReplyTo":"20121127183125.GA4185@book.hvoigt.net","subject":"Re: Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-11-27T19:16:28Z","receivedAt":"2012-11-27T19:16:28Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nI just realized that I gave you an confusing suggestion.\n\nOn Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:\n> \tif test \"$subsha1\" != \"$sha1\"\n> \tthen\n> \t\thandle_on_demand_fetch_update ...\n> \telse\n> \t\thandle_tracked_branch_update ...\n> \tfi\n\nThat obviously does not work. Here I meant of course something like:\n\n \tif test \"$update_module\" = \"branch\"\n \tthen\n \t\thandle_tracked_branch_update ...\n \telse\n \t\thandle_on_demand_fetch_update ...\n \tfi\n\nCheers Heiko\n"},{"id":"204019","messageId":"20121127202103.GD15213@odin.tremily.us","threadId":"32045","inReplyTo":"20121127185142.GB4185@book.hvoigt.net","subject":"Re: [PATCH v4 3/4] git-submodule update: Add --branch option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-27T20:21:03Z","receivedAt":"2012-11-27T20:21:03Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Tue, Nov 27, 2012 at 07:51:42PM +0100, Heiko Voigt wrote:\n> On Mon, Nov 26, 2012 at 04:00:18PM -0500, W. Trevor King wrote:\n> > -b::\n> > --branch::\n> > -\tBranch of repository to add as submodule.\n> > +\tWhen used with the add command, gives the branch of repository to\n> > +\tadd as submodule.\n> > ++\n> > +When used with the update command, checks out a branch named\n> > +`submodule..branch` (as set by `--local-branch`) pointing at the\n> > +current HEAD SHA-1. This is useful for commands like `update\n> > +--rebase` that do not work on detached heads.\n> \n> Since you are reusing this option for update it further convinces me\n> that reusing it for add makes sense and simplifies the logic for users.\n> \n> I think an optional argument for --branch would be nice in the update\n> case:\n> \n> \t$ git submodule update --branch=master\n> \n> would then allow a user that has not configured anything (except the\n> branch tracking info in the submodule of course) to pull all submodules\n> master branches.\n\nSounds good to me. Remember that this is checking the branch and\npointing it at $sha1 (preparing for the pull), not pulling remote\nbranches. The pull happens in a later\n\n $ git submodules foreach 'git pull'\n\n> > diff --git a/git-submodule.sh b/git-submodule.sh\n> > index c51b6ae..28eb4b1 100755\n> > --- a/git-submodule.sh\n> > +++ b/git-submodule.sh\n> > @@ -627,7 +631,7 @@ Maybe you want to use 'update --init'?\")\"\n> > \t\t\tdie \"$(eval_gettext \"Unable to find current revision in submodule path '\\$sm_path'\")\"\n> > \t\tfi\n> > \n> > -\t\tif test \"$subsha1\" != \"$sha1\" -o -n \"$force\"\n> > +\t\tif test \"$subsha1\" != \"$sha1\" -o -n \"$force\" -o \"$update_module\" = \"branch\"\n> \n> As said before I think separating your code from the current update\n> logic will simplify the handling below.\n\nThis felt less invasive (it avoids duplicating the recursion logic),\nbut I don't mind breaking it into a separate function/block.\n\n> > \t\t\tmust_die_on_failure=\n> > \t\t\tcase \"$update_module\" in\n> > \t\t\trebase)\n> > \t\t\t\tcommand=\"git rebase\"\n> > -\t\t\t\tdie_msg=\"$(eval_gettext \"Unable to rebase '\\$sha1' in submodule path '\\$sm_path'\")\"\n> > +\t\t\t\tdie_msg=\"$(eval_gettext \"Unable to rebase '\\$sha1' in submodule path '\\$sm_path'\")\"\t\n> > \t\t\t\tsay_msg=\"$(eval_gettext \"Submodule path '\\$sm_path': rebased into '\\$sha1'\")\"\n> > -\t\t\t\tmust_die_on_failure=yes\n> > +\t\t\tmust_die_on_failure=yes\n> \n> Please always cleanup whitespace changes.\n\nOops, sloppy me. Will fix.\n\n> > \t\t\tthen\n> > -\t\t\t\tdie_with_status 2 \"$die_msg\"\n> > -\t\t\telse\n> > -\t\t\t\terr=\"${err};$die_msg\"\n> > -\t\t\t\tcontinue\n> > +\t\t\t\tif (clear_local_git_env; cd \"$sm_path\" &&\n> > +\t\t\t\t\tgit branch -f \"$branch\" \"$sha1\" &&\n> > +\t\t\t\t\tgit checkout \"$branch\")\n> \n> You wrote in earlier emails that you wanted to protect the user from\n> non-fastforward changes. So I would expect a\n> \n> \t$ git pull --ff-only\n\nI'm not pulling here, I'm doing a regular `submodule update`, and\nafter that's done I checkout the branch pointing at the $sha1 to which\nthe branch was just updated. All the submodule-state-clobbering\ncaveats of a usual `submodule update` still apply to this new\n`submodule update --branch`, and I'm fine with that.\n\n> BTW, I am more and more convinced that an automatically manufactured\n> commit on update with --branch should be the default.\n\nAgain, there's nothing to update. The pull happens in a separate\nstep.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"204028","messageId":"20121127211851.GE15213@odin.tremily.us","threadId":"32045","inReplyTo":"30459164cc221165a20cd4a54daac76ddb101269.1353962698.git.wking@tremily.us","subject":"Re: [PATCH v4 4/4] Hack fix for 'submodule update does not fetch already present commits'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-27T21:18:51Z","receivedAt":"2012-11-27T21:18:51Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:\n> On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:\n> > On Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote:\n> > > Because you need to recurse through submodules for `update --branch`\n> > > even if \"$subsha1\" == \"$sha1\", I had to amend the conditional\n> > > controlling that block. This broke one of the existing tests, which I\n> > > \"fixed\" in patch 4. I think a proper fix would involve rewriting\n> > > \n> > > (clear_local_git_env; cd \"$sm_path\" &&\n> > > ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&\n> > > test -z \"$rev\") || git-fetch)) ||\n> > > die \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n> > > \n> > > but I'm not familiar enough with rev-list to want to dig into that\n> > > yet. If feedback for the earlier three patches is positive, I'll work\n> > > up a clean fix and resubmit.\n> > \n> > You probably need to separate your handling here. The comparison of the\n> > currently checked out sha1 and the recorded sha1 is an optimization\n> > which skips unnecessary fetching in case the submodules commits are\n> > already correct. This code snippet checks whether the to be checked out\n> > sha1 is already local and also skips the fetch if it is. We should not\n> > break that.\n> \n> Agreed. However, determining if the target $sha1 is local should have\n> nothing to do with the current checked out $subsha1.\n\nErm, I clearly wasn't getting enough sleep heading into yesterday,\nbecause when I drop the hack patch #4, reinstall, and retest, I no\nlonger get the bad-fetch error. I'm not quite sure what was going on,\nbut please pretend I never mentioned it ;).\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"204057","messageId":"50B54A68.60309@web.de","threadId":"32045","inReplyTo":"6734714e90064b3932126565e3027d7edcf45d51.1353962698.git.wking@tremily.us","subject":"Re: [PATCH v4 2/4] git-submodule init: Record submodule..branch in repository config.","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-11-27T23:19:04Z","receivedAt":"2012-11-27T23:19:04Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 26.11.2012 22:00, schrieb W. Trevor King:\n> From: \"W. Trevor King\" \n> \n> This allows users to override the .gitmodules value with a\n> per-repository value.\n\nYour intentions makes lots of sense, but your patch does more than\nthat. Copying the branch setting into .git/config sets the initial\nbranch setting into stone. That makes it impossible to have a branch\n\"foo\" in the superproject using a branch \"bar\" in a submodule and\nanother superproject branch \"frotz\" using branch \"nitfol\" for the\nsame submodule. You should use the branch setting from .git/config\nif present and fall back to the branch setting from .gitmodules if\nnot, which would enable the user to have her own setting if she\ndoesn't like what upstream provides but would still enable others\nto follow different submodule branches in different superproject\nbranches.\n\n> Signed-off-by: W. Trevor King \n> ---\n> Documentation/config.txt | 9 +++++----\n> git-submodule.sh | 7 +++++++\n> t/t7400-submodule-basic.sh | 18 ++++++++++++++++++\n> 3 files changed, 30 insertions(+), 4 deletions(-)\n> \n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 11f320b..1304499 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -1994,10 +1994,11 @@ status.submodulesummary::\n> submodule..path::\n> submodule..url::\n> submodule..update::\n> -\tThe path within this project, URL, and the updating strategy\n> -\tfor a submodule. These variables are initially populated\n> -\tby 'git submodule init'; edit them to override the\n> -\tURL and other values found in the `.gitmodules` file. See\n> +submodule..branch::\n> +\tThe path within this project, URL, the updating strategy, and the\n> +\tlocal branch name for a submodule. These variables are initially\n> +\tpopulated by 'git submodule init'; edit them to override the URL and\n> +\tother values found in the `.gitmodules` file. See\n> \tlinkgit:git-submodule[1] and linkgit:gitmodules[5] for details.\n> \n> submodule..fetchRecurseSubmodules::\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index 6eed008..c51b6ae 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -505,6 +505,13 @@ cmd_init()\n> \t\ttest -n \"$(git config submodule.\"$name\".update)\" ||\n> \t\tgit config submodule.\"$name\".update \"$upd\" ||\n> \t\tdie \"$(eval_gettext \"Failed to register update mode for submodule path '\\$sm_path'\")\"\n> +\n> +\t\t# Copy \"branch\" setting when it is not set yet\n> +\t\tbranch=\"$(git config -f .gitmodules submodule.\"$name\".branch)\"\n> +\t\ttest -z \"$branch\" ||\n> +\t\ttest -n \"$(git config submodule.\"$name\".branch)\" ||\n> +\t\tgit config submodule.\"$name\".branch \"$branch\" ||\n> +\t\tdie \"$(eval_gettext \"Failed to register branch for submodule path '\\$sm_path'\")\"\n> \tdone\n> }\n> \n> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\n> index fc08647..3dc8237 100755\n> --- a/t/t7400-submodule-basic.sh\n> +++ b/t/t7400-submodule-basic.sh\n> @@ -236,6 +236,24 @@ test_expect_success 'submodule add --local-branch= --branch' '\n> \t)\n> '\n> \n> +test_expect_success 'init should register submodule branch in .git/config' '\n> +\t(\n> +\t\tcd addtest &&\n> +\t\tgit submodule init &&\n> +\t\ttest \"$(git config submodule.submod-follow.branch)\" = \"final\"\n> +\t)\n> +'\n> +\n> +test_expect_success 'local config should override .gitmodules branch' '\n> +\t(\n> +\t\tcd addtest &&\n> +\t\trm -fr submod-follow &&\n> +\t\tgit config submodule.submod-follow.branch initial\n> +\t\tgit submodule init &&\n> +\t\ttest \"$(git config submodule.submod-follow.branch)\" = \"initial\"\n> +\t)\n> +'\n> +\n> test_expect_success 'setup - add an example entry to .gitmodules' '\n> \tGIT_CONFIG=.gitmodules \\\n> \tgit config submodule.example.url git://example.com/init.git\n> \n"},{"id":"204059","messageId":"20121127232858.GA4742@book.hvoigt.net","threadId":"32045","inReplyTo":"20121127190105.GQ10656@odin.tremily.us","subject":"Re: Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-11-27T23:28:58Z","receivedAt":"2012-11-27T23:28:58Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:\n> On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:\n> The v4 series leaves the remote branch amigious, but it helps you\n> point the local branch at the right hash so that future calls to\n> \n> $ git submodule foreach 'git pull'\n> \n> can use the branch's .git/modules//config settings.\n\nBut IMO thats the functionality which should be implemented in submodule\nupdate and not left to the user.\n\n> > I would think more of some convention like:\n> > \n> > \t$ git checkout -t origin/$branch\n> > \n> > when first initialising the submodule with e.g.\n> > \n> > \t$ git submodule update --init --branch\n> > \n> > Then later calls of\n> > \n> > \t$ git submodule update --branch\n> > \n> > would have a branch configured to pull from. I imagine that results in\n> > a similar behavior gerrit is doing on the server side?\n> \n> That sounds like it's doing pretty much the same thing. Can you think\n> of a test that would distinguish it from my current v4 implementation?\n\nWell the main difference is that gerrit is automatically updating the\nsuperproject AFAIK. I would like it if we could implement the same\nworkflow support in the submodule script. It seems to me that this is\nalready proven to be useful workflow.\n\nI do not have a test but a small draft diff (completely untested, quick and\ndirty) to illustrate the approach I am talking about.\n\nYou can find the whole change at\n\nhttps://github.com/hvoigt/git/commits/hv/floating_submodules_draft\n\nand the interesting patch for easy commenting below[1].\n\n> > How about reusing the -b|--branch option for add? Since we only change\n> > the behavior when submodule.$name.update is set to branch it seems\n> > reasonable to me. Opinions?\n> \n> That was the approach I used in v1, but people were concerned that we\n> would be stomping on previously unclaimed config space. Since noone\n> has pointed out other uses besides Gerrit's very similar case, I'm not\n> sure if that is still an issue.\n\nCould you point me to that mail? I cannot seem to find it in my archive.\n\n> > > Because you need to recurse through submodules for `update --branch`\n> > > even if \"$subsha1\" == \"$sha1\", I had to amend the conditional\n> > > controlling that block. This broke one of the existing tests, which I\n> > > \"fixed\" in patch 4. I think a proper fix would involve rewriting\n> > > \n> > > (clear_local_git_env; cd \"$sm_path\" &&\n> > > ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&\n> > > test -z \"$rev\") || git-fetch)) ||\n> > > die \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n> > > \n> > > but I'm not familiar enough with rev-list to want to dig into that\n> > > yet. If feedback for the earlier three patches is positive, I'll work\n> > > up a clean fix and resubmit.\n> > \n> > You probably need to separate your handling here. The comparison of the\n> > currently checked out sha1 and the recorded sha1 is an optimization\n> > which skips unnecessary fetching in case the submodules commits are\n> > already correct. This code snippet checks whether the to be checked out\n> > sha1 is already local and also skips the fetch if it is. We should not\n> > break that.\n> \n> Agreed. However, determining if the target $sha1 is local should have\n> nothing to do with the current checked out $subsha1.\n\nSee my draft or the diff below for an illustration of the splitup.\n\nCheers Heiko\n\n[1]\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 9ad4370..3fa1465 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -183,6 +183,7 @@ module_clone()\n \tsm_path=$1\n \turl=$2\n \treference=\"$3\"\n+\tbranch=\"$4\"\n \tquiet=\n \tif test -n \"$GIT_QUIET\"\n \tthen\n@@ -209,6 +210,8 @@ module_clone()\n \t\t\tclear_local_git_env\n \t\t\tgit clone $quiet -n ${reference:+\"$reference\"} \\\n \t\t\t\t--separate-git-dir \"$gitdir\" \"$url\" \"$sm_path\"\n+\t\t\ttest -n \"$branch\" && (cd $sm_path &&\n+\t\t\t\tgit checkout -t origin/$branch)\n \t\t) ||\n \t\tdie \"$(eval_gettext \"Clone of '\\$url' into submodule path '\\$sm_path' failed\")\"\n \tfi\n@@ -361,7 +364,7 @@ Use -f if you really want to add it.\" >&2\n \n \telse\n \n-\t\tmodule_clone \"$sm_path\" \"$realrepo\" \"$reference\" || exit\n+\t\tmodule_clone \"$sm_path\" \"$realrepo\" \"$reference\" \"$local_branch\" || exit\n \t\t(\n \t\t\tclear_local_git_env\n \t\t\tcd \"$sm_path\" &&\n@@ -577,6 +580,12 @@ handle_on_demand_update () {\n \tfi\n }\n \n+handle_tracking_branch_update () {\n+\t(clear_local_git_env; cd \"$sm_path\" &&\n+\t\tgit-checkout $branch && git-pull --ff-only) ||\n+\tdie \"$(eval_gettext \"Unable to pull branch '\\$branch' in submodule path '\\$sm_path'\")\"\n+}\n+\n #\n # Update each submodule path to correct revision, using clone and checkout as needed\n #\n@@ -648,6 +657,7 @@ cmd_update()\n \tcloned_modules=\n \tmodule_list \"$@\" | {\n \terr=\n+\tfloating_submodules=\n \twhile read mode sha1 stage sm_path\n \tdo\n \t\tdie_if_unmatched \"$mode\"\n@@ -684,7 +694,7 @@ Maybe you want to use 'update --init'?\")\"\n \n \t\tif ! test -d \"$sm_path\"/.git -o -f \"$sm_path\"/.git\n \t\tthen\n-\t\t\tmodule_clone \"$sm_path\" \"$url\" \"$reference\"|| exit\n+\t\t\tmodule_clone \"$sm_path\" \"$url\" \"$reference\" \"$branch\" || exit\n \t\t\tcloned_modules=\"$cloned_modules;$name\"\n \t\t\tsubsha1=\n \t\telse\n@@ -693,7 +703,13 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\tdie \"$(eval_gettext \"Unable to find current revision in submodule path '\\$sm_path'\")\"\n \t\tfi\n \n-\t\thandle_on_demand_update\n+\t\tif test \"$update_module\" = \"branch\"\n+\t\tthen\n+\t\t\thandle_tracking_branch_update\n+\t\t\tfloating_submodules=\"$floating_submodules $sm_path\"\n+\t\telse\n+\t\t\thandle_on_demand_update\n+\t\tfi\n \n \t\tif test -n \"$recursive\"\n \t\tthen\n@@ -727,6 +743,11 @@ Maybe you want to use 'update --init'?\")\"\n \t\tIFS=$OIFS\n \t\texit 1\n \tfi\n+\tif test -n \"$floating_submodules\"\n+\tthen\n+\t\tgit add $floating_submodules &&\n+\t\tgit commit -m \"Updated submodules\"\n+\tfi\n \t}\n }\n"},{"id":"204074","messageId":"20121128004025.GF15213@odin.tremily.us","threadId":"32045","inReplyTo":"50B54A68.60309@web.de","subject":"Re: [PATCH v4 2/4] git-submodule init: Record submodule..branch in repository config.","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-28T00:40:25Z","receivedAt":"2012-11-28T00:40:25Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Wed, Nov 28, 2012 at 12:19:04AM +0100, Jens Lehmann wrote:\n> Am 26.11.2012 22:00, schrieb W. Trevor King:\n> > From: \"W. Trevor King\" \n> > \n> > This allows users to override the .gitmodules value with a\n> > per-repository value.\n> \n> [snip problems]. You should use the branch setting from .git/config\n> if present and fall back to the branch setting from .gitmodules if\n> not, which would enable the user to have her own setting if she\n> doesn't like what upstream provides but would still enable others to\n> follow different submodule branches in different superproject\n> branches.\n\nSounds good. Will fix in v5.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"204108","messageId":"20121128024205.GG15213@odin.tremily.us","threadId":"32045","inReplyTo":"20121127232858.GA4742@book.hvoigt.net","subject":"Re: Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-28T02:42:05Z","receivedAt":"2012-11-28T02:42:05Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Wed, Nov 28, 2012 at 12:28:58AM +0100, Heiko Voigt wrote:\n> On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:\n> > On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:\n> > The v4 series leaves the remote branch amigious, but it helps you\n> > point the local branch at the right hash so that future calls to\n> > \n> > $ git submodule foreach 'git pull'\n> > \n> > can use the branch's .git/modules//config settings.\n> \n> But IMO thats the functionality which should be implemented in submodule\n> update and not left to the user.\n\nThen you might need submodule..local-branch,\nsubmodule..remote-repository, and submodule..remote-branch\nto configure\n\n $ git checkout submodule..local-branch\n $ git pull submodule..remote-repository submodule..remote-branch\n\nand this would ignore the $sha1 stored in the gitlink (which all of\nthe other update commands use). This ignoring-the-$sha1 bit made me\nthink that a built-in pull wasn't a good fit for 'submodule update'.\nMaybe if it went into a new 'submodule pull'? Then users have a clear\ndistinction:\n\n* 'update' to push superproject $sha1 changes into the submodules\n* 'pull' to push upstream-branch changes into the submodules\n\n> > > I would think more of some convention like:\n> > > \n> > > \t$ git checkout -t origin/$branch\n> > > \n> > > when first initialising the submodule with e.g.\n> > > \n> > > \t$ git submodule update --init --branch\n> > > \n> > > Then later calls of\n> > > \n> > > \t$ git submodule update --branch\n> > > \n> > > would have a branch configured to pull from. I imagine that results in\n> > > a similar behavior gerrit is doing on the server side?\n> > \n> > That sounds like it's doing pretty much the same thing. Can you think\n> > of a test that would distinguish it from my current v4 implementation?\n> \n> Well the main difference is that gerrit is automatically updating the\n> superproject AFAIK. I would like it if we could implement the same\n> workflow support in the submodule script. It seems to me that this is\n> already proven to be useful workflow.\n\nAh, sorry, I meant the configuring which remote branch you were\npulling from happens at submodule initialization (via .git/modules/…)\nfor both your workflow and my v4.\n\nYou're right that having a builtin pull is different from my v4.\n\n> https://github.com/hvoigt/git/commits/hv/floating_submodules_draft\n\nI looked over this before, but maybe not thoroughly enough ;).\n\n> > > How about reusing the -b|--branch option for add? Since we only change\n> > > the behavior when submodule.$name.update is set to branch it seems\n> > > reasonable to me. Opinions?\n> > \n> > That was the approach I used in v1, but people were concerned that we\n> > would be stomping on previously unclaimed config space. Since noone\n> > has pointed out other uses besides Gerrit's very similar case, I'm not\n> > sure if that is still an issue.\n> \n> Could you point me to that mail? I cannot seem to find it in my archive.\n\nHmm. It seems like Phil's initial response was (accidentally?) off\nlist. The relevant portion was:\n\nOn Mon, Oct 22, 2012 at 06:03:53PM -0400, Phil Hord wrote:\n> Some projects now use the 'branch' config value to record the tracking\n> branch for the submodule. Some ascribe different meaning to the\n> configuration if the value is given vs. undefined. For example, see\n> the Gerrit submodule-subscription mechanism. This change will cause\n> those workflows to behave differently than they do now.\n>\n> I do like the idea, but I wish it had a different name for the\n> recording. Maybe --record-branch=${BRANCH} as an extra switch so the\n> action is explicitly requested.\n\nAs I said, I'm happy to go back to --branch if opinions have changed.\n\nOn Wed, Nov 28, 2012 at 12:28:58AM +0100, Heiko Voigt wrote:\n> On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:\n> > On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:\n> > > > Because you need to recurse through submodules for `update --branch`\n> > > > even if \"$subsha1\" == \"$sha1\", I had to amend the conditional\n> > > > controlling that block. This broke one of the existing tests, which I\n> > > > \"fixed\" in patch 4. I think a proper fix would involve rewriting\n> > > > \n> > > > (clear_local_git_env; cd \"$sm_path\" &&\n> > > > ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&\n> > > > test -z \"$rev\") || git-fetch)) ||\n> > > > die \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n> > > > \n> > > > but I'm not familiar enough with rev-list to want to dig into that\n> > > > yet. If feedback for the earlier three patches is positive, I'll work\n> > > > up a clean fix and resubmit.\n> > > \n> > > You probably need to separate your handling here. The comparison of the\n> > > currently checked out sha1 and the recorded sha1 is an optimization\n> > > which skips unnecessary fetching in case the submodules commits are\n> > > already correct. This code snippet checks whether the to be checked out\n> > > sha1 is already local and also skips the fetch if it is. We should not\n> > > break that.\n> > \n> > Agreed. However, determining if the target $sha1 is local should have\n> > nothing to do with the current checked out $subsha1.\n> \n> See my draft or the diff below for an illustration of the splitup.\n> \n> [snip diff]\n\nThis looks fine, but my current --branch implementation (which doesn't\npull) is only a thin branch-checkout layer on top of the standard\n`update` functionality. I'm still unsure if built-in pulls are worth\nthe configuration trouble. I'll sleep on it. Maybe I'll feel better\nabout them tomorrow ;).\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"204258","messageId":"20121129161216.GB23580@odin.tremily.us","threadId":"32045","inReplyTo":"20121127185142.GB4185@book.hvoigt.net","subject":"[RFC] git-submodule update: Add --commit option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-29T16:12:17Z","receivedAt":"2012-11-29T16:12:17Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"This option triggers automatic commits when `submodule update` changes\nany gitlinked submodule SHA-1s. The commit message contains a\n`shortlog` summary of the changes for each changed submodule.\n---\n\nOn Tue, Nov 27, 2012 at 07:51:42PM +0100, Heiko Voigt wrote:\n> BTW, I am more and more convinced that an automatically manufactured\n> commit on update with --branch should be the default. What do other\n> think? Sascha raised a concern that he would not want this, but as far as\n> I understood he let the CI-server do that so I see no downside to\n> natively adding that to git. People who want to manually craft those\n> commits can still amend the generated commit. Since this is all about\n> helping people keeping their submodules updated why not go the full way?\n\nHere's a first pass (without documentation) for automatic commits on\nsubmodule updates. There have been a number of requests for\nautomatically-committed submodule updates due to submodule upstreams.\nThis patch shows how you can do that (if applied with my `submodule\nupdate --remote` series), and reuse the same logic to automatically\ncommit changes due to local submodule changes (as shown here in the\nnew test).\n\nI think the logic is pretty good, but the implementation is pretty\nugly due to POSIX shell variable limitations. I'm basically trying to\npass an array of [(name, sm_path, sha1, subsha1), ...] into\ncommit_changes(). I though about perling-out in commit_changes(), but\nI lack sufficient perl-fu to know how to tie clear_local_git_env, cd,\nand shortlog up in a single open2 call. If anyone can give me some\nimplementation pointers, that would be very helpful.\n\nThis is against v1.8.0 (without my --remote series). To apply on top\nof the --remote series, you'd have to save the original gitlinked\n$sha1 and use that original value when constructing changed_modules.\nI can attach this to the end of the --remote series if desired, but I\nthink this patch could also stand on its own.\n\nObviously this still needs documentation, etc., but I wanted feedback\non the implementation before I started digging into that.\n\nCheers,\nTrevor\n\n---\n git-submodule.sh | 67 ++++++++++++++++++++++++++++++++++++++++++++-\n t/t7406-submodule-update.sh | 19 +++++++++++++\n 2 files changed, 85 insertions(+), 1 deletion(-)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex ab6b110..d9a59af 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -8,7 +8,7 @@ dashless=$(basename \"$0\" | sed -e 's/-/ /')\n USAGE=\"[--quiet] add [-b branch] [-f|--force] [--reference ] [--] []\n or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]\n or: $dashless [--quiet] init [--] [...]\n- or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n+ or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--commit] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ] [commit] [--] [...]\n or: $dashless [--quiet] foreach [--recursive] \n or: $dashless [--quiet] sync [--] [...]\"\n@@ -21,6 +21,7 @@ require_work_tree\n command=\n branch=\n force=\n+commit=\n reference=\n cached=\n recursive=\n@@ -240,6 +241,52 @@ module_clone()\n }\n \n #\n+# Commit changed submodule gitlinks\n+#\n+# $1 = name-a;sha1-a;subsha1-a\\n[name-b;sha1-b;subsha1-b\\n...]\n+#\n+commit_changes()\n+{\n+\techo \"commiting $1\"\n+\tOIFS=\"$IFS\"\n+\tIFS=\";\"\n+\tpaths=$(echo \"$1\" |\n+\t\twhile read name sm_path sha1 subsha1\n+\t\tdo\n+\t\t\techo \"$sm_path\"\n+\t\tdone\n+\t\t)\n+\tnames=$(echo \"$1\" |\n+\t\twhile read name sm_path sha1 subsha1\n+\t\tdo\n+\t\t\tprintf ' %s' \"$name\"\n+\t\tdone\n+\t\t)\n+\tsummary=\"$(eval_gettext \"Updated submodules:\")$names\"\n+\tbody=$(echo \"$1\" |\n+\t\twhile read name sm_path sha1 subsha1\n+\t\tdo\n+\t\t\tif test \"$name\" = \"$sm_path\"\n+\t\t\tthen\n+\t\t\t\tprintf 'Changes to %s:\\n\\n' \"$name\"\n+\t\t\telse\n+\t\t\t\tprintf 'Changes to %s (%s):\\n\\n' \"$name\" \"$sm_path\"\n+\t\t\tfi\n+\t\t\t(\n+\t\t\t\tclear_local_git_env\n+\t\t\t\tcd \"$sm_path\" &&\n+\t\t\t\tgit shortlog \"${sha1}..${subsha1}\" ||\n+\t\t\t\tdie \"$(eval_gettext \"Unable to generate shortlog in submodule path '\\$sm_path'\")\"\n+\t\t\t)\n+\t\tdone\n+\t\t)\n+\tIFS=\"$OIFS\"\n+\tmessage=\"$(printf '%s\\n\\n%s\\n' \"$summary\" \"$body\")\"\n+\techo \"message: [$message]\"\n+\tgit commit -m \"$message\" $paths\n+}\n+\n+#\n # Add a new submodule to the working tree, .gitmodules and the index\n #\n # $@ = repo path\n@@ -515,6 +562,9 @@ cmd_update()\n \t\t-f|--force)\n \t\t\tforce=$1\n \t\t\t;;\n+\t\t--commit)\n+\t\t\tcommit=1\n+\t\t\t;;\n \t\t-r|--rebase)\n \t\t\tupdate=\"rebase\"\n \t\t\t;;\n@@ -557,6 +607,7 @@ cmd_update()\n \tfi\n \n \tcloned_modules=\n+\tchanged_modules=\n \tmodule_list \"$@\" | {\n \terr=\n \twhile read mode sha1 stage sm_path\n@@ -660,6 +711,15 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\t\terr=\"${err};$die_msg\"\n \t\t\t\tcontinue\n \t\t\tfi\n+\n+\t\t\tsubsha1=$(clear_local_git_env; cd \"$sm_path\" &&\n+\t\t\t\tgit rev-parse --verify HEAD) ||\n+\t\t\tdie \"$(eval_gettext \"Unable to find new revision in submodule path '\\$sm_path'\")\"\n+\n+\t\t\tif test \"$subsha1\" != \"$sha1\"\n+\t\t\tthen\n+\t\t\t\tchanged_modules=$(printf '%s%s\\n' \"$changed_modules\" \"$name;$sm_path;$sha1;$subsha1\")\n+\t\t\tfi\n \t\tfi\n \n \t\tif test -n \"$recursive\"\n@@ -680,6 +740,11 @@ Maybe you want to use 'update --init'?\")\"\n \t\tfi\n \tdone\n \n+\tif test -z \"$err\" -a -n \"$commit\" -a -n \"$changed_modules\"\n+\tthen\n+\t\tcommit_changes \"$changed_modules\"\n+\tfi\n+\n \tif test -n \"$err\"\n \tthen\n \t\tOIFS=$IFS\ndiff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\nindex 1542653..4c8bb5d 100755\n--- a/t/t7406-submodule-update.sh\n+++ b/t/t7406-submodule-update.sh\n@@ -163,6 +163,25 @@ test_expect_success 'submodule update --merge staying on master' '\n \t)\n '\n \n+test_expect_success 'submodule update --commit --rebase should commit gitlink changes' '\n+\t(cd super/submodule &&\n+\t git reset --hard HEAD~1 &&\n+\t echo \"local change\" > local-file &&\n+\t git add local-file &&\n+\t test_tick &&\n+\t git commit -m \"local change\"\n+\t) &&\n+\t(cd super &&\n+\t git submodule update --commit --rebase submodule &&\n+\t test \"$(git log -1 --oneline)\" = \"bbdbe2d Updated submodules: submodule\"\n+\t) &&\n+\t(cd submodule &&\n+\t git remote add super-submodule ../super/submodule &&\n+\t git pull super-submodule master\n+\t) &&\n+ test \"a\" = \"b\"\n+'\n+\n test_expect_success 'submodule update - rebase in .git/config' '\n \t(cd super &&\n \t git config submodule.submodule.update rebase\n-- \n1.8.0.1.gaaf2ac7.dirty\n"},{"id":"204260","messageId":"20121129162154.GA27409@odin.tremily.us","threadId":"32045","inReplyTo":"20121129161216.GB23580@odin.tremily.us","subject":"Re: [RFC] git-submodule update: Add --commit option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-29T16:21:54Z","receivedAt":"2012-11-29T16:21:54Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Nov 29, 2012 at 11:12:16AM -0500, W. Trevor King wrote:\n> + test \"a\" = \"b\"\n\nThis kills the test (with --immediate) so you can look at the\ngenerated commit. If you actually want the test to pass (e.g. if this\nbecomes a PATCH and not an RFC), this line should be removed.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"204262","messageId":"20121129162751.GB27409@odin.tremily.us","threadId":"32045","inReplyTo":"20121129161216.GB23580@odin.tremily.us","subject":"Re: [RFC] git-submodule update: Add --commit option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-29T16:27:51Z","receivedAt":"2012-11-29T16:27:51Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Nov 29, 2012 at 11:12:16AM -0500, W. Trevor King wrote:\n> +\t test \"$(git log -1 --oneline)\" = \"bbdbe2d Updated submodules: submodule\"\n\ns/bbdbe2d/cd69713/\n\nI forgot to update the SHA-1 here after tweaking the commit message\nformat. I'd like to rewrite this test so it won't use the SHA-1, but\nthis was the quickest way to check that the commit message and gitlink\nwere both changed appropriately.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"204279","messageId":"CABURp0rAJ3mVf2pN-B7NqBDysdCaZGfm2EHSWKr5iynzF6dA-g@mail.gmail.com","threadId":"32045","inReplyTo":"20121128024205.GG15213@odin.tremily.us","subject":"Re: Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-11-29T18:51:25Z","receivedAt":"2012-11-29T18:51:25Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Nov 27, 2012 at 6:28 PM, Heiko Voigt wrote:\n>\n> Hi,\n>\n> On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:\n> > On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:\n> > The v4 series leaves the remote branch amigious, but it helps you\n> > point the local branch at the right hash so that future calls to\n> >\n> > $ git submodule foreach 'git pull'\n> >\n> > can use the branch's .git/modules//config settings.\n>\n> But IMO thats the functionality which should be implemented in submodule\n> update and not left to the user.\n>\n> > > I would think more of some convention like:\n> > >\n> > > $ git checkout -t origin/$branch\n> > >\n> > > when first initialising the submodule with e.g.\n> > >\n> > > $ git submodule update --init --branch\n> > >\n> > > Then later calls of\n> > >\n> > > $ git submodule update --branch\n> > >\n> > > would have a branch configured to pull from. I imagine that results in\n> > > a similar behavior gerrit is doing on the server side?\n> >\n> > That sounds like it's doing pretty much the same thing. Can you think\n> > of a test that would distinguish it from my current v4 implementation?\n>\n> Well the main difference is that gerrit is automatically updating the\n> superproject AFAIK. I would like it if we could implement the same\n> workflow support in the submodule script. It seems to me that this is\n> already proven to be useful workflow.\n\n\nIt is proven in Gerrit, but Gerrit implements a central-server\nworkflow. That is, only Gerrit ever floats the submodules, and he\npushes the result for everyone else to share. I fear the consequences\nof everyone pulling submodules and then later trying to merge\nsuperprojects with someone else's breadcrumbs.\n\nDo you have some idea how this would be handled?\n\nPhil\n\nps. Apologies for my lateness on this topic. I'm trying to catch up now.\n\npps. Re-sent since Gmail has hidden the \"plain text\" option in a\ndifferent place, now.\n\nOn Tue, Nov 27, 2012 at 9:42 PM, W. Trevor King wrote:\n> On Wed, Nov 28, 2012 at 12:28:58AM +0100, Heiko Voigt wrote:\n>> On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:\n>> > On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:\n>> > The v4 series leaves the remote branch amigious, but it helps you\n>> > point the local branch at the right hash so that future calls to\n>> >\n>> > $ git submodule foreach 'git pull'\n>> >\n>> > can use the branch's .git/modules//config settings.\n>>\n>> But IMO thats the functionality which should be implemented in submodule\n>> update and not left to the user.\n>\n> Then you might need submodule..local-branch,\n> submodule..remote-repository, and submodule..remote-branch\n> to configure\n>\n> $ git checkout submodule..local-branch\n> $ git pull submodule..remote-repository submodule..remote-branch\n>\n> and this would ignore the $sha1 stored in the gitlink (which all of\n> the other update commands use). This ignoring-the-$sha1 bit made me\n> think that a built-in pull wasn't a good fit for 'submodule update'.\n> Maybe if it went into a new 'submodule pull'? Then users have a clear\n> distinction:\n>\n> * 'update' to push superproject $sha1 changes into the submodules\n> * 'pull' to push upstream-branch changes into the submodules\n>\n>> > > I would think more of some convention like:\n>> > >\n>> > > $ git checkout -t origin/$branch\n>> > >\n>> > > when first initialising the submodule with e.g.\n>> > >\n>> > > $ git submodule update --init --branch\n>> > >\n>> > > Then later calls of\n>> > >\n>> > > $ git submodule update --branch\n>> > >\n>> > > would have a branch configured to pull from. I imagine that results in\n>> > > a similar behavior gerrit is doing on the server side?\n>> >\n>> > That sounds like it's doing pretty much the same thing. Can you think\n>> > of a test that would distinguish it from my current v4 implementation?\n>>\n>> Well the main difference is that gerrit is automatically updating the\n>> superproject AFAIK. I would like it if we could implement the same\n>> workflow support in the submodule script. It seems to me that this is\n>> already proven to be useful workflow.\n>\n> Ah, sorry, I meant the configuring which remote branch you were\n> pulling from happens at submodule initialization (via .git/modules/…)\n> for both your workflow and my v4.\n>\n> You're right that having a builtin pull is different from my v4.\n>\n>> https://github.com/hvoigt/git/commits/hv/floating_submodules_draft\n>\n> I looked over this before, but maybe not thoroughly enough ;).\n>\n>> > > How about reusing the -b|--branch option for add? Since we only change\n>> > > the behavior when submodule.$name.update is set to branch it seems\n>> > > reasonable to me. Opinions?\n>> >\n>> > That was the approach I used in v1, but people were concerned that we\n>> > would be stomping on previously unclaimed config space. Since noone\n>> > has pointed out other uses besides Gerrit's very similar case, I'm not\n>> > sure if that is still an issue.\n>>\n>> Could you point me to that mail? I cannot seem to find it in my archive.\n>\n> Hmm. It seems like Phil's initial response was (accidentally?) off\n> list. The relevant portion was:\n>\n> On Mon, Oct 22, 2012 at 06:03:53PM -0400, Phil Hord wrote:\n>> Some projects now use the 'branch' config value to record the tracking\n>> branch for the submodule. Some ascribe different meaning to the\n>> configuration if the value is given vs. undefined. For example, see\n>> the Gerrit submodule-subscription mechanism. This change will cause\n>> those workflows to behave differently than they do now.\n>>\n>> I do like the idea, but I wish it had a different name for the\n>> recording. Maybe --record-branch=${BRANCH} as an extra switch so the\n>> action is explicitly requested.\n>\n> As I said, I'm happy to go back to --branch if opinions have changed.\n>\n> On Wed, Nov 28, 2012 at 12:28:58AM +0100, Heiko Voigt wrote:\n>> On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:\n>> > On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:\n>> > > > Because you need to recurse through submodules for `update --branch`\n>> > > > even if \"$subsha1\" == \"$sha1\", I had to amend the conditional\n>> > > > controlling that block. This broke one of the existing tests, which I\n>> > > > \"fixed\" in patch 4. I think a proper fix would involve rewriting\n>> > > >\n>> > > > (clear_local_git_env; cd \"$sm_path\" &&\n>> > > > ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&\n>> > > > test -z \"$rev\") || git-fetch)) ||\n>> > > > die \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n>> > > >\n>> > > > but I'm not familiar enough with rev-list to want to dig into that\n>> > > > yet. If feedback for the earlier three patches is positive, I'll work\n>> > > > up a clean fix and resubmit.\n>> > >\n>> > > You probably need to separate your handling here. The comparison of the\n>> > > currently checked out sha1 and the recorded sha1 is an optimization\n>> > > which skips unnecessary fetching in case the submodules commits are\n>> > > already correct. This code snippet checks whether the to be checked out\n>> > > sha1 is already local and also skips the fetch if it is. We should not\n>> > > break that.\n>> >\n>> > Agreed. However, determining if the target $sha1 is local should have\n>> > nothing to do with the current checked out $subsha1.\n>>\n>> See my draft or the diff below for an illustration of the splitup.\n>>\n>> [snip diff]\n>\n> This looks fine, but my current --branch implementation (which doesn't\n> pull) is only a thin branch-checkout layer on top of the standard\n> `update` functionality. I'm still unsure if built-in pulls are worth\n> the configuration trouble. I'll sleep on it. Maybe I'll feel better\n> about them tomorrow ;).\n>\n> Cheers,\n> Trevor\n>\n> --\n> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).\n> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"}]}