{"thread":{"id":"32245","subject":"Re: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes","startedAt":"2012-11-29T19:13:26Z","lastAt":"2012-12-21T11:04:25Z","messageCount":67,"participants":["W. Trevor King","Phil Hord","Jens Lehmann","Junio C Hamano","Michael J Gruber","Marc Branchaud","wking@tremily.us","Heiko Voigt"],"isPatch":true,"patchVersion":5,"patchTotal":2},"messages":[{"id":"204286","messageId":"20121129191326.GC27409@odin.tremily.us","threadId":"32245","inReplyTo":"CABURp0oSo9ACFKkBEK1_qNu2mEAu1=nUJxnROaRsXiaWvHih=w@mail.gmail.com","subject":"Re: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-29T19:13:26Z","receivedAt":"2012-11-29T19:13:26Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"\nOn Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote:\n> On Fri, Nov 23, 2012 at 12:54 PM, W. Trevor King wrote:\n> > [snip initial thoughts leading to the update --remote v5]\n>\n> I was thinking the same thing, but reading this whole thread a couple of\n> weeks late. Thanks for noticing.\n> \n> Moreover, I think that 'git submodule update --pull' is also the wrong way\n> to spell this action. Maybe you are misled from the outset by your\n> current workflow:\n\nDid you see my v5 (add --remote) series?\n\n> For that reason, I don't like the --pull switch since it implies a\n> fetch, but I will not always want to do a fetch.\n\n $ git submodule update --remote --no-fetch\n\nwill not fetch the submodule remotes.\n\n> I don't know which remote I should be tracking, though. I suppose\n> it is 'origin' for now, but maybe it is just whatever\n> $superproject's HEAD's remote-tracking branch indicates.\n\nWith the --remote series, I always use \"origin\" because that's what\n`submodule add` should be setting up. If people want to change that\nup by hand, we may need a submodule..remote configuration\noption.\n\n> I am not sure I want the gitlinks in superproject to update automatically\n> in the index, but I definitely do not want to automatically create a commit\n> for them.\n\nCommits are dissabled by default (see my recent --commit RFC for how\nthey would be enabled).\n\n> But I really don't want to figure out how to handle submodule\n> collisions during a merge (or rebase!) of my superproject with changes that\n> someone else auto-committed in his local $superproject as he and I\n> arbitrarily floated up the upstream independently. There is nothing but\n> loathing down that path.\n\nThis is true. I'm not sure how gitlink collisions are currently\nhandled…\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":"204304","messageId":"CABURp0piLAG+hEsav-uro+nq9ZRZ9CFFjVG8VKYk3ZtYvRi8=A@mail.gmail.com","threadId":"32245","inReplyTo":"20121129191326.GC27409@odin.tremily.us","subject":"Re: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-11-30T01:11:20Z","receivedAt":"2012-11-30T01:11:20Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King wrote:\n>\n> On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote:\n>> On Fri, Nov 23, 2012 at 12:54 PM, W. Trevor King wrote:\n>> > [snip initial thoughts leading to the update --remote v5]\n>>\n>> I was thinking the same thing, but reading this whole thread a couple of\n>> weeks late. Thanks for noticing.\n>>\n>> Moreover, I think that 'git submodule update --pull' is also the wrong way\n>> to spell this action. Maybe you are misled from the outset by your\n>> current workflow:\n>\n> Did you see my v5 (add --remote) series?\n\nEventually, I did. Sorry for the out-of-order replies.\n\n\n>> For that reason, I don't like the --pull switch since it implies a\n>> fetch, but I will not always want to do a fetch.\n>\n> $ git submodule update --remote --no-fetch\n>\n> will not fetch the submodule remotes.\n\nThis seems precisely backwards to me. Why not use\n\n $ git submodule update --remote --fetch\n\nto do your \"default\" behavior instead? I suppose I am arguing\nagainst the tide of the dominant workflow, but the fetch-by-default\nidea needlessly conflates two primitive operations: \"float\" and\n\"fetch\".\n\n>> I don't know which remote I should be tracking, though. I suppose\n>> it is 'origin' for now, but maybe it is just whatever\n>> $superproject's HEAD's remote-tracking branch indicates.\n>\n> With the --remote series, I always use \"origin\" because that's what\n> `submodule add` should be setting up. If people want to change that\n> up by hand, we may need a submodule..remote configuration\n> option.\n\nI've always felt that the \"origin\" defaults are broken and are simply\nbeing ignored because most users do not trip over them. But ISTR that\nsubmodule commands use the remote indicated by the superproject's\ncurrent remote-tracking configuration, with a fallback to 'origin' if\nthere is none. Sort of a \"best effort\" algorithm, I think. Am I\nremembering that wrong?\n\n\n>> I am not sure I want the gitlinks in superproject to update automatically\n>> in the index, but I definitely do not want to automatically create a commit\n>> for them.\n>\n> Commits are dissabled by default (see my recent --commit RFC for how\n> they would be enabled).\n>\n>> But I really don't want to figure out how to handle submodule\n>> collisions during a merge (or rebase!) of my superproject with changes that\n>> someone else auto-committed in his local $superproject as he and I\n>> arbitrarily floated up the upstream independently. There is nothing but\n>> loathing down that path.\n>\n> This is true. I'm not sure how gitlink collisions are currently\n> handled…\n\n\nThey've always been trouble for me. But it may be that I am ignorant.\n\nPhil\n"},{"id":"204330","messageId":"20121130032719.GE29257@odin.tremily.us","threadId":"32245","inReplyTo":"CABURp0piLAG+hEsav-uro+nq9ZRZ9CFFjVG8VKYk3ZtYvRi8=A@mail.gmail.com","subject":"Re: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-30T03:27:19Z","receivedAt":"2012-11-30T03:27:19Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote:\n> On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King wrote:\n> > On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote:\n> >> For that reason, I don't like the --pull switch since it implies a\n> >> fetch, but I will not always want to do a fetch.\n> >\n> > $ git submodule update --remote --no-fetch\n> >\n> > will not fetch the submodule remotes.\n> \n> This seems precisely backwards to me. Why not use\n> \n> $ git submodule update --remote --fetch\n> \n> to do your \"default\" behavior instead? I suppose I am arguing\n> against the tide of the dominant workflow, but the fetch-by-default\n> idea needlessly conflates two primitive operations: \"float\" and\n> \"fetch\".\n\nBecause --no-fetch is the existing option, and if it ain't broke… ;).\n\n> >> I don't know which remote I should be tracking, though. I suppose\n> >> it is 'origin' for now, but maybe it is just whatever\n> >> $superproject's HEAD's remote-tracking branch indicates.\n> >\n> > With the --remote series, I always use \"origin\" because that's what\n> > `submodule add` should be setting up. If people want to change that\n> > up by hand, we may need a submodule..remote configuration\n> > option.\n> \n> I've always felt that the \"origin\" defaults are broken and are simply\n> being ignored because most users do not trip over them. But ISTR that\n> submodule commands use the remote indicated by the superproject's\n> current remote-tracking configuration, with a fallback to 'origin' if\n> there is none. Sort of a \"best effort\" algorithm, I think. Am I\n> remembering that wrong?\n\nThe current code uses a bare \"git-fetch\". I'm not sure what that\ndefaults to if you're on a detached head. If it bothers you, I'm fine\nadding the submodule..remote option in v6.\n\n> >> I am not sure I want the gitlinks in superproject to update automatically\n> >> in the index, but I definitely do not want to automatically create a commit\n> >> for them.\n> >\n> > Commits are dissabled by default (see my recent --commit RFC for how\n> > they would be enabled).\n> >\n> >> But I really don't want to figure out how to handle submodule\n> >> collisions during a merge (or rebase!) of my superproject with changes that\n> >> someone else auto-committed in his local $superproject as he and I\n> >> arbitrarily floated up the upstream independently. There is nothing but\n> >> loathing down that path.\n> >\n> > This is true. I'm not sure how gitlink collisions are currently\n> > handled…\n> \n> They've always been trouble for me. But it may be that I am ignorant.\n\nI haven't dealt with any gitlink merges, but I think that supporting\neasy gitlink merges is orthogonal to this --remote option. For simple\ncases like \"autocommitted submodule floats\", one of the conflicting\ngitlinks will be an ancestor of the other, so it should be easy to\nautomate that merge.\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":"204344","messageId":"20121130175309.GA718@odin.tremily.us","threadId":"32245","inReplyTo":"20121130032719.GE29257@odin.tremily.us","subject":"[RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-30T17:53:09Z","receivedAt":"2012-11-30T17:53:09Z","isPatch":false,"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> Your intentions makes lots of sense, but your patch does more than\n> that. Copying the branch setting into .git/config sets the initial\n> branch setting into stone. That makes it impossible to have a branch\n> \"foo\" in the superproject using a branch \"bar\" in a submodule and\n> another superproject branch \"frotz\" using branch \"nitfol\" for the\n> same submodule. 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\n> to follow different submodule branches in different superproject\n> branches.\n\nI've mulling this over, and when I started coding support for\nsubmodule..remote, I had an idea.\n\nOn Thu, Nov 29, 2012 at 10:27:19PM -0500, W. Trevor King wrote:\n> On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote:\n> > I've always felt that the \"origin\" defaults are broken and are simply\n> > being ignored because most users do not trip over them. But ISTR that\n> > submodule commands use the remote indicated by the superproject's\n> > current remote-tracking configuration, with a fallback to 'origin' if\n> > there is none. Sort of a \"best effort\" algorithm, I think. Am I\n> > remembering that wrong?\n> \n> The current code uses a bare \"git-fetch\". I'm not sure what that\n> defaults to if you're on a detached head. If it bothers you, I'm fine\n> adding the submodule..remote option in v6.\n\nIn my v5 patch, I check for submodule..remote first in the usual\n`git config` files. If I don't find what I'm looking for I fall back\non .gitmodules (basically Jens' suggestion). However, my initial\ncopying-to-.git/config approach was mostly done to mimic existing\nconfiguration handling in git-submodule.sh. Since I agree with Jens\non configuration precendence, and I now had two options to read\n(.branch and .remote), I thought I'd pull the logic out into its own\nfunction (code included at the end). While I was shifting the\nexisting submodule config handling over to my new function, I noticed\nthat with this logic, `submodule init` doesn't really do anything\nimportant anymore. Likewise for `submodule sync`, which seems to be\nquite similar to `init`.\n\nWhat to do about this? `init` has been around for a while, so we\ncan't just remove it (maybe in 2.0?). Leaving it in place is not\nreally a problem though, it just means that the user is locking in the\ncurrent .gitmodules configuration (as Jens pointed out with respect to\n.branch).\n\nI may be way off base here, as I'm fairly new to submodules in general\nand these two commands in particular, but I thought I'd float the\nidea.\n\nCheers,\nTrevor\n\n---\n#\n# Print a submodule configuration setting\n#\n# $1 = submodule name\n# $2 = option name\n# $3 = default value\n#\n# Checks in the usual git-config places first (for overrides),\n# otherwise it falls back on .gitmodules. This allows you to\n# distribute project-wide defaults in .gitmodules, while still\n# customizing individual repositories if necessary. If the option is\n# not in .gitmodules either, print a default value.\n#\nget_submodule_config()\n{\n\tname=\"$1\"\n\toption=\"$2\"\n\tdefault=\"$3\"\n\tvalue=$(git config submodule.\"$name\".\"$option\")\n\tif test -z \"$value\"\n\tthen\n\t\tvalue=$(git config -f .gitmodules submodule.\"$name\".\"$option\")\n\tfi\n\tprintf '%s' \"${value:-$default}\"\n}\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":"204350","messageId":"20121130181709.GA967@odin.tremily.us","threadId":"32245","inReplyTo":"20121130175309.GA718@odin.tremily.us","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-11-30T18:17:09Z","receivedAt":"2012-11-30T18:17:09Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Nov 30, 2012 at 12:53:09PM -0500, W. Trevor King wrote:\n> Likewise for `submodule sync`, which seems to be\n> quite similar to `init`.\n\nAh, I'd remove the part of `sync` that touches the superproject's\n.git/config, but keep the part that stores the superproject-reorded\nURL in the submodule's config:\n\n url=$(get_submodule_config \"$name\" url)\n up_path=$(get_up_path \"$sm_path\")\n url=$(resolve_relative_url \"$url\" \"$up_path\") &&\n if test -n \"$url\"\n then\n if test -e \"$sm_path\"/.git\n then\n (\n clear_local_git_env\n cd \"$sm_path\"\n remote=$(get_default_remote)\n git config remote.\"$remote\".url \"$url\"\n )\n fi\n fi\n\nI should probably also tweak sync to do similar things with\nsubmodule..branch and .remote as part of my `--update remote`\nseries.\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":"204367","messageId":"CABURp0qNBcFnxbvhn7PsKWLUOsTiK4u5vx-=6cG3JQHw9aUeHA@mail.gmail.com","threadId":"32245","inReplyTo":"20121130175309.GA718@odin.tremily.us","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-11-30T23:52:22Z","receivedAt":"2012-11-30T23:52:22Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Fri, Nov 30, 2012 at 12:53 PM, W. Trevor King wrote:\n> 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>> Your intentions makes lots of sense, but your patch does more than\n>> that. Copying the branch setting into .git/config sets the initial\n>> branch setting into stone. That makes it impossible to have a branch\n>> \"foo\" in the superproject using a branch \"bar\" in a submodule and\n>> another superproject branch \"frotz\" using branch \"nitfol\" for the\n>> same submodule. 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\n>> to follow different submodule branches in different superproject\n>> branches.\n>\n> I've mulling this over, and when I started coding support for\n> submodule..remote, I had an idea.\n>\n> On Thu, Nov 29, 2012 at 10:27:19PM -0500, W. Trevor King wrote:\n>> On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote:\n>> > I've always felt that the \"origin\" defaults are broken and are simply\n>> > being ignored because most users do not trip over them. But ISTR that\n>> > submodule commands use the remote indicated by the superproject's\n>> > current remote-tracking configuration, with a fallback to 'origin' if\n>> > there is none. Sort of a \"best effort\" algorithm, I think. Am I\n>> > remembering that wrong?\n>>\n>> The current code uses a bare \"git-fetch\". I'm not sure what that\n>> defaults to if you're on a detached head. If it bothers you, I'm fine\n>> adding the submodule..remote option in v6.\n>\n> In my v5 patch, I check for submodule..remote first in the usual\n> `git config` files. If I don't find what I'm looking for I fall back\n> on .gitmodules (basically Jens' suggestion). However, my initial\n> copying-to-.git/config approach was mostly done to mimic existing\n> configuration handling in git-submodule.sh. Since I agree with Jens\n> on configuration precendence, and I now had two options to read\n> (.branch and .remote), I thought I'd pull the logic out into its own\n> function (code included at the end). While I was shifting the\n> existing submodule config handling over to my new function, I noticed\n> that with this logic, `submodule init` doesn't really do anything\n> important anymore.\n\nIf I never 'submodule init' a submodule, it does not get visited by\n'git submodule foreach', among others. I think some people use this\nbehavior explicitly.\n\nOn the other hand, I've also notice that a submodule which I have\nremoved does not get de-inited later one. It causes my 'git submodule\nforeach' to emit errors. :-(\n\nPhil\n\n\n> Likewise for `submodule sync`, which seems to be\n> quite similar to `init`.\n>\n> What to do about this? `init` has been around for a while, so we\n> can't just remove it (maybe in 2.0?). Leaving it in place is not\n> really a problem though, it just means that the user is locking in the\n> current .gitmodules configuration (as Jens pointed out with respect to\n> .branch).\n>\n> I may be way off base here, as I'm fairly new to submodules in general\n> and these two commands in particular, but I thought I'd float the\n> idea.\n>\n> Cheers,\n> Trevor\n>\n> ---\n> #\n> # Print a submodule configuration setting\n> #\n> # $1 = submodule name\n> # $2 = option name\n> # $3 = default value\n> #\n> # Checks in the usual git-config places first (for overrides),\n> # otherwise it falls back on .gitmodules. This allows you to\n> # distribute project-wide defaults in .gitmodules, while still\n> # customizing individual repositories if necessary. If the option is\n> # not in .gitmodules either, print a default value.\n> #\n> get_submodule_config()\n> {\n> name=\"$1\"\n> option=\"$2\"\n> default=\"$3\"\n> value=$(git config submodule.\"$name\".\"$option\")\n> if test -z \"$value\"\n> then\n> value=$(git config -f .gitmodules submodule.\"$name\".\"$option\")\n> fi\n> printf '%s' \"${value:-$default}\"\n> }\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"},{"id":"204383","messageId":"20121201124842.GA32291@odin.tremily.us","threadId":"32245","inReplyTo":"CABURp0qNBcFnxbvhn7PsKWLUOsTiK4u5vx-=6cG3JQHw9aUeHA@mail.gmail.com","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-01T12:48:42Z","receivedAt":"2012-12-01T12:48:42Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Nov 30, 2012 at 06:52:22PM -0500, Phil Hord wrote:\n> If I never 'submodule init' a submodule, it does not get visited by\n> 'git submodule foreach', among others. I think some people use this\n> behavior explicitly.\n\nThis is something I'll fix while working up a trial patch. Currently\ncmd_update calls module_clone if the /.git does not exist.\nThis should probably happen in each command (in a wrapper around\nmodule_list?). It's possible that module_list itself would need some\nwork, but I haven't absorbed its implementation yet [1].\n\nTrevor\n\n[1]: I read Perl by sounding out each letter ;).\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":"204385","messageId":"50BA245A.5000702@web.de","threadId":"32245","inReplyTo":"20121130175309.GA718@odin.tremily.us","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-12-01T15:38:02Z","receivedAt":"2012-12-01T15:38:02Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 30.11.2012 18:53, schrieb W. Trevor King:\n> In my v5 patch, I check for submodule..remote first in the usual\n> `git config` files. If I don't find what I'm looking for I fall back\n> on .gitmodules (basically Jens' suggestion). However, my initial\n> copying-to-.git/config approach was mostly done to mimic existing\n> configuration handling in git-submodule.sh. Since I agree with Jens\n> on configuration precendence, and I now had two options to read\n> (.branch and .remote), I thought I'd pull the logic out into its own\n> function (code included at the end). While I was shifting the\n> existing submodule config handling over to my new function, I noticed\n> that with this logic, `submodule init` doesn't really do anything\n> important anymore. Likewise for `submodule sync`, which seems to be\n> quite similar to `init`.\n\nYou need to handle the 'url' setting differently. While I think the\n'update' setting should not be copied into .git/config at all\n(because it makes it impossible for upstream to change that later\nwithout the user copying that himself as 'sync' doesn't do that) the\n'url' setting in .git/config has two important implications:\n\n1) It tells the submodule commands that the user wants to have that\n submodule populated (which is done in a subsequent \"update\" after\n \"init\" copied the url there).\n\n2) It can be used to follow moving upstreams (think of checking out\n an earlier commit before the upstream was moved, you won't be able\n to clone it from there without having the new setting persist).\n And which repository you follow is a matter of trust, so the extra\n \"git submodule sync\" in that case is a good thing to have.\n\nSo I believe 'url' is the only setting that should be copied into\n.git/config while all the others shouldn't.\n\n> What to do about this? `init` has been around for a while, so we\n> can't just remove it (maybe in 2.0?). Leaving it in place is not\n> really a problem though, it just means that the user is locking in the\n> current .gitmodules configuration (as Jens pointed out with respect to\n> .branch).\n\nWe still need those commands to set and update the \"url\" setting.\n\n> ---\n> #\n> # Print a submodule configuration setting\n> #\n> # $1 = submodule name\n> # $2 = option name\n> # $3 = default value\n> #\n> # Checks in the usual git-config places first (for overrides),\n> # otherwise it falls back on .gitmodules. This allows you to\n> # distribute project-wide defaults in .gitmodules, while still\n> # customizing individual repositories if necessary. If the option is\n> # not in .gitmodules either, print a default value.\n> #\n> get_submodule_config()\n> {\n> \tname=\"$1\"\n> \toption=\"$2\"\n> \tdefault=\"$3\"\n> \tvalue=$(git config submodule.\"$name\".\"$option\")\n> \tif test -z \"$value\"\n> \tthen\n> \t\tvalue=$(git config -f .gitmodules submodule.\"$name\".\"$option\")\n> \tfi\n> \tprintf '%s' \"${value:-$default}\"\n> }\n\nSomething like that makes sense. You can use it for the settings you add\nfirst and we can then reuse that for 'update' in a separate patch later.\n"},{"id":"204386","messageId":"50BA257F.9070607@web.de","threadId":"32245","inReplyTo":"20121201124842.GA32291@odin.tremily.us","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-12-01T15:42:55Z","receivedAt":"2012-12-01T15:42:55Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 01.12.2012 13:48, schrieb W. Trevor King:\n> On Fri, Nov 30, 2012 at 06:52:22PM -0500, Phil Hord wrote:\n>> If I never 'submodule init' a submodule, it does not get visited by 'git submodule foreach', among others. I think some people use this behavior explicitly.\n> \n> This is something I'll fix while working up a trial patch. Currently cmd_update calls module_clone if the /.git does not exist. This should probably happen in each command (in a wrapper around module_list?). It's possible that module_list itself would need some work, but I haven't absorbed its implementation yet [1].\n\nPlease do not fix it, this is a feature. \"update\" is the only command\nwhere that should happen (and only if \"url\" is set in .git/config, as\nI explained in my other mail). So everything should be fine here.\n"},{"id":"204388","messageId":"50BA2892.7060706@web.de","threadId":"32245","inReplyTo":"CABURp0qNBcFnxbvhn7PsKWLUOsTiK4u5vx-=6cG3JQHw9aUeHA@mail.gmail.com","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-12-01T15:56:02Z","receivedAt":"2012-12-01T15:56:02Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 01.12.2012 00:52, schrieb Phil Hord:\n> If I never 'submodule init' a submodule, it does not get visited by\n> 'git submodule foreach', among others. I think some people use this\n> behavior explicitly.\n> \n> On the other hand, I've also notice that a submodule which I have\n> removed does not get de-inited later one. It causes my 'git submodule\n> foreach' to emit errors. :-(\n\nI'm currently hacking on \"git submodule deinit\" which removes the 'url'\nsetting from git/config. This should do the trick for you, right?\n\nJust removing that submodule automagically would not work that well, as\nit would deinitialize a submodule when you switch to a branch where it\nisn't present and you'd have to reinitialize it when you come back.\n"},{"id":"204390","messageId":"20121201163004.GB4823@odin.tremily.us","threadId":"32245","inReplyTo":"50BA257F.9070607@web.de","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-01T16:30:04Z","receivedAt":"2012-12-01T16:30:04Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sat, Dec 01, 2012 at 04:38:02PM +0100, Jens Lehmann wrote:\n> Am 30.11.2012 18:53, schrieb W. Trevor King:\n> > In my v5 patch, I check for submodule..remote first in the usual\n> > `git config` files. If I don't find what I'm looking for I fall back\n> > on .gitmodules (basically Jens' suggestion). However, my initial\n> > copying-to-.git/config approach was mostly done to mimic existing\n> > configuration handling in git-submodule.sh. Since I agree with Jens\n> > on configuration precendence, and I now had two options to read\n> > (.branch and .remote), I thought I'd pull the logic out into its own\n> > function (code included at the end). While I was shifting the\n> > existing submodule config handling over to my new function, I noticed\n> > that with this logic, `submodule init` doesn't really do anything\n> > important anymore. Likewise for `submodule sync`, which seems to be\n> > quite similar to `init`.\n> \n> You need to handle the 'url' setting differently. While I think the\n> 'update' setting should not be copied into .git/config at all\n> (because it makes it impossible for upstream to change that later\n> without the user copying that himself as 'sync' doesn't do that) the\n> 'url' setting in .git/config has two important implications:\n> \n> 1) It tells the submodule commands that the user wants to have that\n> submodule populated (which is done in a subsequent \"update\" after\n> \"init\" copied the url there).\n\nGood point, but this should depend on submodule..update; having\nit as a side effect of a local submodule..url makes no sense.\nPerhaps `submodule init` should be reduced to just wrap:\n\n $ git config submodule..update checkout\n\nwhere the default update configuration would be 'none'.\n\n> 2) It can be used to follow moving upstreams (think of checking out\n> an earlier commit before the upstream was moved, you won't be able\n> to clone it from there without having the new setting persist).\n> And which repository you follow is a matter of trust, so the extra\n> \"git submodule sync\" in that case is a good thing to have.\n> \n> So I believe 'url' is the only setting that should be copied into\n> .git/config while all the others shouldn't.\n\nIf you want to override the old repository location for an old commit,\nsetting submodule..url makes sense. My rewritten `sync` updates\nthe local submodule..url in the superproject if the\nconfiguration option is already set [1]. Perhaps a `sync --local`\ninvocation should forcibly populate the local submodule..url to\nmake this workflow easier. Bundling sugar for this special case\nshould not happen under an extra command called `init`.\n\n> > [snip get_submodule_config()]\n>\n> Something like that makes sense. You can use it for the settings you add\n> first and we can then reuse that for 'update' in a separate patch later.\n\nI'm currently working out the details independently against v1.8.0.\nThis will be a fairly major shift, so I think it should stay\nindependent of `update --remote`. The `update --remote` stuff should\nbe easy to adjust/rebase if the `init` removal/adjustment develops\ninto something acceptable.\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":"204391","messageId":"20121201163714.GC4823@odin.tremily.us","threadId":"32245","inReplyTo":"50BA2892.7060706@web.de","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-01T16:37:14Z","receivedAt":"2012-12-01T16:37:14Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sat, Dec 01, 2012 at 04:56:02PM +0100, Jens Lehmann wrote:\n> Am 01.12.2012 00:52, schrieb Phil Hord:\n> > If I never 'submodule init' a submodule, it does not get visited by\n> > 'git submodule foreach', among others. I think some people use this\n> > behavior explicitly.\n> > \n> > On the other hand, I've also notice that a submodule which I have\n> > removed does not get de-inited later one. It causes my 'git submodule\n> > foreach' to emit errors. :-(\n> \n> I'm currently hacking on \"git submodule deinit\" which removes the 'url'\n> setting from git/config. This should do the trick for you, right?\n> \n> Just removing that submodule automagically would not work that well, as\n> it would deinitialize a submodule when you switch to a branch where it\n> isn't present and you'd have to reinitialize it when you come back.\n\nI think this is another case where we should be looping through\nsubmodules based on the revision-specific .gitmodules content, and\nquerying the local config only to determine if the user wants to\nupdate them (to drop into them with foreach, etc.).\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":"204392","messageId":"50BA3412.60309@web.de","threadId":"32245","inReplyTo":"50BA2892.7060706@web.de","subject":"[PATCH] submodule: add 'deinit' command","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-12-01T16:45:06Z","receivedAt":"2012-12-01T16:45:06Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"With \"git submodule init\" the user is able to tell git he cares about one\nor more submodules and wants to have it populated on the next call to \"git\nsubmodule update\". But currently there is no easy way he could tell git he\ndoes not care about a submodule anymore and wants to get rid of his local\nwork tree (except he knows a lot about submodule internals and removes the\n\"submodule.$name.url\" setting from .git/config himself).\n\nHelp those users by providing a 'deinit' command. This removes the url\nsetting from .git/config either for the given submodule(s) or for all\nthose which have been initialized if none were given. Complain only when\nfor a submodule given on the command line the url setting can't be found\nin .git/config.\n\nAdd tests and link the man pages of \"git submodule deinit\" and \"git rm\" to\nassist the user in deciding whether removing or unregistering the submodule\nis the right thing to do for him.\n\nSigned-off-by: Jens Lehmann \n---\n\nAm 01.12.2012 16:56, schrieb Jens Lehmann:\n> Am 01.12.2012 00:52, schrieb Phil Hord:\n>> If I never 'submodule init' a submodule, it does not get visited by\n>> 'git submodule foreach', among others. I think some people use this\n>> behavior explicitly.\n>>\n>> On the other hand, I've also notice that a submodule which I have\n>> removed does not get de-inited later one. It causes my 'git submodule\n>> foreach' to emit errors. :-(\n> \n> I'm currently hacking on \"git submodule deinit\" which removes the 'url'\n> setting from git/config. This should do the trick for you, right?\n\nAnd here we go ...\n\n\n Documentation/git-rm.txt | 4 ++++\n Documentation/git-submodule.txt | 11 +++++++++\n git-submodule.sh | 50 ++++++++++++++++++++++++++++++++++++++++-\n t/t7400-submodule-basic.sh | 11 +++++++++\n 4 files changed, 75 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt\nindex 262436b..ec42bf5 100644\n--- a/Documentation/git-rm.txt\n+++ b/Documentation/git-rm.txt\n@@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree.\n Ignored files are deemed expendable and won't stop a submodule's work\n tree from being removed.\n\n+If you only want to remove the local checkout of a submodule from your\n+work tree without committing that use `git submodule deinit` instead\n+(see linkgit:git-submodule[1]).\n+\n EXAMPLES\n --------\n `git rm Documentation/\\*.txt`::\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex b1de3ba..fba77f6 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -13,6 +13,7 @@ SYNOPSIS\n \t [--reference ] [--] []\n 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]\n 'git submodule' [--quiet] init [--] [...]\n+'git submodule' [--quiet] deinit [--] [...]\n 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]\n \t [--reference ] [--merge] [--recursive] [--] [...]\n 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]\n@@ -134,6 +135,16 @@ init::\n \tthe explicit 'init' step if you do not intend to customize\n \tany submodule locations.\n\n+deinit::\n+\tUnregister the submodules, i.e. remove the `submodule.$name.url`\n+\tsetting from .git/config. Further calls to `git submodule update`,\n+\t`git submodule foreach` and `git submodule sync` will skip any\n+\tunregistered submodules until they are initialized again, so use\n+\tthis command if you don't want to have a local checkout of the\n+\tsubmodule in your work tree anymore. If you really want to remove\n+\ta submodule from the repository and commit that use\n+\tlinkgit:git-rm[1] instead.\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.\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 2365149..4059a2e 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -8,6 +8,7 @@ dashless=$(basename \"$0\" | sed -e 's/-/ /')\n USAGE=\"[--quiet] add [-b ] [-f|--force] [--name ] [--reference ] [--] []\n or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]\n or: $dashless [--quiet] init [--] [...]\n+ or: $dashless [--quiet] deinit [--] [...]\n or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ] [commit] [--] [...]\n or: $dashless [--quiet] foreach [--recursive] \n@@ -516,6 +517,53 @@ cmd_init()\n }\n\n #\n+# Unregister submodules from .git/config\n+#\n+# $@ = requested paths (default to all)\n+#\n+cmd_deinit()\n+{\n+\t# parse $args after \"submodule ... init\".\n+\twhile test $# -ne 0\n+\tdo\n+\t\tcase \"$1\" in\n+\t\t-q|--quiet)\n+\t\t\tGIT_QUIET=1\n+\t\t\t;;\n+\t\t--)\n+\t\t\tshift\n+\t\t\tbreak\n+\t\t\t;;\n+\t\t-*)\n+\t\t\tusage\n+\t\t\t;;\n+\t\t*)\n+\t\t\tbreak\n+\t\t\t;;\n+\t\tesac\n+\t\tshift\n+\tdone\n+\n+\tmodule_list \"$@\" |\n+\twhile read mode sha1 stage sm_path\n+\tdo\n+\t\tdie_if_unmatched \"$mode\"\n+\t\tname=$(module_name \"$sm_path\") || exit\n+\t\turl=$(git config submodule.\"$name\".url)\n+\t\tif test -z \"$url\"\n+\t\tthen\n+\t\t\t# Only mention uninitialized submodules when its\n+\t\t\t# path have been specified\n+\t\t\ttest \"$#\" != \"0\" &&\n+\t\t\tsay \"$(eval_gettext \"No url found for submodule path '\\$sm_path' in .git/config\")\"\n+\t\t\tcontinue\n+\t\tfi\n+\t\tgit config --unset submodule.\"$name\".url &&\n+\t\tsay \"$(eval_gettext \"Submodule '\\$name' (\\$url) unregistered\")\"\n+\tdone\n+}\n+\n+#\n # Update each submodule path to correct revision, using clone and checkout as needed\n #\n # $@ = requested paths (default to all)\n@@ -1108,7 +1156,7 @@ cmd_sync()\n while test $# != 0 && test -z \"$command\"\n do\n \tcase \"$1\" in\n-\tadd | foreach | init | update | status | summary | sync)\n+\tadd | foreach | init | deinit | update | status | summary | sync)\n \t\tcommand=$1\n \t\t;;\n \t-q|--quiet)\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex de7d453..803bda7 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -756,4 +756,15 @@ test_expect_success 'submodule add with an existing name fails unless forced' '\n \t)\n '\n\n+test_expect_success 'submodule deinit should unregister submodule url from .git/config' '\n+\turl=$(git config submodule.example.url) &&\n+\tgit submodule deinit &&\n+\ttest -z \"$(git config submodule.example.url)\"\n+'\n+\n+test_expect_success 'submodule deinit complains only when explicitly used on an uninitialized submodule' '\n+\tgit submodule deinit &&\n+\ttest_must_fail git submodule deinit example\n+'\n+\n test_done\n-- \n1.7.11.7\n"},{"id":"204393","messageId":"20121201165404.GD4823@odin.tremily.us","threadId":"32245","inReplyTo":"20121130175309.GA718@odin.tremily.us","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-01T16:54:04Z","receivedAt":"2012-12-01T16:54:04Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"I'm currently stuck with adding a commit-less existing repository as a\nsubmodule (which happens in t7400-submodule-basic.sh, ../bar/a/b/c\nworks with relative local path):\n\n $ mkdir -p super/sub\n $ cd super\n $ git init\n $ (cd sub && git init)\n $ git submodule add ./ sub\n $ git status\n # On branch master\n #\n # Initial commit\n #\n # Changes to be committed:\n # (use \"git rm --cached ...\" to unstage)\n #\n # new file: .gitmodules\n #\n\nWhat I'm missing is a gitlink form sub for 'Subproject commit\n00000...' or some such. When the subproject has an actual commit,\nthings work as expected:\n\n $ mkdir -p super/sub\n $ cd super\n $ git init\n $ (cd sub && git init && echo line-1 > file && git add file && git commit -m file)\n $ git submodule add ./ sub\n $ git status\n # On branch master\n #\n # Initial commit\n #\n # Changes to be committed:\n # (use \"git rm --cached ...\" to unstage)\n #\n # new file: .gitmodules\n # new file: sub\n #\n\nThis means that module_list isn't aware of the empty submodule, when\nthe user has just explicitly added it. Fixing this would seem to need\neither 'Subproject commit 00000...' as I suggested earlier, or an\nadjustment to module_list that also spits out submodules that are in\n.gitmodules but not in the index.\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":"204394","messageId":"50BA3D7D.8040707@web.de","threadId":"32245","inReplyTo":"20121201163004.GB4823@odin.tremily.us","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-12-01T17:25:17Z","receivedAt":"2012-12-01T17:25:17Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 01.12.2012 17:30, schrieb W. Trevor King:\n> On Sat, Dec 01, 2012 at 04:38:02PM +0100, Jens Lehmann wrote:\n>> You need to handle the 'url' setting differently. While I think the 'update' setting should not be copied into .git/config at all (because it makes it impossible for upstream to change that later without the user copying that himself as 'sync' doesn't do that) the 'url' setting in .git/config has two important implications:\n>> \n>> 1) It tells the submodule commands that the user wants to have that submodule populated (which is done in a subsequent \"update\" after \"init\" copied the url there).\n> \n> Good point, but this should depend on submodule..update; having it as a side effect of a local submodule..url makes no sense.\n\nSorry, but that makes tons of sense: url controls if the submodule\nis to be populated and from where, update controls how (and can even\nveto populating it if set to \"none\"). We /could/ do it differently,\nbut I can't see why we should (and risk severe compatibility issues).\n\n> Perhaps `submodule init` should be reduced to just wrap:\n> \n> $ git config submodule..update checkout\n> \n> where the default update configuration would be 'none'.\n> \n>> 2) It can be used to follow moving upstreams (think of checking out an earlier commit before the upstream was moved, you won't be able to clone it from there without having the new setting persist). And which repository you follow is a matter of trust, so the extra \"git submodule sync\" in that case is a good thing to have.\n>> \n>> So I believe 'url' is the only setting that should be copied into .git/config while all the others shouldn't.\n> \n> If you want to override the old repository location for an old commit, setting submodule..url makes sense. My rewritten `sync` updates the local submodule..url in the superproject if the configuration option is already set [1]. Perhaps a `sync --local` invocation should forcibly populate the local submodule..url to make this workflow easier. Bundling sugar for this special case should not happen under an extra command called `init`.\n\nWhat real world problems do we have with the current init/sync that\nthis approach would solve?\n\n>>> [snip get_submodule_config()]\n>> \n>> Something like that makes sense. You can use it for the settings you add first and we can then reuse that for 'update' in a separate patch later.\n> \n> I'm currently working out the details independently against v1.8.0. This will be a fairly major shift, so I think it should stay independent of `update --remote`. The `update --remote` stuff should be easy to adjust/rebase if the `init` removal/adjustment develops into something acceptable.\n\nI totally agree. Let's get the `update --remote` stuff ready first.\n"},{"id":"204396","messageId":"20121201174920.GE4823@odin.tremily.us","threadId":"32245","inReplyTo":"50BA3D7D.8040707@web.de","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-01T17:49:20Z","receivedAt":"2012-12-01T17:49:20Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote:\n> Am 01.12.2012 17:30, schrieb W. Trevor King:\n> > On Sat, Dec 01, 2012 at 04:38:02PM +0100, Jens Lehmann wrote:\n> > > 1) It tells the submodule commands that the user wants to have\n> > > that submodule populated (which is done in a subsequent \"update\"\n> > > after \"init\" copied the url there).\n> > \n> > Good point, but this should depend on submodule..update;\n> > having it as a side effect of a local submodule..url makes\n> > no sense.\n> \n> Sorry, but that makes tons of sense: url controls if the submodule\n> is to be populated and from where, update controls how (and can even\n> veto populating it if set to \"none\"). We /could/ do it differently,\n> but I can't see why we should (and risk severe compatibility issues).\n\nI think removing `init` will cause some compatibility issues anyway,\nso I was re-imaging how you do it. I don't think update='none' and\n\"don't populate my submodule\" are distinct ideas, while a locally\nconfigured url=\"somwhere\" and \"please populate my submodule\" are (with\nthe blank-url case defaulting to the superproject itself).\n\n> > > 2) It can be used to follow moving upstreams (think of checking\n> > > out an earlier commit before the upstream was moved, you won't\n> > > be able to clone it from there without having the new setting\n> > > persist). And which repository you follow is a matter of trust,\n> > > so the extra \"git submodule sync\" in that case is a good thing\n> > > to have.\n> > > \n> > > So I believe 'url' is the only setting that should be copied\n> > > into .git/config while all the others shouldn't.\n> > \n> > If you want to override the old repository location for an old\n> > commit, setting submodule..url makes sense. My rewritten\n> > `sync` updates the local submodule..url in the superproject\n> > if the configuration option is already set [1]. Perhaps a `sync\n> > --local` invocation should forcibly populate the local\n> > submodule..url to make this workflow easier. Bundling sugar\n> > for this special case should not happen under an extra command\n> > called `init`.\n> \n> What real world problems do we have with the current init/sync that\n> this approach would solve?\n\nI don't have any, but in my `update --remote` series I'm adding two\nnew config options that are handled differently (define in\n.gitmodules, override in superproject .git/config) than existing\nsubmodules options. I'm trying to avoid confusing users by\nstandardizing on the more flexible method, which avoids copying stuff\ninto the superproject's .git/config, and under which the current\n`init` functionality doesn't make much sense.\n\n> > > > [snip get_submodule_config()]\n> > >\n> > > Something like that makes sense. You can use it for the settings\n> > > you add first and we can then reuse that for 'update' in a\n> > > separate patch later.\n> > \n> > I'm currently working out the details independently against\n> > v1.8.0. This will be a fairly major shift, so I think it should\n> > stay independent of `update --remote`. The `update --remote`\n> > stuff should be easy to adjust/rebase if the `init`\n> > removal/adjustment develops into something acceptable.\n> \n> I totally agree. Let's get the `update --remote` stuff ready first.\n\nOk, but we'll have the possible confusion about option setting that I\nmention above. Still, it's good to minimize the number of irons in\nthe fire, and an `init` removal will probably not get in until 2.0\nanyway. If other people are fine with the different initialization\npaths, I'll put the init-removal on hold for now.\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":"204397","messageId":"50BA4695.7030008@web.de","threadId":"32245","inReplyTo":"20121201174920.GE4823@odin.tremily.us","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-12-01T18:04:05Z","receivedAt":"2012-12-01T18:04:05Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 01.12.2012 18:49, schrieb W. Trevor King:\n> I think removing `init` will cause some compatibility issues anyway,\n> so I was re-imaging how you do it. I don't think update='none' and\n> \"don't populate my submodule\" are distinct ideas, while a locally\n> configured url=\"somwhere\" and \"please populate my submodule\" are (with\n> the blank-url case defaulting to the superproject itself).\n\nWhy would we want to remove \"init\"? It still has to copy the \"url\"\nsetting (and it would be a compatibility nightmare if we would change\nthat, imagine different git versions used on the same work tree).\n\n>> What real world problems do we have with the current init/sync that\n>> this approach would solve?\n> \n> I don't have any, but in my `update --remote` series I'm adding two\n> new config options that are handled differently (define in\n> .gitmodules, override in superproject .git/config) than existing\n> submodules options.\n\nNo, they're not. They are just handled differently than \"url\" and\n\"update\", but will behave just like \"fetchRecurseSubmodules\" and\n\"ignore\" do since day one. And as I explained in another mail I\nthink \"url\" is special and \"update\" should be change to behave like\nthe other two some day.\n"},{"id":"204398","messageId":"20121201181643.GF4823@odin.tremily.us","threadId":"32245","inReplyTo":"50BA4695.7030008@web.de","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-01T18:16:43Z","receivedAt":"2012-12-01T18:16:43Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sat, Dec 01, 2012 at 07:04:05PM +0100, Jens Lehmann wrote:\n> Am 01.12.2012 18:49, schrieb W. Trevor King:\n> > I think removing `init` will cause some compatibility issues anyway,\n> > so I was re-imaging how you do it. I don't think update='none' and\n> > \"don't populate my submodule\" are distinct ideas, while a locally\n> > configured url=\"somwhere\" and \"please populate my submodule\" are (with\n> > the blank-url case defaulting to the superproject itself).\n> \n> Why would we want to remove \"init\"? It still has to copy the \"url\"\n> setting (and it would be a compatibility nightmare if we would change\n> that, imagine different git versions used on the same work tree).\n\nIn my init-less rewrite, it doesn't have to copy the url setting.\nPeople using older versions of Git would need to run `init` using\ntheir old version. Having the url defined in .git/config won't break\nmy init-less submodule commands, it just means that the value in\n.gitmodules will be masked.\n\n> >> What real world problems do we have with the current init/sync that\n> >> this approach would solve?\n> > \n> > I don't have any, but in my `update --remote` series I'm adding two\n> > new config options that are handled differently (define in\n> > .gitmodules, override in superproject .git/config) than existing\n> > submodules options.\n> \n> No, they're not. They are just handled differently than \"url\" and\n> \"update\", but will behave just like \"fetchRecurseSubmodules\" and\n> \"ignore\" do since day one. And as I explained in another mail I\n> think \"url\" is special and \"update\" should be change to behave like\n> the other two some day.\n\nI somehow missed those earlier. Thanks for correcting my tunnel\nvision. This makes me much happier about postponing the init-removal.\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":"204401","messageId":"7vy5hhmcwp.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"50BA3412.60309@web.de","subject":"Re: [PATCH] submodule: add 'deinit' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-02T02:00:06Z","receivedAt":"2012-12-02T02:00:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> With \"git submodule init\" the user is able to tell git he cares about one\n> or more submodules and wants to have it populated on the next call to \"git\n> submodule update\". But currently there is no easy way he could tell git he\n> does not care about a submodule anymore and wants to get rid of his local\n> work tree (except he knows a lot about submodule internals and removes the\n> \"submodule.$name.url\" setting from .git/config himself).\n>\n> Help those users by providing a 'deinit' command. This removes the url\n> setting from .git/config either for the given submodule(s) or for all\n> those which have been initialized if none were given. Complain only when\n> for a submodule given on the command line the url setting can't be found\n> in .git/config.\n>\n> Add tests and link the man pages of \"git submodule deinit\" and \"git rm\" to\n> assist the user in deciding whether removing or unregistering the submodule\n> is the right thing to do for him.\n>\n> Signed-off-by: Jens Lehmann \n> ---\n\nI fully agree with your analysis on the reason why the \"url\" element\nis special and has to be copied to $GIT_DIR/config, but when you\ndeinit (or uninit) a submodule to say you are no longer interested\nin it and do not want it populated in the context of the\nsuperproject, I am not sure if removing only submodule.$name.url (so\nthat when you later decide to \"init\" it again, you will keep the\nvalues for submodule.$name.update and other things from the previous\nlife) is the sane thing to do, or it is better to remove\nsubmodule.$name.* altogether as if an earlier \"init\" has never\nhappened. Would it be worth analyzing the pros-and-cons here?\n\n> Am 01.12.2012 16:56, schrieb Jens Lehmann:\n>> Am 01.12.2012 00:52, schrieb Phil Hord:\n>>> If I never 'submodule init' a submodule, it does not get visited by\n>>> 'git submodule foreach', among others. I think some people use this\n>>> behavior explicitly.\n>>>\n>>> On the other hand, I've also notice that a submodule which I have\n>>> removed does not get de-inited later one. It causes my 'git submodule\n>>> foreach' to emit errors. :-(\n>> \n>> I'm currently hacking on \"git submodule deinit\" which removes the 'url'\n>> setting from git/config. This should do the trick for you, right?\n>\n> And here we go ...\n>\n>\n> Documentation/git-rm.txt | 4 ++++\n> Documentation/git-submodule.txt | 11 +++++++++\n> git-submodule.sh | 50 ++++++++++++++++++++++++++++++++++++++++-\n> t/t7400-submodule-basic.sh | 11 +++++++++\n> 4 files changed, 75 insertions(+), 1 deletion(-)\n>\n> diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt\n> index 262436b..ec42bf5 100644\n> --- a/Documentation/git-rm.txt\n> +++ b/Documentation/git-rm.txt\n> @@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree.\n> Ignored files are deemed expendable and won't stop a submodule's work\n> tree from being removed.\n>\n> +If you only want to remove the local checkout of a submodule from your\n> +work tree without committing that use `git submodule deinit` instead\n> +(see linkgit:git-submodule[1]).\n> +\n> EXAMPLES\n> --------\n> `git rm Documentation/\\*.txt`::\n> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> index b1de3ba..fba77f6 100644\n> --- a/Documentation/git-submodule.txt\n> +++ b/Documentation/git-submodule.txt\n> @@ -13,6 +13,7 @@ SYNOPSIS\n> \t [--reference ] [--] []\n> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]\n> 'git submodule' [--quiet] init [--] [...]\n> +'git submodule' [--quiet] deinit [--] [...]\n> 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]\n> \t [--reference ] [--merge] [--recursive] [--] [...]\n> 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]\n> @@ -134,6 +135,16 @@ init::\n> \tthe explicit 'init' step if you do not intend to customize\n> \tany submodule locations.\n>\n> +deinit::\n> +\tUnregister the submodules, i.e. remove the `submodule.$name.url`\n> +\tsetting from .git/config. Further calls to `git submodule update`,\n> +\t`git submodule foreach` and `git submodule sync` will skip any\n> +\tunregistered submodules until they are initialized again, so use\n> +\tthis command if you don't want to have a local checkout of the\n> +\tsubmodule in your work tree anymore. If you really want to remove\n> +\ta submodule from the repository and commit that use\n> +\tlinkgit:git-rm[1] instead.\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> diff --git a/git-submodule.sh b/git-submodule.sh\n> index 2365149..4059a2e 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -8,6 +8,7 @@ dashless=$(basename \"$0\" | sed -e 's/-/ /')\n> USAGE=\"[--quiet] add [-b ] [-f|--force] [--name ] [--reference ] [--] []\n> or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]\n> or: $dashless [--quiet] init [--] [...]\n> + or: $dashless [--quiet] deinit [--] [...]\n> or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n> or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ] [commit] [--] [...]\n> or: $dashless [--quiet] foreach [--recursive] \n> @@ -516,6 +517,53 @@ cmd_init()\n> }\n>\n> #\n> +# Unregister submodules from .git/config\n> +#\n> +# $@ = requested paths (default to all)\n> +#\n> +cmd_deinit()\n> +{\n> +\t# parse $args after \"submodule ... init\".\n> +\twhile test $# -ne 0\n> +\tdo\n> +\t\tcase \"$1\" in\n> +\t\t-q|--quiet)\n> +\t\t\tGIT_QUIET=1\n> +\t\t\t;;\n> +\t\t--)\n> +\t\t\tshift\n> +\t\t\tbreak\n> +\t\t\t;;\n> +\t\t-*)\n> +\t\t\tusage\n> +\t\t\t;;\n> +\t\t*)\n> +\t\t\tbreak\n> +\t\t\t;;\n> +\t\tesac\n> +\t\tshift\n> +\tdone\n> +\n> +\tmodule_list \"$@\" |\n> +\twhile read mode sha1 stage sm_path\n> +\tdo\n> +\t\tdie_if_unmatched \"$mode\"\n> +\t\tname=$(module_name \"$sm_path\") || exit\n> +\t\turl=$(git config submodule.\"$name\".url)\n> +\t\tif test -z \"$url\"\n> +\t\tthen\n> +\t\t\t# Only mention uninitialized submodules when its\n> +\t\t\t# path have been specified\n> +\t\t\ttest \"$#\" != \"0\" &&\n> +\t\t\tsay \"$(eval_gettext \"No url found for submodule path '\\$sm_path' in .git/config\")\"\n> +\t\t\tcontinue\n> +\t\tfi\n> +\t\tgit config --unset submodule.\"$name\".url &&\n> +\t\tsay \"$(eval_gettext \"Submodule '\\$name' (\\$url) unregistered\")\"\n> +\tdone\n> +}\n> +\n> +#\n> # Update each submodule path to correct revision, using clone and checkout as needed\n> #\n> # $@ = requested paths (default to all)\n> @@ -1108,7 +1156,7 @@ cmd_sync()\n> while test $# != 0 && test -z \"$command\"\n> do\n> \tcase \"$1\" in\n> -\tadd | foreach | init | update | status | summary | sync)\n> +\tadd | foreach | init | deinit | update | status | summary | sync)\n> \t\tcommand=$1\n> \t\t;;\n> \t-q|--quiet)\n> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\n> index de7d453..803bda7 100755\n> --- a/t/t7400-submodule-basic.sh\n> +++ b/t/t7400-submodule-basic.sh\n> @@ -756,4 +756,15 @@ test_expect_success 'submodule add with an existing name fails unless forced' '\n> \t)\n> '\n>\n> +test_expect_success 'submodule deinit should unregister submodule url from .git/config' '\n> +\turl=$(git config submodule.example.url) &&\n> +\tgit submodule deinit &&\n> +\ttest -z \"$(git config submodule.example.url)\"\n> +'\n> +\n> +test_expect_success 'submodule deinit complains only when explicitly used on an uninitialized submodule' '\n> +\tgit submodule deinit &&\n> +\ttest_must_fail git submodule deinit example\n> +'\n> +\n> test_done\n"},{"id":"204412","messageId":"cover.1354417618.git.wking@tremily.us","threadId":"32245","inReplyTo":"20121130032719.GE29257@odin.tremily.us","subject":"[PATCH v6 0/4] submodule update: add --remote for submodule's upstream changes","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-02T03:17:00Z","receivedAt":"2012-12-02T03:17:00Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nOn Thu, Nov 29, 2012 at 10:27:19PM -0500, W. Trevor King wrote:\n> On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote:\n> > I've always felt that the \"origin\" defaults are broken and are simply\n> > being ignored because most users do not trip over them. But ISTR that\n> > submodule commands use the remote indicated by the superproject's\n> > current remote-tracking configuration, with a fallback to 'origin' if\n> > there is none. Sort of a \"best effort\" algorithm, I think. Am I\n> > remembering that wrong?\n>\n> The current code uses a bare \"git-fetch\". I'm not sure what that\n> defaults to if you're on a detached head. If it bothers you, I'm fine\n> adding the submodule..remote option in v6.\n\nHere it is. Now the remote defaults to $(get_default_remote) with an\noptional override via submodule..remote.\n\nChanges since v5:\n\n* New patch 1 for easy config variable setup.\n* Minor tweaks and rewordings in patches 2 and 3 (v5 patches 1 and 2).\n* New patch 4 adding submodule..remote.\n\nI'm fine with squashing patches 1, 2, and 4 together, if people prefer\na more compact series.\n\nW. Trevor King (4):\n submodule: add get_submodule_config helper funtion\n submodule update: add --remote for submodule's upstream changes\n submodule add: If --branch is given, record it in .gitmodules\n submodule update: add submodule..remote config option\n\n Documentation/config.txt | 8 ++++-\n Documentation/git-submodule.txt | 27 ++++++++++++++-\n Documentation/gitmodules.txt | 5 +++\n git-submodule.sh | 74 ++++++++++++++++++++++++++++++++++++++---\n t/t7400-submodule-basic.sh | 1 +\n t/t7406-submodule-update.sh | 49 +++++++++++++++++++++++++++\n 6 files changed, 158 insertions(+), 6 deletions(-)\n\n-- \n1.8.0.4.gf74b0fc.dirty\n"},{"id":"204411","messageId":"436a73a8fdc8f0695aa597d53483d4c4bae16ebb.1354417618.git.wking@tremily.us","threadId":"32245","inReplyTo":"cover.1354417618.git.wking@tremily.us","subject":"[PATCH v6 1/4] submodule: add get_submodule_config helper funtion","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-02T03:17:01Z","receivedAt":"2012-12-02T03:17:01Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nSeveral submodule configuration variables\n(e.g. fetchRecurseSubmodules) are read from .gitmodules with local\noverrides from the usual git config files. This shell function mimics\nthat logic to help initialize configuration variables in\ngit-submodule.sh.\n\nSigned-off-by: W. Trevor King \n---\n git-submodule.sh | 27 +++++++++++++++++++++++++++\n 1 file changed, 27 insertions(+)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex ab6b110..97ce5e4 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -152,6 +152,33 @@ die_if_unmatched ()\n }\n \n #\n+# Print a submodule configuration setting\n+#\n+# $1 = submodule name\n+# $2 = option name\n+# $3 = default value\n+#\n+# Checks in the usual git-config places first (for overrides),\n+# otherwise it falls back on .gitmodules. This allows you to\n+# distribute project-wide defaults in .gitmodules, while still\n+# customizing individual repositories if necessary. If the option is\n+# not in .gitmodules either, print a default value.\n+#\n+get_submodule_config()\n+{\n+\tname=\"$1\"\n+\toption=\"$2\"\n+\tdefault=\"$3\"\n+\tvalue=$(git config submodule.\"$name\".\"$option\")\n+\tif test -z \"$value\"\n+\tthen\n+\t\tvalue=$(git config -f .gitmodules submodule.\"$name\".\"$option\")\n+\tfi\n+\tprintf '%s' \"${value:-$default}\"\n+}\n+\n+\n+#\n # Map submodule path to submodule name\n #\n # $1 = path\n-- \n1.8.0.4.gf74b0fc.dirty\n"},{"id":"204410","messageId":"ec5d0235322619aff6c1c64b0a346efb0e4d0a32.1354417618.git.wking@tremily.us","threadId":"32245","inReplyTo":"cover.1354417618.git.wking@tremily.us","subject":"[PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-02T03:17:02Z","receivedAt":"2012-12-02T03:17:02Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nThe current `update` command incorporates the superproject's gitlinked\nSHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the\noptions you use, it may checkout $sha1, rebase the $subsha1 onto\n$sha1, or merge $sha1 into $subsha1. This helps you keep up with\nchanges in the upstream superproject.\n\nHowever, it's also useful to stay up to date with changes in the\nupstream subproject. Previous workflows for incorporating such\nchanges include the ungainly:\n\n $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n\nWith this patch, all of the useful functionality for incorporating\nsuperproject changes can be reused to incorporate upstream subproject\nupdates. When you specify --remote, the target $sha1 is replaced with\na $sha1 of the submodule's origin/master tracking branch. If you want\nto merge a different tracking branch, you can configure the\n`submodule..branch` option in `.gitmodules`. You can override\nthe `.gitmodules` configuration setting for a particular superproject\nby configuring the option in that superproject's default configuration\n(using the usual configuration hierarchy, e.g. `.git/config`,\n`~/.gitconfig`, etc.).\n\nPrevious use of submodule..branch\n=======================================\n\nBecause we're adding a new configuration option, it's a good idea to\ncheck if anyone else is already using the option. The foreach-pull\nexample above was described by Ævar 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\nAlthough the --remote functionality is using `submodule..branch`\nslightly differently, the effect is the same. The foreach-pull\nexample uses the option to record the name of the local branch to\ncheckout before pulls. The tracking branch to be pulled is recorded\nin `.git/modules//config`, which was initialized by the module\nclone during `submodule add` or `submodule init`. Because the branch\nname stored in `submodule..branch` was likely the same as the\nbranch name used during the initial `submodule add`, the same branch\nwill be pulled in each workflow.\n\nImplementation details\n======================\n\nIn order to ensure a current tracking branch state, `update --remote`\nfetches the submodule's remote repository before calculating the\nSHA-1. However, I didn't change the logic guarding the existing fetch:\n\n if test -z \"$nofetch\"\n then\n # Run fetch only if $sha1 isn't present or it\n # is not reachable from a ref.\n (clear_local_git_env; cd \"$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 '\\$path'\")\"\n fi\n\nThere will not be a double-fetch, because the new $sha1 determined\nafter the `--remote` triggered fetch should always exist in the\nrepository. If it doesn't, it's because some racy process removed it\nfrom the submodule's repository and we *should* be re-fetching.\n\nSigned-off-by: W. Trevor King \n---\n Documentation/config.txt | 7 ++++++-\n Documentation/git-submodule.txt | 25 ++++++++++++++++++++++++-\n Documentation/gitmodules.txt | 5 +++++\n git-submodule.sh | 22 +++++++++++++++++++++-\n t/t7406-submodule-update.sh | 31 +++++++++++++++++++++++++++++++\n 5 files changed, 87 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 11f320b..6f4663c 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1998,7 +1998,12 @@ submodule..update::\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-\tlinkgit:git-submodule[1] and linkgit:gitmodules[5] for details.\n+\n+submodule..branch::\n+\tThe remote branch name for a submodule, used by `git submodule\n+\tupdate --remote`. Set this option to override the value found in\n+\tthe `.gitmodules` file. See linkgit:git-submodule[1] and\n+\tlinkgit:gitmodules[5] for details.\n \n submodule..fetchRecurseSubmodules::\n \tThis option can be used to control recursive fetching of this\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex b4683bb..72dd52f 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -13,7 +13,7 @@ SYNOPSIS\n \t [--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] [--remote] [-N|--no-fetch] [--rebase]\n \t [--reference ] [--merge] [--recursive] [--] [...]\n 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]\n \t [commit] [--] [...]\n@@ -236,6 +236,29 @@ OPTIONS\n \t(the default). This limit only applies to modified submodules. The\n \tsize is always limited to 1 for added/deleted/typechanged submodules.\n \n+--remote::\n+\tThis option is only valid for the update command. Instead of using\n+\tthe superproject's recorded SHA-1 to update the submodule, use the\n+\tstatus of the submodule's remote tracking branch. The remote used\n+\tis branch's remote (`branch..remote`), defaulting to `origin`.\n+\tThe remote branch used defaults to `master`, but the branch name may\n+\tbe overridden by setting the `submodule..branch` option in\n+\teither `.gitmodules` or `.git/config` (with `.git/config` taking\n+\tprecedence).\n++\n+This works for any of the supported update procedures (`--checkout`,\n+`--rebase`, etc.). The only change is the source of the target SHA-1.\n+For example, `submodule update --remote --merge` will merge upstream\n+submodule changes into the submodules, while `submodule update\n+--merge` will merge superproject gitlink changes into the submodules.\n++\n+In order to ensure a current tracking branch state, `update --remote`\n+fetches the submodule's remote repository before calculating the\n+SHA-1. This makes `submodule update --remote --merge` similar to\n+running `git pull` in the submodule. If you don't want to fetch (for\n+something closer to `git merge`), you should use `submodule update\n+--remote --no-fetch --merge`.\n+\n -N::\n --no-fetch::\n \tThis option is only valid for the update command.\ndiff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt\nindex 4effd78..4004fa6 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 remote branch name for tracking updates in the upstream submodule.\n+\tIf the option is not specified, it defaults to 'master'. See the\n+\t`--remote` documentation in linkgit:git-submodule[1] for details.\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 97ce5e4..104b5de 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -8,7 +8,8 @@ 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] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n+ges\n or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ] [commit] [--] [...]\n or: $dashless [--quiet] foreach [--recursive] \n or: $dashless [--quiet] sync [--] [...]\"\n@@ -26,6 +27,7 @@ cached=\n recursive=\n init=\n files=\n+remote=\n nofetch=\n update=\n prefix=\n@@ -536,6 +538,9 @@ cmd_update()\n \t\t-i|--init)\n \t\t\tinit=1\n \t\t\t;;\n+\t\t--remote)\n+\t\t\tremote=1\n+\t\t\t;;\n \t\t-N|--no-fetch)\n \t\t\tnofetch=1\n \t\t\t;;\n@@ -596,6 +601,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=$(get_submodule_config \"$name\" branch master)\n \t\tif ! test -z \"$update\"\n \t\tthen\n \t\t\tupdate_module=$update\n@@ -630,6 +636,20 @@ 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 -n \"$remote\"\n+\t\tthen\n+\t\t\tif test -z \"$nofetch\"\n+\t\t\tthen\n+\t\t\t\t# Fetch remote before determining tracking $sha1\n+\t\t\t\t(clear_local_git_env; cd \"$sm_path\" && git-fetch) ||\n+\t\t\t\tdie \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n+\t\t\tfi\n+\t\t\tremote_name=$(get_default_remote)\n+\t\t\tsha1=$(clear_local_git_env; cd \"$sm_path\" &&\n+\t\t\t\tgit rev-parse --verify \"${remote_name}/${branch}\") ||\n+\t\t\tdie \"$(eval_gettext \"Unable to find current ${remote_name}/${branch} revision in submodule path '\\$sm_path'\")\"\n+\t\tfi\n+\n \t\tif test \"$subsha1\" != \"$sha1\" -o -n \"$force\"\n \t\tthen\n \t\t\tsubforce=$force\ndiff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\nindex 1542653..a567834 100755\n--- a/t/t7406-submodule-update.sh\n+++ b/t/t7406-submodule-update.sh\n@@ -135,6 +135,37 @@ test_expect_success 'submodule update --force forcibly checks out submodules' '\n \t)\n '\n \n+test_expect_success 'submodule update --remote should fetch upstream changes' '\n+\t(cd submodule &&\n+\t echo line4 >> file &&\n+\t git add file &&\n+\t test_tick &&\n+\t git commit -m \"upstream line4\"\n+\t) &&\n+\t(cd super &&\n+\t git submodule update --remote --force submodule &&\n+\t cd submodule &&\n+\t test \"$(git log -1 --oneline)\" = \"$(GIT_DIR=../../submodule/.git git log -1 --oneline)\"\n+\t)\n+'\n+\n+test_expect_success 'local config should override .gitmodules branch' '\n+\t(cd submodule &&\n+\t git checkout -b test-branch &&\n+\t echo line5 >> file &&\n+\t git add file &&\n+\t test_tick &&\n+\t git commit -m \"upstream line5\" &&\n+\t git checkout master\n+\t) &&\n+\t(cd super &&\n+\t git config submodule.submodule.branch test-branch &&\n+\t git submodule update --remote --force submodule &&\n+\t cd submodule &&\n+\t test \"$(git log -1 --oneline)\" = \"$(GIT_DIR=../../submodule/.git git log -1 --oneline test-branch)\"\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.4.gf74b0fc.dirty\n"},{"id":"204408","messageId":"be4777f670198aedae24c3974fddd575fc734c0c.1354417619.git.wking@tremily.us","threadId":"32245","inReplyTo":"cover.1354417618.git.wking@tremily.us","subject":"[PATCH v6 3/4] submodule add: If --branch is given, record it in .gitmodules","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-02T03:17:03Z","receivedAt":"2012-12-02T03:17:03Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nThis allows you to easily record a submodule..branch option in\n.gitmodules when you add a new submodule. With this patch,\n\n $ git submodule add -b []\n $ git config -f .gitmodules submodule..branch \n\nreduces to\n\n $ git submodule add -b []\n\nThis means that future calls to\n\n $ git submodule update --remote ...\n\nwill get updates from the same branch that you used to initialize the\nsubmodule, which is usually what you want.\n\nSigned-off-by: W. Trevor King \n---\n Documentation/git-submodule.txt | 2 ++\n git-submodule.sh | 4 ++++\n t/t7400-submodule-basic.sh | 1 +\n 3 files changed, 7 insertions(+)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 72dd52f..988bba9 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -208,6 +208,8 @@ OPTIONS\n -b::\n --branch::\n \tBranch of repository to add as submodule.\n+\tThe name of the branch is recorded as `submodule..branch` in\n+\t`.gitmodules` for `update --remote`.\n \n -f::\n --force::\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 104b5de..27b02fe 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -395,6 +395,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 \"$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..90e2915 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 \"initial\" = \"$(git config -f .gitmodules submodule.submod-branch.branch)\" &&\n \t\tgit submodule init\n \t) &&\n \n-- \n1.8.0.4.gf74b0fc.dirty\n"},{"id":"204409","messageId":"b9635b844051e681af1c80447fedac5ee77280f7.1354417619.git.wking@tremily.us","threadId":"32245","inReplyTo":"cover.1354417618.git.wking@tremily.us","subject":"[PATCH v6 4/4] submodule update: add submodule..remote config option","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-02T03:17:04Z","receivedAt":"2012-12-02T03:17:04Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nDon't force the user to clone from the tracked repository\n(branch..remote) or `origin`. By setting\nsubmodule..remote in .gitmodules or the usual git config files,\nyou can easily point a submodule at a different remote when using\n`submodule update --remote`.\n\nThe configured remote name is also used in `submodule sync` to\ndetermine which remote..url is updated with the submodule's\norigin URL.\n\nSigned-off-by: W. Trevor King \n---\n Documentation/config.txt | 7 ++++---\n Documentation/git-submodule.txt | 10 +++++-----\n git-submodule.sh | 27 +++++++++++++++++++++------\n t/t7406-submodule-update.sh | 18 ++++++++++++++++++\n 4 files changed, 48 insertions(+), 14 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 6f4663c..c54b9b4 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1999,10 +1999,11 @@ submodule..update::\n \tby 'git submodule init'; edit them to override the\n \tURL and other values found in the `.gitmodules` file. See\n \n+submodule..remote::\n submodule..branch::\n-\tThe remote branch name for a submodule, used by `git submodule\n-\tupdate --remote`. Set this option to override the value found in\n-\tthe `.gitmodules` file. See linkgit:git-submodule[1] and\n+\tThe remote repository and branch names for a submodule, used by `git\n+\tsubmodule update --remote`. Set these options to override the value\n+\tfound in the `.gitmodules` file. See linkgit:git-submodule[1] and\n \tlinkgit:gitmodules[5] for details.\n \n submodule..fetchRecurseSubmodules::\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 988bba9..1d8d5f1 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -242,11 +242,11 @@ OPTIONS\n \tThis option is only valid for the update command. Instead of using\n \tthe superproject's recorded SHA-1 to update the submodule, use the\n \tstatus of the submodule's remote tracking branch. The remote used\n-\tis branch's remote (`branch..remote`), defaulting to `origin`.\n-\tThe remote branch used defaults to `master`, but the branch name may\n-\tbe overridden by setting the `submodule..branch` option in\n-\teither `.gitmodules` or `.git/config` (with `.git/config` taking\n-\tprecedence).\n+\tis branch's remote (`branch..remote`, defaulting to `origin`),\n+\tand the remote branch used defaults to `master`, but either may be\n+\toverridden by setting the `submodule..remote` or\n+\t`submodule..branch` option in `.gitmodules` or `.git/config`\n+\t(with `.git/config` taking precedence).\n +\n This works for any of the supported update procedures (`--checkout`,\n `--rebase`, etc.). The only change is the source of the target SHA-1.\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 27b02fe..3e39e29 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -179,6 +179,21 @@ get_submodule_config()\n \tprintf '%s' \"${value:-$default}\"\n }\n \n+#\n+# Print the name of a submodule's configured remote\n+#\n+# $1 = submodule name\n+#\n+get_submodule_remote()\n+{\n+\tname=\"$1\"\n+\tremote=$(get_submodule_config \"$name\" remote)\n+\tif test -z \"$remote\"\n+\tthen\n+\t\tremote=$(get_default_remote)\n+\tfi\n+\tprintf '%s' \"${remote}\"\n+}\n \n #\n # Map submodule path to submodule name\n@@ -605,6 +620,7 @@ cmd_update()\n \t\tfi\n \t\tname=$(module_name \"$sm_path\") || exit\n \t\turl=$(git config submodule.\"$name\".url)\n+\t\tremote_name=$(get_submodule_remote \"$name\")\n \t\tbranch=$(get_submodule_config \"$name\" branch master)\n \t\tif ! test -z \"$update\"\n \t\tthen\n@@ -645,10 +661,9 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\tif test -z \"$nofetch\"\n \t\t\tthen\n \t\t\t\t# Fetch remote before determining tracking $sha1\n-\t\t\t\t(clear_local_git_env; cd \"$sm_path\" && git-fetch) ||\n-\t\t\t\tdie \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n+\t\t\t\t(clear_local_git_env; cd \"$sm_path\" && git-fetch \"$remote_name\") ||\n+\t\t\t\tdie \"$(eval_gettext \"Unable to fetch '\\$remote_name' in submodule path '\\$sm_path'\")\"\n \t\t\tfi\n-\t\t\tremote_name=$(get_default_remote)\n \t\t\tsha1=$(clear_local_git_env; cd \"$sm_path\" &&\n \t\t\t\tgit rev-parse --verify \"${remote_name}/${branch}\") ||\n \t\t\tdie \"$(eval_gettext \"Unable to find current ${remote_name}/${branch} revision in submodule path '\\$sm_path'\")\"\n@@ -669,8 +684,8 @@ Maybe you want to use 'update --init'?\")\"\n \t\t\t\t# is not reachable from a ref.\n \t\t\t\t(clear_local_git_env; cd \"$sm_path\" &&\n \t\t\t\t\t( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&\n-\t\t\t\t\t test -z \"$rev\") || git-fetch)) ||\n-\t\t\t\tdie \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n+\t\t\t\t\t test -z \"$rev\") || git-fetch \"$remote_name\")) ||\n+\t\t\t\tdie \"$(eval_gettext \"Unable to fetch '\\$remote_name' in submodule path '\\$sm_path'\")\"\n \t\t\tfi\n \n \t\t\t# Is this something we just cloned?\n@@ -1110,7 +1125,7 @@ cmd_sync()\n \t\t\t(\n \t\t\t\tclear_local_git_env\n \t\t\t\tcd \"$sm_path\"\n-\t\t\t\tremote=$(get_default_remote)\n+\t\t\t\tremote=$(get_submodule_remote \"$name\")\n \t\t\t\tgit config remote.\"$remote\".url \"$sub_origin_url\"\n \t\t\t)\n \t\t\tfi\ndiff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\nindex a567834..86c85f8 100755\n--- a/t/t7406-submodule-update.sh\n+++ b/t/t7406-submodule-update.sh\n@@ -149,6 +149,24 @@ test_expect_success 'submodule update --remote should fetch upstream changes' '\n \t)\n '\n \n+test_expect_success 'local config should override .gitmodules remote' '\n+\t(cd submodule &&\n+\t echo line5-master >> file &&\n+\t git add file &&\n+\t test_tick &&\n+\t git commit -m \"upstream line5-master\"\n+\t) &&\n+\t(cd super/submodule &&\n+\t git remote rename origin test-remote\n+\t) &&\n+\t(cd super &&\n+\t git config submodule.submodule.remote test-remote &&\n+\t git submodule update --remote --force submodule &&\n+\t cd submodule &&\n+\t test \"$(git log -1 --oneline)\" = \"$(GIT_DIR=../../submodule/.git git log -1 --oneline)\"\n+\t)\n+'\n+\n test_expect_success 'local config should override .gitmodules branch' '\n \t(cd submodule &&\n \t git checkout -b test-branch &&\n-- \n1.8.0.4.gf74b0fc.dirty\n"},{"id":"204427","messageId":"20121202190929.GG9401@odin.tremily.us","threadId":"32245","inReplyTo":"7vy5hhmcwp.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-02T19:09:29Z","receivedAt":"2012-12-02T19:09:29Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"Before I get into the details, I'd like to point out that I actually\nunderstand the purpose of `submodule init` now ;). To avoid further\nconfusion, my current one-line command summaries would be:\n\n init: mark a submodule as active for future submodule operation\n deinit: mark a submodule as inactive for future submodule operation\n sync: update remote..origin in submodules to reflect changes\n in .gitmodules or the superproject's remote URL.\n\nI don't think we disagree on that, we just don't agree on how to\nimplement it.\n\nCurrently, Git uses submodule..url in the superproject's local\nconfiguration as a marker for submodule activation. This is not (as\nfar as I know) discussed in the docs, which is why I initially\nmissunderstood the purpose of `init` to be “setup the superproject's\nlocal configuration so we don't have to keep resolving the submodules\nURL relative to the superproject's upstream URL”. With the proposed\n`deinit` docs, this role for the submodule..url is mentioned,\nbut not in a place where casual users will be able to easily connect\nit to the purpose of `init`.\n\nI floated using submodule..update (with 'none' for inactive and\nanything else for active) as an alternative marker:\n\nOn Sat, Dec 01, 2012 at 01:16:43PM -0500, W. Trevor King wrote:\n> On Sat, Dec 01, 2012 at 07:04:05PM +0100, Jens Lehmann wrote:\n> > Am 01.12.2012 18:49, schrieb W. Trevor King:\n> > > I think removing `init` will cause some compatibility issues anyway,\n> > > so I was re-imaging how you do it. I don't think update='none' and\n> > > \"don't populate my submodule\" are distinct ideas, while a locally\n> > > configured url=\"somwhere\" and \"please populate my submodule\" are (with\n> > > the blank-url case defaulting to the superproject itself).\n> > \n> > Why would we want to remove \"init\"? It still has to copy the \"url\"\n> > setting (and it would be a compatibility nightmare if we would change\n> > that, imagine different git versions used on the same work tree).\n> \n> In my init-less rewrite, it doesn't have to copy the url setting.\n> People using older versions of Git would need to run `init` using\n> their old version. Having the url defined in .git/config won't break\n> my init-less submodule commands, it just means that the value in\n> .gitmodules will be masked.\n\nbut that doesn't seem to be going over very well. Junio may have been\nweighing in obliquely with:\n\nOn Sat, Dec 01, 2012 at 06:00:06PM -0800, Junio C Hamano wrote:\n> Jens Lehmann writes:\n> > [snip v1 deinit commit message]\n> \n> I fully agree with your analysis on the reason why the \"url\" element\n> is special and has to be copied to $GIT_DIR/config, but when you\n> deinit (or uninit) a submodule to say you are no longer interested\n> in it and do not want it populated in the context of the\n> superproject, I am not sure if removing only submodule.$name.url (so\n> that when you later decide to \"init\" it again, you will keep the\n> values for submodule.$name.update and other things from the previous\n> life) is the sane thing to do, or it is better to remove\n> submodule.$name.* altogether as if an earlier \"init\" has never\n> happened. Would it be worth analyzing the pros-and-cons here?\n\nLet me take another stab at presenting my argument in favor of a\ndifferent activity marker.\n\nProposal:\n\nAdd a new boolean option, submodule..active, to explicitly mark\nsubmodules as active (with “active” defined as “to be returned by\nmodule_list()”). Strip down `init` (and the --init part of `update\n--init`) to just setting this option to true. `deinit` only sets this\noption to false (but a `deinit --clean` could remove the whole\nsubmodule. section).\n\nWith this in place, extracting URLs for submodule operations be\nsimilar to the extraction of other variables (.gitmodules defaults\nwith superproject-local .git/config overrides). This also makes it\neasier to track maintenance updates in .gitmodules-defined URLs,\nbecause you aren't forced to bake overrides into your local\n.git/config\n\nThe upgrade path from earlier versions of Git is easy: if\nsubmodule..active is unset, use the presence of\nsubmodule..url to determine its initial value.\n\nIn the case where you check out an earlier superproject commit which\nis missing a particular submodule (or remove a submodule without\ndeinit-ing), the presense of an active setting in .git/config should\nnot cause an error, which they currently seem to:\n\nOn Sat, Dec 01, 2012 at 11:37:14AM -0500, W. Trevor King wrote:\n> On Sat, Dec 01, 2012 at 04:56:02PM +0100, Jens Lehmann wrote:\n> > Am 01.12.2012 00:52, schrieb Phil Hord:\n> > > If I never 'submodule init' a submodule, it does not get visited by\n> > > 'git submodule foreach', among others. I think some people use this\n> > > behavior explicitly.\n> > >\n> > > On the other hand, I've also notice that a submodule which I have\n> > > removed does not get de-inited later one. It causes my 'git submodule\n> > > foreach' to emit errors. :-(\n> >\n> > I'm currently hacking on \"git submodule deinit\" which removes the 'url'\n> > setting from git/config. This should do the trick for you, right?\n> >\n> > Just removing that submodule automagically would not work that well, as\n> > it would deinitialize a submodule when you switch to a branch where it\n> > isn't present and you'd have to reinitialize it when you come back.\n>\n> I think this is another case where we should be looping through\n> submodules based on the revision-specific .gitmodules content, and\n> querying the local config only to determine if the user wants to\n> update them (to drop into them with foreach, etc.).\n\nThoughts?\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":"204428","messageId":"50BBACC3.1070504@web.de","threadId":"32245","inReplyTo":"20121130032719.GE29257@odin.tremily.us","subject":"Re: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-12-02T19:32:19Z","receivedAt":"2012-12-02T19:32:19Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 30.11.2012 04:27, schrieb W. Trevor King:\n> On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote:\n>> On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King wrote:\n>>> On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote:\n>>>> But I really don't want to figure out how to handle submodule\n>>>> collisions during a merge (or rebase!) of my superproject with changes that\n>>>> someone else auto-committed in his local $superproject as he and I\n>>>> arbitrarily floated up the upstream independently. There is nothing but\n>>>> loathing down that path.\n>>>\n>>> This is true. I'm not sure how gitlink collisions are currently\n>>> handled…\n>>\n>> They've always been trouble for me. But it may be that I am ignorant.\n> \n> I haven't dealt with any gitlink merges, but I think that supporting\n> easy gitlink merges is orthogonal to this --remote option. For simple\n> cases like \"autocommitted submodule floats\", one of the conflicting\n> gitlinks will be an ancestor of the other, so it should be easy to\n> automate that merge.\n\nSubmodule merges where one submodule commit is the ancestor of the\nother are already resolved automatically in recent git. So Phil's\nexample will just work as long as only fast-forward merges are needed.\n"},{"id":"204429","messageId":"50BBB22A.7050901@web.de","threadId":"32245","inReplyTo":"7vy5hhmcwp.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] submodule: add 'deinit' command","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-12-02T19:55:22Z","receivedAt":"2012-12-02T19:55:22Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 02.12.2012 03:00, schrieb Junio C Hamano:\n> Jens Lehmann writes:\n> \n>> With \"git submodule init\" the user is able to tell git he cares about one\n>> or more submodules and wants to have it populated on the next call to \"git\n>> submodule update\". But currently there is no easy way he could tell git he\n>> does not care about a submodule anymore and wants to get rid of his local\n>> work tree (except he knows a lot about submodule internals and removes the\n>> \"submodule.$name.url\" setting from .git/config himself).\n>>\n>> Help those users by providing a 'deinit' command. This removes the url\n>> setting from .git/config either for the given submodule(s) or for all\n>> those which have been initialized if none were given. Complain only when\n>> for a submodule given on the command line the url setting can't be found\n>> in .git/config.\n>>\n>> Add tests and link the man pages of \"git submodule deinit\" and \"git rm\" to\n>> assist the user in deciding whether removing or unregistering the submodule\n>> is the right thing to do for him.\n>>\n>> Signed-off-by: Jens Lehmann \n>> ---\n> \n> I fully agree with your analysis on the reason why the \"url\" element\n> is special and has to be copied to $GIT_DIR/config, but when you\n> deinit (or uninit) a submodule to say you are no longer interested\n> in it and do not want it populated in the context of the\n> superproject, I am not sure if removing only submodule.$name.url (so\n> that when you later decide to \"init\" it again, you will keep the\n> values for submodule.$name.update and other things from the previous\n> life) is the sane thing to do, or it is better to remove\n> submodule.$name.* altogether as if an earlier \"init\" has never\n> happened. Would it be worth analyzing the pros-and-cons here?\n\nSure. I was worried about throwing away other settings the user\nmight have set in the submodule.$name section and the first reflex\nwas to protect them. But thinking about that again I noticed we are\nalready throwing away a possibly user customized \"url\" setting, so\nwe already remove a possibly customized setting.\n\nMaybe the principle of least surprise is better followed when we\nnuke the whole section, as it might surprise the user more to have\na setting resurrected he customized in the last life cycle of the\nsubmodule than seeing that after an deinit followed by an init all\nformer customizations are consistently gone. So I tend to think now\nthat removing the whole section would be the better solution here.\n\nOpinions by other submodule users?\n"},{"id":"204430","messageId":"50BBBA29.2000106@web.de","threadId":"32245","inReplyTo":"20121202190929.GG9401@odin.tremily.us","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-12-02T20:29:29Z","receivedAt":"2012-12-02T20:29:29Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 02.12.2012 20:09, schrieb W. Trevor King:\n> Before I get into the details, I'd like to point out that I actually\n> understand the purpose of `submodule init` now ;). To avoid further\n> confusion, my current one-line command summaries would be:\n> \n> init: mark a submodule as active for future submodule operation\n> deinit: mark a submodule as inactive for future submodule operation\n> sync: update remote..origin in submodules to reflect changes\n> in .gitmodules or the superproject's remote URL.\n> \n> I don't think we disagree on that, we just don't agree on how to\n> implement it.\n\nNope, it is already implemented and you are arguing to change the\ncurrent implementation. To quote from another mail:\n\nAm 01.12.2012 18:49, schrieb W. Trevor King:\n> On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote:\n>> What real world problems do we have with the current init/sync that\n>> this approach would solve?\n>\n> I don't have any, ...\n\nWe don't want to change working code and cause compatibility issues\njust because we /could/ do things differently, no?\n"},{"id":"204432","messageId":"20121202211159.GA12429@odin.tremily.us","threadId":"32245","inReplyTo":"50BBBA29.2000106@web.de","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-02T21:11:59Z","receivedAt":"2012-12-02T21:11:59Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \nTo: Jens Lehmann , Junio C Hamano \nCc: Phil Hord , Git ,\n\tHeiko Voigt , Jeff King ,\n\tShawn Pearce , Nahor \nBcc: \nSubject: Re: [RFC] remove/deprecate 'submodule init' and 'sync'\nReply-To: \nIn-Reply-To: <50BBBA29.2000106@web.de>\n <50BBB22A.7050901@web.de>\n <20121202190929.GG9401@odin.tremily.us>\nOpenPGP: id=39A2F3FA2AB17E5D8764F388FC29BDCDF15F5BE8;\n url=http://tremily.us/pubkey.txt\n\nOn Sun, Dec 02, 2012 at 09:29:29PM +0100, Jens Lehmann wrote:\n> Am 02.12.2012 20:09, schrieb W. Trevor King:\n> > Before I get into the details, I'd like to point out that I actually\n> > understand the purpose of `submodule init` now ;). To avoid further\n> > confusion, my current one-line command summaries would be:\n> > \n> > init: mark a submodule as active for future submodule operation\n> > deinit: mark a submodule as inactive for future submodule operation\n> > sync: update remote..origin in submodules to reflect changes\n> > in .gitmodules or the superproject's remote URL.\n> > \n> > I don't think we disagree on that, we just don't agree on how to\n> > implement it.\n> \n> Nope, it is already implemented and you are arguing to change the\n> current implementation.\n\nAgreed.\n\n> To quote from another mail:\n> \n> Am 01.12.2012 18:49, schrieb W. Trevor King:\n> > On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote:\n> >> What real world problems do we have with the current init/sync that\n> >> this approach would solve?\n> >\n> > I don't have any, ...\n> \n> We don't want to change working code and cause compatibility issues\n> just because we /could/ do things differently, no?\n\nIn principle, yes, but in this case I think changing the\nimplementation does not risk much in the way of compatibility issues\n(it only hurts users who rely on `submodule init` setting\nsubmodule..url for reasons of their own. A few of the existing\ntests explictly check the url setting, so perhaps there are a number\nof users who do require this side effect?\n\nI think this risk is outweighed by the benefits of having a clearer\nactivation option. For example:\n\nOn Sun, Dec 02, 2012 at 08:55:22PM +0100, Jens Lehmann wrote:\n> Sure. I was worried about throwing away other settings the user\n> might have set in the submodule.$name section and the first reflex\n> was to protect them. But thinking about that again I noticed we are\n> already throwing away a possibly user customized \"url\" setting, so\n> we already remove a possibly customized setting.\n\nWith submodule..active, there's nothing customized that you'd\nhave to nuke on deinit (except 'active' iteself, which the user is\nexplicitly asking for).\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":"204442","messageId":"7vhao31s9e.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"50BBB22A.7050901@web.de","subject":"Re: [PATCH] submodule: add 'deinit' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-03T07:58:37Z","receivedAt":"2012-12-03T07:58:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> Maybe the principle of least surprise is better followed when we\n> nuke the whole section, as it might surprise the user more to have\n> a setting resurrected he customized in the last life cycle of the\n> submodule than seeing that after an deinit followed by an init all\n> former customizations are consistently gone. So I tend to think now\n> that removing the whole section would be the better solution here.\n\nI tend to agree; I suspect that a \"deinit\" would be mostly done\neither to\n\n (1) correct mistakes the user made during a recent \"init\" and\n perhaps \"sync\"; or\n\n (2) tell Git that the user has finished woing with this particular\n submodule and does not intend to use it for quite a while.\n\nFor both (1) and (2), I think it would be easier to users if we gave\nthem a clean slate, the same state as the one the user who never had\nran \"init\" on it would be in. A user in situation (1) is asking for\na clean slate, and a user in situation (2) is better served if he\ndoes not have to worry about leftover entries in $GIT_DIR/config he\nhas long forgotten from many months ago (during which time the way\nthe project uses the particular submodule may well have changed)\ngiving non-standard experience different from what other project\nparticipants would get.\n\nIf there were a sane workflow where it makes sense to frequently run\n\"deinit\" followed by some operation followed by \"init\", it may be\nhelpful to have an option to keep the other customization. And one\nconsideration when implementing that \"deinit --keep-customization\"\noption might be to introduce the submodule.$name.activated boolean;\nthat way, the operation can keep the customized upstream URL.\n\nIn any case, it needs to be shown that such a workflow exists in the\nfirst place to justify \"deinit --keep-customization\". I think the\ndefault should be to remove the submodule.$name section.\n"},{"id":"204451","messageId":"20121203153855.GA14981@odin.tremily.us","threadId":"32245","inReplyTo":"20121202211159.GA12429@odin.tremily.us","subject":"Re: [RFC] remove/deprecate 'submodule init' and 'sync'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-03T15:38:55Z","receivedAt":"2012-12-03T15:38:55Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sun, Dec 02, 2012 at 04:11:59PM -0500, W. Trevor King wrote:\n> On Sun, Dec 02, 2012 at 09:29:29PM +0100, Jens Lehmann wrote:\n> > Am 01.12.2012 18:49, schrieb W. Trevor King:\n> > > On Sat, Dec 01, 2012 at 06:25:17PM +0100, Jens Lehmann wrote:\n> > >> What real world problems do we have with the current init/sync that\n> > >> this approach would solve?\n> > >\n> > > I don't have any, ...\n> > \n> > We don't want to change working code and cause compatibility issues\n> > just because we /could/ do things differently, no?\n> \n> In principle, yes, but in this case I think changing the\n> implementation does not risk much in the way of compatibility issues\n> (it only hurts users who rely on `submodule init` setting\n> submodule..url for reasons of their own. A few of the existing\n> tests explictly check the url setting, so perhaps there are a number\n> of users who do require this side effect?\n> \n> I think this risk is outweighed by the benefits of having a clearer\n> activation option.\n\nFor anyone interested in an implementation of my\nsubmodule..active proposal, I've posted an initial version:\n\n git://github.com/wking/git.git wtk/submodule.name.active\n\nI can re-post it here as a PATCH series, but I don't think we're at\nthe level of patch-specific feedback yet.\n\nI'm currently pretty happy with it except for the last commit:\n\n HACK work around missing index entry for existing empty submodules\n\nTo solve that cleanly, I'd need a solution to the commit-less existing\nrepository problem which I mentioned earlier:\n\nOn Sat, Dec 01, 2012 at 11:54:04AM -0500, W. Trevor King wrote:\n> I'm currently stuck with adding a commit-less existing repository as a\n> submodule (which happens in t7400-submodule-basic.sh, ../bar/a/b/c\n> works with relative local path):\n> \n> $ mkdir -p super/sub\n> $ cd super\n> $ git init\n> $ (cd sub && git init)\n> $ git submodule add ./ sub\n> $ git status\n> # On branch master\n> #\n> # Initial commit\n> #\n> # Changes to be committed:\n> # (use \"git rm --cached ...\" to unstage)\n> #\n> # new file: .gitmodules\n> #\n> \n> What I'm missing is a gitlink form sub for 'Subproject commit\n> 00000...' or some such. When the subproject has an actual commit,\n> things work as expected:\n> \n> $ mkdir -p super/sub\n> $ cd super\n> $ git init\n> $ (cd sub && git init && echo line-1 > file && git add file && git commit -m file)\n> $ git submodule add ./ sub\n> $ git status\n> # On branch master\n> #\n> # Initial commit\n> #\n> # Changes to be committed:\n> # (use \"git rm --cached ...\" to unstage)\n> #\n> # new file: .gitmodules\n> # new file: sub\n> #\n> \n> This means that module_list isn't aware of the empty submodule, when\n> the user has just explicitly added it. Fixing this would seem to need\n> either 'Subproject commit 00000...' as I suggested earlier, or an\n> adjustment to module_list that also spits out submodules that are in\n> .gitmodules but not in the index.\n\nOther than that, I think all the changes in the test suite are\nlogically sound and unlikely to cause problems with existing usage.\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":"204452","messageId":"7v8v9ft761.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"ec5d0235322619aff6c1c64b0a346efb0e4d0a32.1354417618.git.wking@tremily.us","subject":"Re: [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-03T16:46:46Z","receivedAt":"2012-12-03T16:46:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n> From: \"W. Trevor King\" \n>\n> The current `update` command incorporates the superproject's gitlinked\n> SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the\n> options you use, it may checkout $sha1, rebase the $subsha1 onto\n> $sha1, or merge $sha1 into $subsha1. This helps you keep up with\n> changes in the upstream superproject.\n>\n> However, it's also useful to stay up to date with changes in the\n> upstream subproject. Previous workflows for incorporating such\n> changes include the ungainly:\n>\n> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n>\n> With this patch, all of the useful functionality for incorporating\n> superproject changes can be reused to incorporate upstream subproject\n> updates. When you specify --remote, the target $sha1 is replaced with\n> a $sha1 of the submodule's origin/master tracking branch. If you want\n> to merge a different tracking branch, you can configure the\n> `submodule..branch` option in `.gitmodules`. You can override\n> the `.gitmodules` configuration setting for a particular superproject\n> by configuring the option in that superproject's default configuration\n> (using the usual configuration hierarchy, e.g. `.git/config`,\n> `~/.gitconfig`, etc.).\n>\n> Previous use of submodule..branch\n> =======================================\n>\n> Because we're adding a new configuration option, it's a good idea to\n> check if anyone else is already using the option. The foreach-pull\n> example above was described by Ævar 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>\n> Gerrit uses the same interpretation for the setting, but because\n> Gerrit has direct access to the subproject repositories, it updates\n> the superproject repositories automatically when a subproject changes.\n> Gerrit also accepts the special value '.', which it expands into the\n> superproject's branch name.\n>\n> Although the --remote functionality is using `submodule..branch`\n> slightly differently, the effect is the same. The foreach-pull\n> example uses the option to record the name of the local branch to\n> checkout before pulls. The tracking branch to be pulled is recorded\n> in `.git/modules//config`, which was initialized by the module\n> clone during `submodule add` or `submodule init`. Because the branch\n> name stored in `submodule..branch` was likely the same as the\n> branch name used during the initial `submodule add`, the same branch\n> will be pulled in each workflow.\n>\n> Implementation details\n> ======================\n>\n> In order to ensure a current tracking branch state, `update --remote`\n> fetches the submodule's remote repository before calculating the\n> SHA-1. However, I didn't change the logic guarding the existing fetch:\n>\n> if test -z \"$nofetch\"\n> then\n> # Run fetch only if $sha1 isn't present or it\n> # is not reachable from a ref.\n> (clear_local_git_env; cd \"$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 '\\$path'\")\"\n> fi\n>\n> There will not be a double-fetch, because the new $sha1 determined\n> after the `--remote` triggered fetch should always exist in the\n> repository. If it doesn't, it's because some racy process removed it\n> from the submodule's repository and we *should* be re-fetching.\n\nAs you hinted in the first paragraph, you could flip between merge,\nrebase, and detach with a command line option when running the\n\"update\" subcommand, but I would imagine that the expected use\npattern is that for a particular project, you would choose one mode\nand consistently stick to that mode. To make it easier, the user\ncan set submodule.$name.update once and run \"update\" without having\nto give any flags.\n\nAnd this is about adding another mode to the \"update\" subcommand\nwhere the HEAD is not detached, nor merged, nor rebased, but is set\nto follow whatever commit a remote branch points at.\n\nShouldn't the patch add a way for the user to set a configuration\nvariable to signal that this new mode is always used when \"update\"\nis run without a command line flag?\n\nAs the user has to configure submodule.$name.branch in order to use\nthis mode anyway, I have a feeling that taking that as a signal, and\nignoring submodule.$name.update altogether, might be a simpler\ninterface from the end user's point of view. That is,\n\n (1) if you are not interested in the submodule $name, you do not\n \"init\" it; you \"init\" it for all of the following.\n\n (2) if you want to have the tree state as recorded in the\n superproject, you do \"update\" without any option to make the\n HEAD of the submodule detached at the commit the superproject's\n tree records;\n\n (3) if you want to follow the upstream project of the submodule,\n you set submodule.$name.branch to the branch you want to\n follow, and you do \"update\"---submodule.$name.update is ignored\n and you will make the HEAD of the submodule detached at the tip\n of the branch at the remote (using remote-tracking branch);\n\n (4) if you want to --merge or --rebase, you give them from the\n command line, or use submodule.$name.update.\n\nI may be oversimplifying a bit, but a separate\nsubmodule.$name.remote feels very wrong; if it were a new token\n\"remote\" that can be set as the value of submodule.$name.update (in\naddition to existing \"none\", \"rebase\" and \"merge\"), it might be a\nbit more understandable, though.\n\nHow does this compare with the floating submodules Heiko has been\nworking on?\n"},{"id":"204457","messageId":"20121203181519.GC14981@odin.tremily.us","threadId":"32245","inReplyTo":"7v8v9ft761.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-03T18:15:19Z","receivedAt":"2012-12-03T18:15:19Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Mon, Dec 03, 2012 at 08:46:46AM -0800, Junio C Hamano wrote:\n> As you hinted in the first paragraph, you could flip between merge,\n> rebase, and detach with a command line option when running the\n> \"update\" subcommand, but I would imagine that the expected use\n> pattern is that for a particular project, you would choose one mode\n> and consistently stick to that mode. To make it easier, the user\n> can set submodule.$name.update once and run \"update\" without having\n> to give any flags.\n\nSure.\n\n> And this is about adding another mode to the \"update\" subcommand\n> where the HEAD is not detached, nor merged, nor rebased, but is set\n> to follow whatever commit a remote branch points at.\n\nThis is about adding another suite of modes. Currently you can\nrebase/merge/checkout the superproject-recorded $sha1. I'm adding the\nability to rebase/merge/checkout a submodule-upstream branch. I\ndiscuss this explicitly in Documentation/git-submodule.txt when\ndescribing --remote.\n\n> Shouldn't the patch add a way for the user to set a configuration\n> variable to signal that this new mode is always used when \"update\"\n> is run without a command line flag?\n\nHow about a new submodule..update-source with (which can be\neither superproject-gitlink or submodule-upstream)? Or to be a bit\nsimpler and less explicit, a submodule..update-remote boolean?\nFor lack of a better name, I'll call this submodule..\nbelow.\n\n> As the user has to configure submodule.$name.branch in order to use\n> this mode anyway, I have a feeling that taking that as a signal, and\n> ignoring submodule.$name.update altogether, might be a simpler\n> interface from the end user's point of view. That is,\n\nAs I mention earlier, submodule..update is still important. I\nthink it's good to add a new submodule.. config and a\n--no-remote option (to override a configured\nsubmodule..). This way a user that generally updates\nvia the superproject's gitlink can still configure a branch to update\nfrom when they use --remote.\n\n> (1) if you are not interested in the submodule $name, you do not\n> \"init\" it; you \"init\" it for all of the following.\n> \n> (2) if you want to have the tree state as recorded in the\n> superproject, you do \"update\" without any option to make the\n> HEAD of the submodule detached at the commit the superproject's\n> tree records;\n> \n> (3) if you want to follow the upstream project of the submodule,\n> you set submodule.$name.branch to the branch you want to\n> follow, and you do \"update\"---submodule.$name.update is ignored\n> and you will make the HEAD of the submodule detached at the tip\n> of the branch at the remote (using remote-tracking branch);\n> \n> (4) if you want to --merge or --rebase, you give them from the\n> command line, or use submodule.$name.update.\n\nBut what if your whant to merge the upstream project into a currently\nchecked out submodule branch? Or rebase a currently detached head\nagainst the upstream branch?\n\n> I may be oversimplifying a bit, but a separate\n> submodule.$name.remote feels very wrong;\n\nI use submodule..remote in patch 4 to specify the name of the\nsuperproject's remote (for when get_default_remote doesn't give the\nvalue you want), but I think you're referring to the potential\nsubmodule.. and the presense of the --remote option.\n\n> How does this compare with the floating submodules Heiko has been\n> working on?\n\nHeiko's older hv/floating_submodules also uses submodule..branch\n(with a similar interpretation). There's also a --branch option to\n`update` for command-line overrides (which I don't have, perhaps I\nshould add them?). He reverts to the original behavior in the\npresense of submodule..branch with `update --checkout`, or when\nsubmodule..branch=HEAD.\n\nHe also fetches all remotes, while I fetch just the explicitly\nconfigured submodule..remote falling back on\n$(get_default_remote. His submodule..branch is the full local\nref for the branch (e.g. 'origin/master'), while mine is just the\nremote branch (e.g. 'master'). I split the remote (e.g. 'origin')\ninto submodule..remote in patch 4 so you can explicitly fetch\njust that remote (and not all the remotes you may have configured for\nthat submodule).\n\nFor reasons that I don't understand, he only supports the `checkout`\nupdate logic for remote branches.\n\nHeiko's newer hv/floating_submodules_draft builds on my earlier v4\n--local-branch option, but he uses his own processing logic. He pulls\nthe existing 'update to $sha1' logic out into a new\nhandle_on_demand_update() and uses the stored submodule..branch\nas the name of a local submodule branch to check out when tracking.\nThen he pulls that local branches default upstream (configured in\n.git/modules//config) with --ff-only.\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":"204459","messageId":"20121203183802.GD14981@odin.tremily.us","threadId":"32245","inReplyTo":"20121203181519.GC14981@odin.tremily.us","subject":"Re: [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-03T18:38:02Z","receivedAt":"2012-12-03T18:38:02Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"As an example to make this clearer:\n\n $ cat .gitmodules\n [submodule \"sub1\"]\n path = sub1\n url = git://example.com/sub1.git\n remote = remote1\n branch = branch1\n update-source = submodule-upstream\n update = rebase\n [submodule \"sub2\"]\n ...\n\nMeans that `git submodule update sub1` will fetch remote1 and rebase\nthe current sub1 checkout against the tip of remote1/branch1. The\ngit://example.com/sub1.git URL is not actually used during this\nupdate. Presumably the user setup remote1 intentionally in the\nsubmodule, and wants to use the URL they've configured there.\n\nPerhaps I need to ammend my\n\n submodule update: add submodule..remote config option\n\npatch (#4) to adjust the remote that has it's URL changed by `sync`?\n\nI may also want to append some form of the following commit (from my\nsubmodule..active proposal):\n\n submodule add: configure existing submodule url if not set [1]\n\nCheers,\nTrevor\n\n[1]: https://github.com/wking/git/commit/b045c16cffe6eb86c157a6c7397166a46e147442\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":"204463","messageId":"7vehj7q6gr.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"436a73a8fdc8f0695aa597d53483d4c4bae16ebb.1354417618.git.wking@tremily.us","subject":"Re: [PATCH v6 1/4] submodule: add get_submodule_config helper funtion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-03T19:30:12Z","receivedAt":"2012-12-03T19:30:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n> From: \"W. Trevor King\" \n>\n> Several submodule configuration variables\n> (e.g. fetchRecurseSubmodules) are read from .gitmodules with local\n> overrides from the usual git config files. This shell function mimics\n> that logic to help initialize configuration variables in\n> git-submodule.sh.\n>\n> Signed-off-by: W. Trevor King \n> ---\n> git-submodule.sh | 27 +++++++++++++++++++++++++++\n> 1 file changed, 27 insertions(+)\n>\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index ab6b110..97ce5e4 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -152,6 +152,33 @@ die_if_unmatched ()\n> }\n> \n> #\n> +# Print a submodule configuration setting\n> +#\n> +# $1 = submodule name\n> +# $2 = option name\n> +# $3 = default value\n> +#\n> +# Checks in the usual git-config places first (for overrides),\n> +# otherwise it falls back on .gitmodules. This allows you to\n> +# distribute project-wide defaults in .gitmodules, while still\n> +# customizing individual repositories if necessary. If the option is\n> +# not in .gitmodules either, print a default value.\n> +#\n> +get_submodule_config()\n> +{\n\nstyle (see CodingGuidelines):\n\n\tget_submodule_config ()\t{\n\n> +\tname=\"$1\"\n> +\toption=\"$2\"\n> +\tdefault=\"$3\"\n> +\tvalue=$(git config submodule.\"$name\".\"$option\")\n\nThis will get unwieldy quickly once we have submodule.$name.$var\nthat takes a boolean option, as there are different ways to spell\nboolean and \"git config --bool\" is the way to ask for canonicalized\n\"true\" or \"false\".\n\nIf we never query any boolean via this helper function, it is\nobviously not an issue, though.\n\n> +\tif test -z \"$value\"\n> +\tthen\n> +\t\tvalue=$(git config -f .gitmodules submodule.\"$name\".\"$option\")\n> +\tfi\n> +\tprintf '%s' \"${value:-$default}\"\n> +}\n> +\n> +\n> +#\n> # Map submodule path to submodule name\n> #\n> # $1 = path\n"},{"id":"204466","messageId":"7vr4n6q3qm.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"20121203183802.GD14981@odin.tremily.us","subject":"Re: [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-03T20:29:05Z","receivedAt":"2012-12-03T20:29:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n> As an example to make this clearer:\n>\n> $ cat .gitmodules\n> [submodule \"sub1\"]\n> path = sub1\n> url = git://example.com/sub1.git\n> remote = remote1\n> branch = branch1\n> update-source = submodule-upstream\n> update = rebase\n> [submodule \"sub2\"]\n> ...\n\nMaybe it is just me but that \"remote = remote1\" sticks out like a\nsore thumb.\n\nIf you are showing the .gitmodules file to be shared as hints to\nproject participants, why does it even need to have both URL and\nremote1? If remote1 points at some other repository, the recipient\nof this .gitmodules file would not have any clue where it is. If\nremote1 points at the same repository as the URL, why should it be\nthere in the first place? The superproject is in no business to\nforce what local remote name each participant would call in their\nsubmodule checkout, and more importantly, there is no _need_ to do\nso.\n\nWe could extend that reasoning to the branch name (which is also a\nlocal matter, at least technically), but this is a lot more\njustifiable. If the upstream of the superproject is the same\norganization as the upstream of the submodule project, which is\noften the case when a large project is organized as a forest of\nsubmodules bound at the top-level with a superproject, the\nsuperproject commit on a particular superproject branch may want any\nupdate necessary to complete the superproject made to submodules on\nspecific branches at the central meeting place. The superproject's\nMilestone22 branch may want to bind commits that is on submodule's\nMilestone22 branch.\n\nWhile a participant locally *can* create M22 branch in the submodule\nand set it to build upon Milestone22 branch taken from the central\nrepository, most people don't. They use the same branch names\nbetween local and remote (i.e. refs/heads/*:refs/remotes/origin/* to\nkeep the remote-tracking branches under the same name, and the local\nbranch $any builds upon the corresponding remote-tracking branch\nrefs/remotes/origin/$any. Most importantly, the work done on local\nbranch $any is pushed out to refs/heads/$any at the remote of the\nsubmodule). Because of how people use \"push\" to push $any branch to\nthe branch of the same name $any at the central meeting place, and\nbecause the upstream wants participants to use a particular branch\nname in the submodule at the central meeting place, the set-up ends\nup dictating what local branch name should be used.\n\nBut I do not see any reason to require or even suggest any local\nnickname that is to be used to call the remote. It really is a\nlocal matter. Why should .gitmodules have \"remote = ...\" line?\n\nOn the other hand, if you meant the above as an excerpt from\n$GIT_DIR/config, it also does not make sense. At that point, the\nparticipant own the file and updating url to point at whatever\ndifferent repository without changing the remote name is sufficient.\n\nIt looks way over-engineered for unclear/dubious benefit.\n"},{"id":"204472","messageId":"20121204001717.GA17375@odin.tremily.us","threadId":"32245","inReplyTo":"7vr4n6q3qm.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v6 1/4] submodule: add get_submodule_config helper funtion","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-04T00:17:17Z","receivedAt":"2012-12-04T00:17:17Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Mon, Dec 03, 2012 at 11:30:12AM -0800, Junio C Hamano wrote:\n> > +get_submodule_config()\n> > +{\n> \n> style (see CodingGuidelines):\n> \n> \tget_submodule_config ()\t{\n\nWill fix. I was generally just copying the surrounding code.\n\n> > +\tname=\"$1\"\n> > +\toption=\"$2\"\n> > +\tdefault=\"$3\"\n> > +\tvalue=$(git config submodule.\"$name\".\"$option\")\n> \n> This will get unwieldy quickly once we have submodule.$name.$var\n> that takes a boolean option, as there are different ways to spell\n> boolean and \"git config --bool\" is the way to ask for canonicalized\n> \"true\" or \"false\".\n> \n> If we never query any boolean via this helper function, it is\n> obviously not an issue, though.\n\nWe do in my submodule..active branch, and I adjusted the\nfunction in\n\n submodule: add submodule..active [1]\n\nto add additional options passed through to `git config`. You do have\nto pick a default to use the extra options though. If that becomes a\nproblem, I'd suggest extending git config itself to add a file above\nor below the usual series of files. Then get_submodule_config could\nbe\n\n git config --bottom-file .gitmodules submodule.\"$name\".\"$option\"\n\nor something, without needing a separate shell function.\n\nOn Mon, Dec 03, 2012 at 12:29:05PM -0800, Junio C Hamano wrote:\n> \"W. Trevor King\" writes:\n> \n> > As an example to make this clearer:\n> >\n> > $ cat .gitmodules\n> > [submodule \"sub1\"]\n> > path = sub1\n> > url = git://example.com/sub1.git\n> > remote = remote1\n> > branch = branch1\n> > update-source = submodule-upstream\n> > update = rebase\n> > [submodule \"sub2\"]\n> > ...\n> \n> Maybe it is just me but that \"remote = remote1\" sticks out like a\n> sore thumb.\n> \n> If you are showing the .gitmodules file to be shared as hints to\n> project participants, why does it even need to have both URL and\n> remote1?\n\nThe remote name will probably only ever get configured locally in\n.git/config. I put it in (as a separate patch) mostly because Phil\nsuggested something like it:\n\nOn Thu, Nov 29, 2012 at 10:27:19PM -0500, W. Trevor King wrote:\n> On Thu, Nov 29, 2012 at 08:11:20PM -0500, Phil Hord wrote:\n> > I've always felt that the \"origin\" defaults are broken and are simply\n> > being ignored because most users do not trip over them. But ISTR that\n> > submodule commands use the remote indicated by the superproject's\n> > current remote-tracking configuration, with a fallback to 'origin' if\n> > there is none. Sort of a \"best effort\" algorithm, I think. Am I\n> > remembering that wrong?\n>\n> The current code uses a bare \"git-fetch\". I'm not sure what that\n> defaults to if you're on a detached head. If it bothers you, I'm fine\n> adding the submodule..remote option in v6.\n\nand I hadn't heard any comments against it. I'm not really attached\nto that patch though, so feel free to leave it out (unless Phil chimes\nin with stronger motivation?).\n\nOn Mon, Dec 03, 2012 at 12:29:05PM -0800, Junio C Hamano wrote:\n> But I do not see any reason to require or even suggest any local\n> nickname that is to be used to call the remote. It really is a\n> local matter. Why should .gitmodules have \"remote = ...\" line?\n\nThe idea for configuring it at all probably goes something like “I\ndon't like where upstream (origin) is taking this submodule. I want\nto follow *my* upstream, but I've called it something besides origin.\nLook, a submodule..remote option! Now I don't have to rename\nmy-remote→origin→original-remote.” I don't think this will come up\nall that often.\n\n> On the other hand, if you meant the above as an excerpt from\n> $GIT_DIR/config, it also does not make sense. At that point, the\n> participant own the file and updating url to point at whatever\n> different repository without changing the remote name is sufficient.\n\nUnless they still want to keep an the origin remote to track the\noriginal submodule upstream. Maybe they'll want to switch back to\nfollowing that remote later. As I hinted at above, if they have\nremotes `alice`, `bob`, etc., it's easier to flip between them by\nconfiguring submodule..remote\n\n $ git config submodule.submod.remote alice\n\nthan it is to reconfigure the submodule's origin:\n\n $ cd submod\n $ git remote rename origin charlie\n $ git remote rename alice origin\n\n> It looks way over-engineered for unclear/dubious benefit.\n\nI'm not going to push for submodule..remote. Drop at will.\n\nCheers,\nTrevor\n\n[1]: https://github.com/wking/git/commit/fbe2d8419902700a6b0b40defaa5801811b887f7#L0R288\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":"204503","messageId":"50BE6FB9.70301@web.de","threadId":"32245","inReplyTo":"7vhao31s9e.fsf@alter.siamese.dyndns.org","subject":"[PATCH v2] submodule: add 'deinit' command","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-12-04T21:48:41Z","receivedAt":"2012-12-04T21:48:41Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"With \"git submodule init\" the user is able to tell git he cares about one\nor more submodules and wants to have it populated on the next call to \"git\nsubmodule update\". But currently there is no easy way he could tell git he\ndoes not care about a submodule anymore and wants to get rid of his local\nwork tree (except he knows a lot about submodule internals and removes the\n\"submodule.$name.url\" setting from .git/config himself).\n\nHelp those users by providing a 'deinit' command. This removes the whole\nsubmodule. section from .git/config either for the given\nsubmodule(s) or for all those which have been initialized if none were\ngiven. Complain only when for a submodule given on the command line the\nurl setting can't be found in .git/config.\n\nAdd tests and link the man pages of \"git submodule deinit\" and \"git rm\"\nto assist the user in deciding whether removing or unregistering the\nsubmodule is the right thing to do for him.\n\nSigned-off-by: Jens Lehmann \n---\n\nAm 03.12.2012 08:58, schrieb Junio C Hamano:\n> Jens Lehmann writes:\n> \n>> Maybe the principle of least surprise is better followed when we\n>> nuke the whole section, as it might surprise the user more to have\n>> a setting resurrected he customized in the last life cycle of the\n>> submodule than seeing that after an deinit followed by an init all\n>> former customizations are consistently gone. So I tend to think now\n>> that removing the whole section would be the better solution here.\n> \n> I tend to agree; I suspect that a \"deinit\" would be mostly done\n> either to\n> \n> (1) correct mistakes the user made during a recent \"init\" and\n> perhaps \"sync\"; or\n> \n> (2) tell Git that the user has finished woing with this particular\n> submodule and does not intend to use it for quite a while.\n> \n> For both (1) and (2), I think it would be easier to users if we gave\n> them a clean slate, the same state as the one the user who never had\n> ran \"init\" on it would be in. A user in situation (1) is asking for\n> a clean slate, and a user in situation (2) is better served if he\n> does not have to worry about leftover entries in $GIT_DIR/config he\n> has long forgotten from many months ago (during which time the way\n> the project uses the particular submodule may well have changed)\n> giving non-standard experience different from what other project\n> participants would get.\n\nChanges in v2:\n- Remove the whole submodule section instead of only removing the\n \"url\" setting and explain why we do that in a comment\n- Reworded commit message and git-submodule.txt to reflect that\n- Extend the test to check that a custom settings are removed\n\n\n Documentation/git-rm.txt | 4 ++++\n Documentation/git-submodule.txt | 12 ++++++++++\n git-submodule.sh | 52 ++++++++++++++++++++++++++++++++++++++++-\n t/t7400-submodule-basic.sh | 12 ++++++++++\n 4 files changed, 79 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt\nindex 262436b..ec42bf5 100644\n--- a/Documentation/git-rm.txt\n+++ b/Documentation/git-rm.txt\n@@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree.\n Ignored files are deemed expendable and won't stop a submodule's work\n tree from being removed.\n\n+If you only want to remove the local checkout of a submodule from your\n+work tree without committing that use `git submodule deinit` instead\n+(see linkgit:git-submodule[1]).\n+\n EXAMPLES\n --------\n `git rm Documentation/\\*.txt`::\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex b1de3ba..08b55a7 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -13,6 +13,7 @@ SYNOPSIS\n \t [--reference ] [--] []\n 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]\n 'git submodule' [--quiet] init [--] [...]\n+'git submodule' [--quiet] deinit [--] [...]\n 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]\n \t [--reference ] [--merge] [--recursive] [--] [...]\n 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]\n@@ -134,6 +135,17 @@ init::\n \tthe explicit 'init' step if you do not intend to customize\n \tany submodule locations.\n\n+deinit::\n+\tUnregister the submodules, i.e. remove the whole `submodule.$name`\n+\tsection from .git/config. Further calls to `git submodule update`,\n+\t`git submodule foreach` and `git submodule sync` will skip any\n+\tunregistered submodules until they are initialized again, so use\n+\tthis command if you don't want to have a local checkout of the\n+\tsubmodule in your work tree anymore (but note that this command\n+\tdoes not remove the submodule work tree). If you really want to\n+\tremove a submodule from the repository and commit that use\n+\tlinkgit:git-rm[1] instead.\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.\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 2365149..3f558ed 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -8,6 +8,7 @@ dashless=$(basename \"$0\" | sed -e 's/-/ /')\n USAGE=\"[--quiet] add [-b ] [-f|--force] [--name ] [--reference ] [--] []\n or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]\n or: $dashless [--quiet] init [--] [...]\n+ or: $dashless [--quiet] deinit [--] [...]\n or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ] [commit] [--] [...]\n or: $dashless [--quiet] foreach [--recursive] \n@@ -516,6 +517,55 @@ cmd_init()\n }\n\n #\n+# Unregister submodules from .git/config\n+#\n+# $@ = requested paths (default to all)\n+#\n+cmd_deinit()\n+{\n+\t# parse $args after \"submodule ... init\".\n+\twhile test $# -ne 0\n+\tdo\n+\t\tcase \"$1\" in\n+\t\t-q|--quiet)\n+\t\t\tGIT_QUIET=1\n+\t\t\t;;\n+\t\t--)\n+\t\t\tshift\n+\t\t\tbreak\n+\t\t\t;;\n+\t\t-*)\n+\t\t\tusage\n+\t\t\t;;\n+\t\t*)\n+\t\t\tbreak\n+\t\t\t;;\n+\t\tesac\n+\t\tshift\n+\tdone\n+\n+\tmodule_list \"$@\" |\n+\twhile read mode sha1 stage sm_path\n+\tdo\n+\t\tdie_if_unmatched \"$mode\"\n+\t\tname=$(module_name \"$sm_path\") || exit\n+\t\turl=$(git config submodule.\"$name\".url)\n+\t\tif test -z \"$url\"\n+\t\tthen\n+\t\t\t# Only mention uninitialized submodules when its\n+\t\t\t# path have been specified\n+\t\t\ttest \"$#\" != \"0\" &&\n+\t\t\tsay \"$(eval_gettext \"No url found for submodule path '\\$sm_path' in .git/config\")\"\n+\t\t\tcontinue\n+\t\tfi\n+\t\t# Remove the whole section so we have a clean state when the user\n+\t\t# later decides to init this submodule again\n+\t\tgit config --remove-section submodule.\"$name\" &&\n+\t\tsay \"$(eval_gettext \"Submodule '\\$name' (\\$url) unregistered\")\"\n+\tdone\n+}\n+\n+#\n # Update each submodule path to correct revision, using clone and checkout as needed\n #\n # $@ = requested paths (default to all)\n@@ -1108,7 +1158,7 @@ cmd_sync()\n while test $# != 0 && test -z \"$command\"\n do\n \tcase \"$1\" in\n-\tadd | foreach | init | update | status | summary | sync)\n+\tadd | foreach | init | deinit | update | status | summary | sync)\n \t\tcommand=$1\n \t\t;;\n \t-q|--quiet)\ndiff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\nindex de7d453..ee4f0ab 100755\n--- a/t/t7400-submodule-basic.sh\n+++ b/t/t7400-submodule-basic.sh\n@@ -756,4 +756,16 @@ test_expect_success 'submodule add with an existing name fails unless forced' '\n \t)\n '\n\n+test_expect_success 'submodule deinit should remove the whole submodule section from .git/config' '\n+\tgit config submodule.example.foo bar &&\n+\tgit submodule deinit &&\n+\ttest -z \"$(git config submodule.example.url)\" &&\n+\ttest -z \"$(git config submodule.example.foo)\"\n+'\n+\n+test_expect_success 'submodule deinit complains only when explicitly used on an uninitialized submodule' '\n+\tgit submodule deinit &&\n+\ttest_must_fail git submodule deinit example\n+'\n+\n test_done\n-- \n1.8.0.1.348.gc64da69\n"},{"id":"204504","messageId":"7v1uf5mn74.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"50BE6FB9.70301@web.de","subject":"Re: [PATCH v2] submodule: add 'deinit' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-04T23:06:55Z","receivedAt":"2012-12-04T23:06:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> +If you only want to remove the local checkout of a submodule from your\n> +work tree without committing that use `git submodule deinit` instead\n> +(see linkgit:git-submodule[1]).\n\nI'll add a comma between \"without commiting that\" and \"use X\ninstead\"; it will read better, I think.\n\n> +test_expect_success 'submodule deinit should remove the whole submodule section from .git/config' '\n> +\tgit config submodule.example.foo bar &&\n> +\tgit submodule deinit &&\n> +\ttest -z \"$(git config submodule.example.url)\" &&\n> +\ttest -z \"$(git config submodule.example.foo)\"\n> +'\n\nThis is sufficient, but it might be cleaner to see if\n\n git config --get-regexp \"^submodule\\.example\\.\"\n\nresults in empty. Does not make much difference to warrant a re-roll.\n\n> +test_expect_success 'submodule deinit complains only when explicitly used on an uninitialized submodule' '\n> +\tgit submodule deinit &&\n> +\ttest_must_fail git submodule deinit example\n> +'\n> +\n> test_done\n\nThanks; will queue.\n"},{"id":"204682","messageId":"cover.1355251862.git.wking@tremily.us","threadId":"32245","inReplyTo":"20121204001717.GA17375@odin.tremily.us","subject":"[PATCH v7 0/3] submodule update: add --remote for submodule's upstream changes","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-11T18:58:14Z","receivedAt":"2012-12-11T18:58:14Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nI see that this series has dropped out of \"what's cooking?\".\nHopefully this reroll gets it back in ;).\n\nChanges since v6 (both in response to Junio's comments):\n\n* Fix style in get_submodule_config definition.\n* Drop the submodule..remote config option (v6's patch 4).\n\nW. Trevor King (3):\n submodule: add get_submodule_config helper funtion\n submodule update: add --remote for submodule's upstream changes\n submodule add: If --branch is given, record it in .gitmodules\n\n Documentation/config.txt | 7 +++++-\n Documentation/git-submodule.txt | 27 ++++++++++++++++++++-\n Documentation/gitmodules.txt | 5 ++++\n git-submodule.sh | 52 ++++++++++++++++++++++++++++++++++++++++-\n t/t7400-submodule-basic.sh | 1 +\n t/t7406-submodule-update.sh | 31 ++++++++++++++++++++++++\n 6 files changed, 120 insertions(+), 3 deletions(-)\n\n-- \n1.8.0\n"},{"id":"204684","messageId":"81a253f4d88cd2f3febedc9f24754c4390723a46.1355251862.git.wking@tremily.us","threadId":"32245","inReplyTo":"cover.1355251862.git.wking@tremily.us","subject":"[PATCH v7 1/3] submodule: add get_submodule_config helper funtion","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-11T18:58:15Z","receivedAt":"2012-12-11T18:58:15Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nSeveral submodule configuration variables\n(e.g. fetchRecurseSubmodules) are read from .gitmodules with local\noverrides from the usual git config files. This shell function mimics\nthat logic to help initialize configuration variables in\ngit-submodule.sh.\n\nSigned-off-by: W. Trevor King \n---\n git-submodule.sh | 26 ++++++++++++++++++++++++++\n 1 file changed, 26 insertions(+)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex ab6b110..f969f28 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -152,6 +152,32 @@ die_if_unmatched ()\n }\n \n #\n+# Print a submodule configuration setting\n+#\n+# $1 = submodule name\n+# $2 = option name\n+# $3 = default value\n+#\n+# Checks in the usual git-config places first (for overrides),\n+# otherwise it falls back on .gitmodules. This allows you to\n+# distribute project-wide defaults in .gitmodules, while still\n+# customizing individual repositories if necessary. If the option is\n+# not in .gitmodules either, print a default value.\n+#\n+get_submodule_config () {\n+\tname=\"$1\"\n+\toption=\"$2\"\n+\tdefault=\"$3\"\n+\tvalue=$(git config submodule.\"$name\".\"$option\")\n+\tif test -z \"$value\"\n+\tthen\n+\t\tvalue=$(git config -f .gitmodules submodule.\"$name\".\"$option\")\n+\tfi\n+\tprintf '%s' \"${value:-$default}\"\n+}\n+\n+\n+#\n # Map submodule path to submodule name\n #\n # $1 = path\n-- \n1.8.0\n"},{"id":"204685","messageId":"64d109da03c521303ad87b8370bf09ab28a5c09f.1355251862.git.wking@tremily.us","threadId":"32245","inReplyTo":"cover.1355251862.git.wking@tremily.us","subject":"[PATCH v7 2/3] submodule update: add --remote for submodule's upstream changes","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-11T18:58:16Z","receivedAt":"2012-12-11T18:58:16Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nThe current `update` command incorporates the superproject's gitlinked\nSHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the\noptions you use, it may checkout $sha1, rebase the $subsha1 onto\n$sha1, or merge $sha1 into $subsha1. This helps you keep up with\nchanges in the upstream superproject.\n\nHowever, it's also useful to stay up to date with changes in the\nupstream subproject. Previous workflows for incorporating such\nchanges include the ungainly:\n\n $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n\nWith this patch, all of the useful functionality for incorporating\nsuperproject changes can be reused to incorporate upstream subproject\nupdates. When you specify --remote, the target $sha1 is replaced with\na $sha1 of the submodule's origin/master tracking branch. If you want\nto merge a different tracking branch, you can configure the\n`submodule..branch` option in `.gitmodules`. You can override\nthe `.gitmodules` configuration setting for a particular superproject\nby configuring the option in that superproject's default configuration\n(using the usual configuration hierarchy, e.g. `.git/config`,\n`~/.gitconfig`, etc.).\n\nPrevious use of submodule..branch\n=======================================\n\nBecause we're adding a new configuration option, it's a good idea to\ncheck if anyone else is already using the option. The foreach-pull\nexample above was described by Ævar 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\nAlthough the --remote functionality is using `submodule..branch`\nslightly differently, the effect is the same. The foreach-pull\nexample uses the option to record the name of the local branch to\ncheckout before pulls. The tracking branch to be pulled is recorded\nin `.git/modules//config`, which was initialized by the module\nclone during `submodule add` or `submodule init`. Because the branch\nname stored in `submodule..branch` was likely the same as the\nbranch name used during the initial `submodule add`, the same branch\nwill be pulled in each workflow.\n\nImplementation details\n======================\n\nIn order to ensure a current tracking branch state, `update --remote`\nfetches the submodule's remote repository before calculating the\nSHA-1. However, I didn't change the logic guarding the existing fetch:\n\n if test -z \"$nofetch\"\n then\n # Run fetch only if $sha1 isn't present or it\n # is not reachable from a ref.\n (clear_local_git_env; cd \"$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 '\\$path'\")\"\n fi\n\nThere will not be a double-fetch, because the new $sha1 determined\nafter the `--remote` triggered fetch should always exist in the\nrepository. If it doesn't, it's because some racy process removed it\nfrom the submodule's repository and we *should* be re-fetching.\n\nSigned-off-by: W. Trevor King \n---\n Documentation/config.txt | 7 ++++++-\n Documentation/git-submodule.txt | 25 ++++++++++++++++++++++++-\n Documentation/gitmodules.txt | 5 +++++\n git-submodule.sh | 22 +++++++++++++++++++++-\n t/t7406-submodule-update.sh | 31 +++++++++++++++++++++++++++++++\n 5 files changed, 87 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 11f320b..6f4663c 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1998,7 +1998,12 @@ submodule..update::\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-\tlinkgit:git-submodule[1] and linkgit:gitmodules[5] for details.\n+\n+submodule..branch::\n+\tThe remote branch name for a submodule, used by `git submodule\n+\tupdate --remote`. Set this option to override the value found in\n+\tthe `.gitmodules` file. See linkgit:git-submodule[1] and\n+\tlinkgit:gitmodules[5] for details.\n \n submodule..fetchRecurseSubmodules::\n \tThis option can be used to control recursive fetching of this\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex b4683bb..72dd52f 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -13,7 +13,7 @@ SYNOPSIS\n \t [--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] [--remote] [-N|--no-fetch] [--rebase]\n \t [--reference ] [--merge] [--recursive] [--] [...]\n 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]\n \t [commit] [--] [...]\n@@ -236,6 +236,29 @@ OPTIONS\n \t(the default). This limit only applies to modified submodules. The\n \tsize is always limited to 1 for added/deleted/typechanged submodules.\n \n+--remote::\n+\tThis option is only valid for the update command. Instead of using\n+\tthe superproject's recorded SHA-1 to update the submodule, use the\n+\tstatus of the submodule's remote tracking branch. The remote used\n+\tis branch's remote (`branch..remote`), defaulting to `origin`.\n+\tThe remote branch used defaults to `master`, but the branch name may\n+\tbe overridden by setting the `submodule..branch` option in\n+\teither `.gitmodules` or `.git/config` (with `.git/config` taking\n+\tprecedence).\n++\n+This works for any of the supported update procedures (`--checkout`,\n+`--rebase`, etc.). The only change is the source of the target SHA-1.\n+For example, `submodule update --remote --merge` will merge upstream\n+submodule changes into the submodules, while `submodule update\n+--merge` will merge superproject gitlink changes into the submodules.\n++\n+In order to ensure a current tracking branch state, `update --remote`\n+fetches the submodule's remote repository before calculating the\n+SHA-1. This makes `submodule update --remote --merge` similar to\n+running `git pull` in the submodule. If you don't want to fetch (for\n+something closer to `git merge`), you should use `submodule update\n+--remote --no-fetch --merge`.\n+\n -N::\n --no-fetch::\n \tThis option is only valid for the update command.\ndiff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt\nindex 4effd78..4004fa6 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 remote branch name for tracking updates in the upstream submodule.\n+\tIf the option is not specified, it defaults to 'master'. See the\n+\t`--remote` documentation in linkgit:git-submodule[1] for details.\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 f969f28..1395079 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -8,7 +8,8 @@ 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] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n+ges\n or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ] [commit] [--] [...]\n or: $dashless [--quiet] foreach [--recursive] \n or: $dashless [--quiet] sync [--] [...]\"\n@@ -26,6 +27,7 @@ cached=\n recursive=\n init=\n files=\n+remote=\n nofetch=\n update=\n prefix=\n@@ -535,6 +537,9 @@ cmd_update()\n \t\t-i|--init)\n \t\t\tinit=1\n \t\t\t;;\n+\t\t--remote)\n+\t\t\tremote=1\n+\t\t\t;;\n \t\t-N|--no-fetch)\n \t\t\tnofetch=1\n \t\t\t;;\n@@ -595,6 +600,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=$(get_submodule_config \"$name\" branch master)\n \t\tif ! test -z \"$update\"\n \t\tthen\n \t\t\tupdate_module=$update\n@@ -629,6 +635,20 @@ 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 -n \"$remote\"\n+\t\tthen\n+\t\t\tif test -z \"$nofetch\"\n+\t\t\tthen\n+\t\t\t\t# Fetch remote before determining tracking $sha1\n+\t\t\t\t(clear_local_git_env; cd \"$sm_path\" && git-fetch) ||\n+\t\t\t\tdie \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n+\t\t\tfi\n+\t\t\tremote_name=$(get_default_remote)\n+\t\t\tsha1=$(clear_local_git_env; cd \"$sm_path\" &&\n+\t\t\t\tgit rev-parse --verify \"${remote_name}/${branch}\") ||\n+\t\t\tdie \"$(eval_gettext \"Unable to find current ${remote_name}/${branch} revision in submodule path '\\$sm_path'\")\"\n+\t\tfi\n+\n \t\tif test \"$subsha1\" != \"$sha1\" -o -n \"$force\"\n \t\tthen\n \t\t\tsubforce=$force\ndiff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\nindex 1542653..a567834 100755\n--- a/t/t7406-submodule-update.sh\n+++ b/t/t7406-submodule-update.sh\n@@ -135,6 +135,37 @@ test_expect_success 'submodule update --force forcibly checks out submodules' '\n \t)\n '\n \n+test_expect_success 'submodule update --remote should fetch upstream changes' '\n+\t(cd submodule &&\n+\t echo line4 >> file &&\n+\t git add file &&\n+\t test_tick &&\n+\t git commit -m \"upstream line4\"\n+\t) &&\n+\t(cd super &&\n+\t git submodule update --remote --force submodule &&\n+\t cd submodule &&\n+\t test \"$(git log -1 --oneline)\" = \"$(GIT_DIR=../../submodule/.git git log -1 --oneline)\"\n+\t)\n+'\n+\n+test_expect_success 'local config should override .gitmodules branch' '\n+\t(cd submodule &&\n+\t git checkout -b test-branch &&\n+\t echo line5 >> file &&\n+\t git add file &&\n+\t test_tick &&\n+\t git commit -m \"upstream line5\" &&\n+\t git checkout master\n+\t) &&\n+\t(cd super &&\n+\t git config submodule.submodule.branch test-branch &&\n+\t git submodule update --remote --force submodule &&\n+\t cd submodule &&\n+\t test \"$(git log -1 --oneline)\" = \"$(GIT_DIR=../../submodule/.git git log -1 --oneline test-branch)\"\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\n"},{"id":"204683","messageId":"0b2b49bb7337459502d46b814e350ec857cedfaa.1355251862.git.wking@tremily.us","threadId":"32245","inReplyTo":"cover.1355251862.git.wking@tremily.us","subject":"[PATCH v7 3/3] submodule add: If --branch is given, record it in .gitmodules","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-11T18:58:17Z","receivedAt":"2012-12-11T18:58: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 you to easily record a submodule..branch option in\n.gitmodules when you add a new submodule. With this patch,\n\n $ git submodule add -b []\n $ git config -f .gitmodules submodule..branch \n\nreduces to\n\n $ git submodule add -b []\n\nThis means that future calls to\n\n $ git submodule update --remote ...\n\nwill get updates from the same branch that you used to initialize the\nsubmodule, which is usually what you want.\n\nSigned-off-by: W. Trevor King \n---\n Documentation/git-submodule.txt | 2 ++\n git-submodule.sh | 4 ++++\n t/t7400-submodule-basic.sh | 1 +\n 3 files changed, 7 insertions(+)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 72dd52f..988bba9 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -208,6 +208,8 @@ OPTIONS\n -b::\n --branch::\n \tBranch of repository to add as submodule.\n+\tThe name of the branch is recorded as `submodule..branch` in\n+\t`.gitmodules` for `update --remote`.\n \n -f::\n --force::\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 1395079..9f3f437 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -394,6 +394,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 \"$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..90e2915 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 \"initial\" = \"$(git config -f .gitmodules submodule.submod-branch.branch)\" &&\n \t\tgit submodule init\n \t) &&\n \n-- \n1.8.0\n"},{"id":"204717","messageId":"7vtxrr6d2f.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"cover.1355251862.git.wking@tremily.us","subject":"Re: [PATCH v7 0/3] submodule update: add --remote for submodule's upstream changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-12T05:42:48Z","receivedAt":"2012-12-12T05:42:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"What branch did you base this series on?\n\nThe preimage of git-submodule.sh in [2/3] does not seem to match\nanything I have (I could wiggle the patch, but in general I would\nrather prefer not having to).\n"},{"id":"204746","messageId":"50C89DF3.20303@drmicha.warpmail.net","threadId":"32245","inReplyTo":"50BE6FB9.70301@web.de","subject":"Re: [PATCH v2] submodule: add 'deinit' command","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-12-12T15:08:35Z","receivedAt":"2012-12-12T15:08:35Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jens Lehmann venit, vidit, dixit 04.12.2012 22:48:\n> With \"git submodule init\" the user is able to tell git he cares about one\n> or more submodules and wants to have it populated on the next call to \"git\n> submodule update\". But currently there is no easy way he could tell git he\n> does not care about a submodule anymore and wants to get rid of his local\n> work tree (except he knows a lot about submodule internals and removes the\n> \"submodule.$name.url\" setting from .git/config himself).\n> \n> Help those users by providing a 'deinit' command. This removes the whole\n> submodule. section from .git/config either for the given\n> submodule(s) or for all those which have been initialized if none were\n> given. Complain only when for a submodule given on the command line the\n> url setting can't be found in .git/config.\n\nWhoaaa, so why not have \"git rm\" remove everything unless I specify a\nfile to be removed?\n\nI know I'm exaggerating a bit, but defaulting to \"--all\" for a\ndestructive operation seems to be a bit harsh, especially when the\ncommand is targeted at \"those\" users that you mention.\n\n> Add tests and link the man pages of \"git submodule deinit\" and \"git rm\"\n> to assist the user in deciding whether removing or unregistering the\n> submodule is the right thing to do for him.\n> \n> Signed-off-by: Jens Lehmann \n> ---\n> \n> Am 03.12.2012 08:58, schrieb Junio C Hamano:\n>> Jens Lehmann writes:\n>>\n>>> Maybe the principle of least surprise is better followed when we\n>>> nuke the whole section, as it might surprise the user more to have\n>>> a setting resurrected he customized in the last life cycle of the\n>>> submodule than seeing that after an deinit followed by an init all\n>>> former customizations are consistently gone. So I tend to think now\n>>> that removing the whole section would be the better solution here.\n>>\n>> I tend to agree; I suspect that a \"deinit\" would be mostly done\n>> either to\n>>\n>> (1) correct mistakes the user made during a recent \"init\" and\n>> perhaps \"sync\"; or\n>>\n>> (2) tell Git that the user has finished woing with this particular\n>> submodule and does not intend to use it for quite a while.\n>>\n>> For both (1) and (2), I think it would be easier to users if we gave\n>> them a clean slate, the same state as the one the user who never had\n>> ran \"init\" on it would be in. A user in situation (1) is asking for\n>> a clean slate, and a user in situation (2) is better served if he\n>> does not have to worry about leftover entries in $GIT_DIR/config he\n>> has long forgotten from many months ago (during which time the way\n>> the project uses the particular submodule may well have changed)\n>> giving non-standard experience different from what other project\n>> participants would get.\n> \n> Changes in v2:\n> - Remove the whole submodule section instead of only removing the\n> \"url\" setting and explain why we do that in a comment\n> - Reworded commit message and git-submodule.txt to reflect that\n> - Extend the test to check that a custom settings are removed\n> \n> \n> Documentation/git-rm.txt | 4 ++++\n> Documentation/git-submodule.txt | 12 ++++++++++\n> git-submodule.sh | 52 ++++++++++++++++++++++++++++++++++++++++-\n> t/t7400-submodule-basic.sh | 12 ++++++++++\n> 4 files changed, 79 insertions(+), 1 deletion(-)\n> \n> diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt\n> index 262436b..ec42bf5 100644\n> --- a/Documentation/git-rm.txt\n> +++ b/Documentation/git-rm.txt\n> @@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree.\n> Ignored files are deemed expendable and won't stop a submodule's work\n> tree from being removed.\n> \n> +If you only want to remove the local checkout of a submodule from your\n> +work tree without committing that use `git submodule deinit` instead\n> +(see linkgit:git-submodule[1]).\n> +\n> EXAMPLES\n> --------\n> `git rm Documentation/\\*.txt`::\n> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> index b1de3ba..08b55a7 100644\n> --- a/Documentation/git-submodule.txt\n> +++ b/Documentation/git-submodule.txt\n> @@ -13,6 +13,7 @@ SYNOPSIS\n> \t [--reference ] [--] []\n> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [...]\n> 'git submodule' [--quiet] init [--] [...]\n> +'git submodule' [--quiet] deinit [--] [...]\n> 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]\n> \t [--reference ] [--merge] [--recursive] [--] [...]\n> 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]\n> @@ -134,6 +135,17 @@ init::\n> \tthe explicit 'init' step if you do not intend to customize\n> \tany submodule locations.\n> \n> +deinit::\n> +\tUnregister the submodules, i.e. remove the whole `submodule.$name`\n> +\tsection from .git/config. Further calls to `git submodule update`,\n> +\t`git submodule foreach` and `git submodule sync` will skip any\n> +\tunregistered submodules until they are initialized again, so use\n> +\tthis command if you don't want to have a local checkout of the\n> +\tsubmodule in your work tree anymore (but note that this command\n> +\tdoes not remove the submodule work tree). If you really want to\n> +\tremove a submodule from the repository and commit that use\n> +\tlinkgit:git-rm[1] instead.\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> diff --git a/git-submodule.sh b/git-submodule.sh\n> index 2365149..3f558ed 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -8,6 +8,7 @@ dashless=$(basename \"$0\" | sed -e 's/-/ /')\n> USAGE=\"[--quiet] add [-b ] [-f|--force] [--name ] [--reference ] [--] []\n> or: $dashless [--quiet] status [--cached] [--recursive] [--] [...]\n> or: $dashless [--quiet] init [--] [...]\n> + or: $dashless [--quiet] deinit [--] [...]\n> or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n> or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ] [commit] [--] [...]\n> or: $dashless [--quiet] foreach [--recursive] \n> @@ -516,6 +517,55 @@ cmd_init()\n> }\n> \n> #\n> +# Unregister submodules from .git/config\n> +#\n> +# $@ = requested paths (default to all)\n> +#\n> +cmd_deinit()\n> +{\n> +\t# parse $args after \"submodule ... init\".\n> +\twhile test $# -ne 0\n> +\tdo\n> +\t\tcase \"$1\" in\n> +\t\t-q|--quiet)\n> +\t\t\tGIT_QUIET=1\n> +\t\t\t;;\n> +\t\t--)\n> +\t\t\tshift\n> +\t\t\tbreak\n> +\t\t\t;;\n> +\t\t-*)\n> +\t\t\tusage\n> +\t\t\t;;\n> +\t\t*)\n> +\t\t\tbreak\n> +\t\t\t;;\n> +\t\tesac\n> +\t\tshift\n> +\tdone\n> +\n> +\tmodule_list \"$@\" |\n> +\twhile read mode sha1 stage sm_path\n> +\tdo\n> +\t\tdie_if_unmatched \"$mode\"\n> +\t\tname=$(module_name \"$sm_path\") || exit\n> +\t\turl=$(git config submodule.\"$name\".url)\n> +\t\tif test -z \"$url\"\n> +\t\tthen\n> +\t\t\t# Only mention uninitialized submodules when its\n> +\t\t\t# path have been specified\n> +\t\t\ttest \"$#\" != \"0\" &&\n> +\t\t\tsay \"$(eval_gettext \"No url found for submodule path '\\$sm_path' in .git/config\")\"\n> +\t\t\tcontinue\n> +\t\tfi\n> +\t\t# Remove the whole section so we have a clean state when the user\n> +\t\t# later decides to init this submodule again\n> +\t\tgit config --remove-section submodule.\"$name\" &&\n> +\t\tsay \"$(eval_gettext \"Submodule '\\$name' (\\$url) unregistered\")\"\n> +\tdone\n> +}\n> +\n> +#\n> # Update each submodule path to correct revision, using clone and checkout as needed\n> #\n> # $@ = requested paths (default to all)\n> @@ -1108,7 +1158,7 @@ cmd_sync()\n> while test $# != 0 && test -z \"$command\"\n> do\n> \tcase \"$1\" in\n> -\tadd | foreach | init | update | status | summary | sync)\n> +\tadd | foreach | init | deinit | update | status | summary | sync)\n> \t\tcommand=$1\n> \t\t;;\n> \t-q|--quiet)\n> diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh\n> index de7d453..ee4f0ab 100755\n> --- a/t/t7400-submodule-basic.sh\n> +++ b/t/t7400-submodule-basic.sh\n> @@ -756,4 +756,16 @@ test_expect_success 'submodule add with an existing name fails unless forced' '\n> \t)\n> '\n> \n> +test_expect_success 'submodule deinit should remove the whole submodule section from .git/config' '\n> +\tgit config submodule.example.foo bar &&\n> +\tgit submodule deinit &&\n> +\ttest -z \"$(git config submodule.example.url)\" &&\n> +\ttest -z \"$(git config submodule.example.foo)\"\n> +'\n> +\n> +test_expect_success 'submodule deinit complains only when explicitly used on an uninitialized submodule' '\n> +\tgit submodule deinit &&\n> +\ttest_must_fail git submodule deinit example\n> +'\n> +\n> test_done\n> \n"},{"id":"204747","messageId":"20121212152437.GB5157@odin.tremily.us","threadId":"32245","inReplyTo":"7vtxrr6d2f.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v7 0/3] submodule update: add --remote for submodule's upstream changes","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-12T15:24:37Z","receivedAt":"2012-12-12T15:24:37Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Tue, Dec 11, 2012 at 09:42:48PM -0800, Junio C Hamano wrote:\n> What branch did you base this series on?\n\nEvery version of this series has been based on v1.8.0.\n\n> The preimage of git-submodule.sh in [2/3] does not seem to match\n> anything I have (I could wiggle the patch, but in general I would\n> rather prefer not having to).\n\nFrom patch 1/3:\n\n diff --git a/git-submodule.sh b/git-submodule.sh\n index ab6b110..f969f28 100755\n\nAnd from patch 2/3:\n\n diff --git a/git-submodule.sh b/git-submodule.sh\n index f969f28..1395079 100755\n\nab6b110 is in v1.8.0:\n\n $ git ls-tree v1.8.0 git-submodule.sh\n 100755 blob ab6b1107b6090494f192f361471ed5748ffa7dc1 git-submodule.sh\n\nI can reroll if necessary, but I'm not sure what I've done wrong…\n\nCheers,\nTrevor\n"},{"id":"204757","messageId":"50C8BD6B.9010702@web.de","threadId":"32245","inReplyTo":"50C89DF3.20303@drmicha.warpmail.net","subject":"Re: [PATCH v2] submodule: add 'deinit' command","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-12-12T17:22:51Z","receivedAt":"2012-12-12T17:22:51Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 12.12.2012 16:08, schrieb Michael J Gruber:\n> Jens Lehmann venit, vidit, dixit 04.12.2012 22:48:\n>> With \"git submodule init\" the user is able to tell git he cares about one\n>> or more submodules and wants to have it populated on the next call to \"git\n>> submodule update\". But currently there is no easy way he could tell git he\n>> does not care about a submodule anymore and wants to get rid of his local\n>> work tree (except he knows a lot about submodule internals and removes the\n>> \"submodule.$name.url\" setting from .git/config himself).\n>>\n>> Help those users by providing a 'deinit' command. This removes the whole\n>> submodule. section from .git/config either for the given\n>> submodule(s) or for all those which have been initialized if none were\n>> given. Complain only when for a submodule given on the command line the\n>> url setting can't be found in .git/config.\n> \n> Whoaaa, so why not have \"git rm\" remove everything unless I specify a\n> file to be removed?\n\nBecause \"git add\" doesn't add any file in that case either?\n\n> I know I'm exaggerating a bit, but defaulting to \"--all\" for a\n> destructive operation seems to be a bit harsh, especially when the\n> command is targeted at \"those\" users that you mention.\n\nAll other submodule commands (except add, which only operates on a\nsingle submodule to be) iterate over all submodules if none were\nexplicitly given on the command line. So I made deinit just behave\nlike all the others - and especially init - do. But if people really\nare surprised by being consistent here I won't argue against adding\nsuch a \"--all\" option, but currently I'm not convinced it is worth\nit. Especially as I suspect the number of submodule users having\ncustomized those in .git/config is not that high ...\n"},{"id":"204760","messageId":"CABURp0oLmSjiZAOJxEzwSmL+jimpVj8DcDi-odPTzCpCcyH8yA@mail.gmail.com","threadId":"32245","inReplyTo":"64d109da03c521303ad87b8370bf09ab28a5c09f.1355251862.git.wking@tremily.us","subject":"Re: [PATCH v7 2/3] submodule update: add --remote for submodule's upstream changes","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-12-12T17:43:23Z","receivedAt":"2012-12-12T17:43:23Z","isPatch":true,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"Thanks for looking after this.\n\n\nOn Tue, Dec 11, 2012 at 1:58 PM, W. Trevor King wrote:\n> From: \"W. Trevor King\" \n>\n> The current `update` command incorporates the superproject's gitlinked\n> SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the\n> options you use, it may checkout $sha1, rebase the $subsha1 onto\n> $sha1, or merge $sha1 into $subsha1. This helps you keep up with\n> changes in the upstream superproject.\n>\n> However, it's also useful to stay up to date with changes in the\n> upstream subproject. Previous workflows for incorporating such\n> changes include the ungainly:\n>\n> $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n>\n> With this patch, all of the useful functionality for incorporating\n> superproject changes can be reused to incorporate upstream subproject\n> updates. When you specify --remote, the target $sha1 is replaced with\n> a $sha1 of the submodule's origin/master tracking branch. If you want\n> to merge a different tracking branch, you can configure the\n> `submodule..branch` option in `.gitmodules`. You can override\n> the `.gitmodules` configuration setting for a particular superproject\n> by configuring the option in that superproject's default configuration\n> (using the usual configuration hierarchy, e.g. `.git/config`,\n> `~/.gitconfig`, etc.).\n>\n> Previous use of submodule..branch\n> =======================================\n>\n> Because we're adding a new configuration option, it's a good idea to\n> check if anyone else is already using the option. The foreach-pull\n> example above was described by Ævar 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>\n> Gerrit uses the same interpretation for the setting, but because\n> Gerrit has direct access to the subproject repositories, it updates\n> the superproject repositories automatically when a subproject changes.\n> Gerrit also accepts the special value '.', which it expands into the\n> superproject's branch name.\n>\n> Although the --remote functionality is using `submodule..branch`\n> slightly differently, the effect is the same. The foreach-pull\n> example uses the option to record the name of the local branch to\n> checkout before pulls. The tracking branch to be pulled is recorded\n> in `.git/modules//config`, which was initialized by the module\n> clone during `submodule add` or `submodule init`. Because the branch\n> name stored in `submodule..branch` was likely the same as the\n> branch name used during the initial `submodule add`, the same branch\n> will be pulled in each workflow.\n>\n> Implementation details\n> ======================\n>\n> In order to ensure a current tracking branch state, `update --remote`\n> fetches the submodule's remote repository before calculating the\n> SHA-1. However, I didn't change the logic guarding the existing fetch:\n>\n> if test -z \"$nofetch\"\n> then\n> # Run fetch only if $sha1 isn't present or it\n> # is not reachable from a ref.\n> (clear_local_git_env; cd \"$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 '\\$path'\")\"\n> fi\n>\n> There will not be a double-fetch, because the new $sha1 determined\n> after the `--remote` triggered fetch should always exist in the\n> repository. If it doesn't, it's because some racy process removed it\n> from the submodule's repository and we *should* be re-fetching.\n>\n> Signed-off-by: W. Trevor King \n> ---\n> Documentation/config.txt | 7 ++++++-\n> Documentation/git-submodule.txt | 25 ++++++++++++++++++++++++-\n> Documentation/gitmodules.txt | 5 +++++\n> git-submodule.sh | 22 +++++++++++++++++++++-\n> t/t7406-submodule-update.sh | 31 +++++++++++++++++++++++++++++++\n> 5 files changed, 87 insertions(+), 3 deletions(-)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 11f320b..6f4663c 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -1998,7 +1998,12 @@ submodule..update::\n> for a submodule. These variables are initially populated\n> by 'git submodule init'; edit them to override the\n> URL and other values found in the `.gitmodules` file. See\n> - linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.\n> +\n> +submodule..branch::\n> + The remote branch name for a submodule, used by `git submodule\n> + update --remote`. Set this option to override the value found in\n> + the `.gitmodules` file. See linkgit:git-submodule[1] and\n> + linkgit:gitmodules[5] for details.\n>\n> submodule..fetchRecurseSubmodules::\n> This option can be used to control recursive fetching of this\n> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> index b4683bb..72dd52f 100644\n> --- a/Documentation/git-submodule.txt\n> +++ b/Documentation/git-submodule.txt\n> @@ -13,7 +13,7 @@ SYNOPSIS\n> [--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] [--remote] [-N|--no-fetch] [--rebase]\n> [--reference ] [--merge] [--recursive] [--] [...]\n> 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]\n> [commit] [--] [...]\n> @@ -236,6 +236,29 @@ OPTIONS\n> (the default). This limit only applies to modified submodules. The\n> size is always limited to 1 for added/deleted/typechanged submodules.\n>\n> +--remote::\n> + This option is only valid for the update command. Instead of using\n> + the superproject's recorded SHA-1 to update the submodule, use the\n> + status of the submodule's remote tracking branch. The remote used\n> + is branch's remote (`branch..remote`), defaulting to `origin`.\n> + The remote branch used defaults to `master`, but the branch name may\n> + be overridden by setting the `submodule..branch` option in\n> + either `.gitmodules` or `.git/config` (with `.git/config` taking\n> + precedence).\n> ++\n> +This works for any of the supported update procedures (`--checkout`,\n> +`--rebase`, etc.). The only change is the source of the target SHA-1.\n> +For example, `submodule update --remote --merge` will merge upstream\n> +submodule changes into the submodules, while `submodule update\n> +--merge` will merge superproject gitlink changes into the submodules.\n> ++\n> +In order to ensure a current tracking branch state, `update --remote`\n> +fetches the submodule's remote repository before calculating the\n> +SHA-1. This makes `submodule update --remote --merge` similar to\n> +running `git pull` in the submodule. If you don't want to fetch (for\n> +something closer to `git merge`), you should use `submodule update\n> +--remote --no-fetch --merge`.\n\nI assume the same can be said for 'submodue update --remote --rebase',\nright? I wonder if this can be made merge/rebase-agnostic. Is it\nstill true if I word it like this?:\n\n In order to ensure a current tracking branch state, `update --remote`\n fetches the submodule's remote repository before calculating the\n SHA-1. If you don't want to fetch, you should use `submodule update\n --remote --no-fetch`.\n\n\n> +\n> -N::\n> --no-fetch::\n> This option is only valid for the update command.\n> diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt\n> index 4effd78..4004fa6 100644\n> --- a/Documentation/gitmodules.txt\n> +++ b/Documentation/gitmodules.txt\n> @@ -47,6 +47,11 @@ submodule..update::\n> This config option is overridden if 'git submodule update' is given\n> the '--merge', '--rebase' or '--checkout' options.\n>\n> +submodule..branch::\n> + A remote branch name for tracking updates in the upstream submodule.\n> + If the option is not specified, it defaults to 'master'. See the\n> + `--remote` documentation in linkgit:git-submodule[1] for details.\n> +\n> submodule..fetchRecurseSubmodules::\n> This option can be used to control recursive fetching of this\n> submodule. If this option is also present in the submodules entry in\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index f969f28..1395079 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -8,7 +8,8 @@ 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] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n> +ges\n\nI think there's an unintentionally added line here with \"ges\".\n\n> or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ] [commit] [--] [...]\n> or: $dashless [--quiet] foreach [--recursive] \n> or: $dashless [--quiet] sync [--] [...]\"\n> @@ -26,6 +27,7 @@ cached=\n> recursive=\n> init=\n> files=\n> +remote=\n> nofetch=\n> update=\n> prefix=\n> @@ -535,6 +537,9 @@ cmd_update()\n> -i|--init)\n> init=1\n> ;;\n> + --remote)\n> + remote=1\n> + ;;\n> -N|--no-fetch)\n> nofetch=1\n> ;;\n> @@ -595,6 +600,7 @@ cmd_update()\n> fi\n> name=$(module_name \"$sm_path\") || exit\n> url=$(git config submodule.\"$name\".url)\n> + branch=$(get_submodule_config \"$name\" branch master)\n> if ! test -z \"$update\"\n> then\n> update_module=$update\n> @@ -629,6 +635,20 @@ Maybe you want to use 'update --init'?\")\"\n> die \"$(eval_gettext \"Unable to find current revision in submodule path '\\$sm_path'\")\"\n> fi\n>\n> + if test -n \"$remote\"\n> + then\n> + if test -z \"$nofetch\"\n> + then\n> + # Fetch remote before determining tracking $sha1\n> + (clear_local_git_env; cd \"$sm_path\" && git-fetch) ||\n\nYou should 'git fetch $remote_name' here, and of course, initialize\nremote_name before this. But how can we know the remote_name in the\nfirst place? Is it safe to assume the submodule remote names will\nmatch those in the superproject?\n\n> + die \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n> + fi\n> + remote_name=$(get_default_remote)\n\nThis get_default_remote finds the remote for the remote-tracking\nbranch for HEAD in the superproject. It is possible that HEAD !=\n$branch, so we have very few clues to go on here to get a more\nreasonable answer, so I do not have any good suggestions to improve\nthis.\n\nOne option would be to find the remote given for\nsubmodule.\"$branch\".merge, but this would suppose there is some\nremote-tracking branch configured in the submodule, and that is not\nlikely to be the case.\n\n> + sha1=$(clear_local_git_env; cd \"$sm_path\" &&\n> + git rev-parse --verify \"${remote_name}/${branch}\") ||\n\nThis does assume the submodule remote names will match those in the\nsuperproject. Is this safe?\n\n> + die \"$(eval_gettext \"Unable to find current ${remote_name}/${branch} revision in submodule path '\\$sm_path'\")\"\n> + fi\n> +\n> if test \"$subsha1\" != \"$sha1\" -o -n \"$force\"\n> then\n> subforce=$force\n> diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\n> index 1542653..a567834 100755\n> --- a/t/t7406-submodule-update.sh\n> +++ b/t/t7406-submodule-update.sh\n> @@ -135,6 +135,37 @@ test_expect_success 'submodule update --force forcibly checks out submodules' '\n> )\n> '\n>\n> +test_expect_success 'submodule update --remote should fetch upstream changes' '\n> + (cd submodule &&\n> + echo line4 >> file &&\n> + git add file &&\n> + test_tick &&\n> + git commit -m \"upstream line4\"\n> + ) &&\n> + (cd super &&\n> + git submodule update --remote --force submodule &&\n> + cd submodule &&\n> + test \"$(git log -1 --oneline)\" = \"$(GIT_DIR=../../submodule/.git git log -1 --oneline)\"\n> + )\n> +'\n> +\n> +test_expect_success 'local config should override .gitmodules branch' '\n> + (cd submodule &&\n> + git checkout -b test-branch &&\n> + echo line5 >> file &&\n> + git add file &&\n> + test_tick &&\n> + git commit -m \"upstream line5\" &&\n> + git checkout master\n> + ) &&\n> + (cd super &&\n> + git config submodule.submodule.branch test-branch &&\n> + git submodule update --remote --force submodule &&\n> + cd submodule &&\n> + test \"$(git log -1 --oneline)\" = \"$(GIT_DIR=../../submodule/.git git log -1 --oneline test-branch)\"\n> + )\n> +'\n> +\n> test_expect_success 'submodule update --rebase staying on master' '\n> (cd super/submodule &&\n> git checkout master\n> --\n> 1.8.0\n>\n"},{"id":"204768","messageId":"7vzk1j3zgr.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"20121212152437.GB5157@odin.tremily.us","subject":"Re: [PATCH v7 0/3] submodule update: add --remote for submodule's upstream changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-12T18:19:32Z","receivedAt":"2012-12-12T18:19:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n> On Tue, Dec 11, 2012 at 09:42:48PM -0800, Junio C Hamano wrote:\n>> What branch did you base this series on?\n>\n> Every version of this series has been based on v1.8.0.\n\nThanks.\n\nThere were quite a few changes to git-submodule.sh since then to\n'master' and I had to either wiggle the patch or know which exact\none 1/3 needs to be applied to in order to allow 2/3 to apply (try\napplying these three to 'master' yourself---you will likely to see\nthat 2/3 will stop with conflicts).\n\nIn any case, I ended up applying them by editing the patches, and I\nshould have a good copy in 'pu'. Please double check the result.\n\nThanks.\n"},{"id":"204774","messageId":"7vr4mv3w2x.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"50C8BD6B.9010702@web.de","subject":"Re: [PATCH v2] submodule: add 'deinit' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-12T19:32:38Z","receivedAt":"2012-12-12T19:32:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> Especially as I suspect the number of submodule users having\n> customized those in .git/config is not that high ...\n\nI thought the point of \"deinit\" was to say \"I am not interested in\nhaving a checkout of these submodules in my working tree anymore\".\nThe user could do \"rm -fr submodule && mkdir submodule\" to remove it\nlocally and keep \"diff\" and \"status\" from noticing the removal, but\nthe primary reason the user needs an explicit \"deinit\" is because\nmany subcommands of \"git submodule\" are documented to operate on all\nsubmodules that have been \"init\"ed when given no explicit submodule\nnames [*1*].\n\nYour \"deinit\" is documented not to actually remove the submodule\ncheckout, but that very much goes against my intuition. What is the\njustification behind that choice? \"We'll remove the configuration,\nyou remove the tree yourself\" will invite the mistake of running\n\"git rm\" on it, which you wanted to avoid with the addition to the\n\"git rm\" documentation, no?\n\n\n[Footnote]\n\n*1* In reality, the code looks at presense of .git in the submodule\npath to decide if it has been \"init\"ed (cf. cmd_update), but this\nimplementation of \"deinit\" does not seem to cause that .git to be\nremoved, leaving the submodule in \"init\"ed state from these other\ncommand's perspective.\n"},{"id":"204778","messageId":"7v7gon3v2r.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"CABURp0oLmSjiZAOJxEzwSmL+jimpVj8DcDi-odPTzCpCcyH8yA@mail.gmail.com","subject":"Re: [PATCH v7 2/3] submodule update: add --remote for submodule's upstream changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-12T19:54:20Z","receivedAt":"2012-12-12T19:54:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phil Hord writes:\n\n>> + if test -n \"$remote\"\n>> + then\n>> + if test -z \"$nofetch\"\n>> + then\n>> + # Fetch remote before determining tracking $sha1\n>> + (clear_local_git_env; cd \"$sm_path\" && git-fetch) ||\n>\n> You should 'git fetch $remote_name' here, and of course, initialize\n> remote_name before this. But how can we know the remote_name in the\n> first place? Is it safe to assume the submodule remote names will\n> match those in the superproject?\n>\n>> + die \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n>> + fi\n>> + remote_name=$(get_default_remote)\n>\n> This get_default_remote finds the remote for the remote-tracking\n> branch for HEAD in the superproject. It is possible that HEAD !=\n> $branch, so we have very few clues to go on here to get a more\n> reasonable answer, so I do not have any good suggestions to improve\n> this.\n>\n> One option would be to find the remote given for\n> submodule.\"$branch\".merge, but this would suppose there is some\n> remote-tracking branch configured in the submodule, and that is not\n> likely to be the case.\n>\n>> + sha1=$(clear_local_git_env; cd \"$sm_path\" &&\n>> + git rev-parse --verify \"${remote_name}/${branch}\") ||\n>\n> This does assume the submodule remote names will match those in the\n> superproject. Is this safe?\n\nAll good points. Thanks for reviewing.\n"},{"id":"204788","messageId":"50C90469.8080303@web.de","threadId":"32245","inReplyTo":"7vr4mv3w2x.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] submodule: add 'deinit' command","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-12-12T22:25:45Z","receivedAt":"2012-12-12T22:25:45Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 12.12.2012 20:32, schrieb Junio C Hamano:\n> Jens Lehmann writes:\n> \n>> Especially as I suspect the number of submodule users having\n>> customized those in .git/config is not that high ...\n> \n> I thought the point of \"deinit\" was to say \"I am not interested in\n> having a checkout of these submodules in my working tree anymore\".\n\nYes. (But I'm not sure users expect that command to also remove\nthe work tree)\n\n> The user could do \"rm -fr submodule && mkdir submodule\" to remove it\n> locally and keep \"diff\" and \"status\" from noticing the removal, but\n> the primary reason the user needs an explicit \"deinit\" is because\n> many subcommands of \"git submodule\" are documented to operate on all\n> submodules that have been \"init\"ed when given no explicit submodule\n> names [*1*].\n\nThe real reason we need deinit is that the next run of \"submodule\nupdate\" will otherwise happily recreate the submodule checkout you\njust removed as long as it finds the url setting in .git/config.\n\n> Your \"deinit\" is documented not to actually remove the submodule\n> checkout, but that very much goes against my intuition. What is the\n> justification behind that choice?\n\nI thought it should match what \"submodule init\" does, which is to do\nnothing to the work tree until the next \"submodule update\" is run.\n(But I agree that analogy is somewhat flawed until we teach \"update\"\nto remove a deinitialized submodule - or maybe teach it the --deinit\noption which could do both). On the other hand with current git\nsubmodule work trees always stay around anyway until you remove them\nby hand (e.g. when you switch to a branch that doesn't have it), so\nI'm not sure what would surprise people more here. So I just left\nthe work tree unchanged.\n\n> \"We'll remove the configuration,\n> you remove the tree yourself\" will invite the mistake of running\n> \"git rm\" on it, which you wanted to avoid with the addition to the\n> \"git rm\" documentation, no?\n\nI think that'll happen only if git would remind them that they\nstill have a populated work tree, which I believe it shouldn't.\n\n> [Footnote]\n> \n> *1* In reality, the code looks at presense of .git in the submodule\n> path to decide if it has been \"init\"ed (cf. cmd_update), but this\n> implementation of \"deinit\" does not seem to cause that .git to be\n> removed, leaving the submodule in \"init\"ed state from these other\n> command's perspective.\n\nNope, cmd_update() checks first if the url is found in .git/config\nand skips the submodule if not. I rechecked and only \"summary\" and\n\"foreach\" still recurse into a deinitialized submodule, which they\nshouldn't. But a quick test shows that \"git status\" and \"git diff\"\nalso still inspect a deinitialized submodule, so there's some work\nleft to do to handle the case where the work tree is not removed.\n\nSo unless people agree that deinit should also remove the work\ntree I'll prepare some patches teaching all git commands to\nconsistently ignore deinitialized submodules. Opinions?\n"},{"id":"204791","messageId":"7vlid23nnc.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"50C90469.8080303@web.de","subject":"Re: [PATCH v2] submodule: add 'deinit' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-12T22:34:47Z","receivedAt":"2012-12-12T22:34:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> So unless people agree that deinit should also remove the work\n> tree I'll prepare some patches teaching all git commands to\n> consistently ignore deinitialized submodules. Opinions?\n\nWhile I agree that consistency is good, \"deinit\" that does not\nremove the working tree of the submodule the user explicitly said he\nno longer wants to have the checkout for is a bug, and I think these\ntwo are orthogonal issues.\n\nIn other words, \"Ignore deinitialized submodules even when an\nearlier bug in deinit failed to remove the working tree\" is a\nrobustness issue for the other recursing commands, not an excuse for\n\"deinit\" to have such a bug in the first place, I think.\n"},{"id":"204794","messageId":"20121212224425.GA7729@odin.tremily.us","threadId":"32245","inReplyTo":"7vzk1j3zgr.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v7 0/3] submodule update: add --remote for submodule's upstream changes","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-12T22:44:25Z","receivedAt":"2012-12-12T22:44:25Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Wed, Dec 12, 2012 at 10:19:32AM -0800, Junio C Hamano wrote:\n> In any case, I ended up applying them by editing the patches, and I\n> should have a good copy in 'pu'. Please double check the result.\n\nYour 'pu' branch looks good to me. Most of the differences with my\ninitial patch are due to irrelevant context lines. I would change\npatch 3 (commit 2f507f9a in 'pu') to use\n\n git config -f .gitmodules submodule.\"$sm_name\".branch \"$branch\"\n ^\ninstead of\n\n git config -f .gitmodules submodule.\"$sm_path\".branch \"$branch\"\n ^\nto match the nearby changes from 73b0898d.\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":"204798","messageId":"20121212230217.GB7729@odin.tremily.us","threadId":"32245","inReplyTo":"CABURp0oLmSjiZAOJxEzwSmL+jimpVj8DcDi-odPTzCpCcyH8yA@mail.gmail.com","subject":"Re: [PATCH v7 2/3] submodule update: add --remote for submodule's upstream changes","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-12T23:02:17Z","receivedAt":"2012-12-12T23:02:17Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Wed, Dec 12, 2012 at 12:43:23PM -0500, Phil Hord wrote:\n> On Tue, Dec 11, 2012 at 1:58 PM, W. Trevor King wrote:\n> > diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\n> > …\n> > +--remote::\n> > [snip some --remote documentation]\n> > +In order to ensure a current tracking branch state, `update --remote`\n> > +fetches the submodule's remote repository before calculating the\n> > +SHA-1. This makes `submodule update --remote --merge` similar to\n> > +running `git pull` in the submodule. If you don't want to fetch (for\n> > +something closer to `git merge`), you should use `submodule update\n> > +--remote --no-fetch --merge`.\n> \n> I assume the same can be said for 'submodue update --remote --rebase',\n> right?\n\nYes.\n\n> I wonder if this can be made merge/rebase-agnostic. Is it still\n> true if I word it like this?:\n> \n> In order to ensure a current tracking branch state, `update --remote`\n> fetches the submodule's remote repository before calculating the\n> SHA-1. If you don't want to fetch, you should use `submodule update\n> --remote --no-fetch`.\n\nWorks for me. Will change in v8 (which I'll base on 'master').\n\n> > diff --git a/git-submodule.sh b/git-submodule.sh\n> > index f969f28..1395079 100755\n> > --- a/git-submodule.sh\n> > +++ b/git-submodule.sh\n> > @@ -8,7 +8,8 @@ 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] [--remote] [-N|--no-fetch] [-f|--force] [--rebase] [--reference ] [--merge] [--recursive] [--] [...]\n> > +ges\n> \n> I think there's an unintentionally added line here with \"ges\".\n\nThat is embarrassing :p. Will fix in v8.\n\n> > + if test -n \"$remote\"\n> > + then\n> > + if test -z \"$nofetch\"\n> > + then\n> > + # Fetch remote before determining tracking $sha1\n> > + (clear_local_git_env; cd \"$sm_path\" && git-fetch) ||\n> \n> You should 'git fetch $remote_name' here, and of course, initialize\n> remote_name before this. But how can we know the remote_name in the\n> first place? Is it safe to assume the submodule remote names will\n> match those in the superproject?\n\nThe other git-fetch call from git-submodule.sh is also bare (i.e. no\nspecified remote). When the remote needs to be specified, other\nportions of git-submodule.sh use $(get_default_remote), which is (I\nthink) what the user should expect. v6 of this series had a\nconfigurable remote name, but Junio wasn't keen on the additional\nconfiguration option. I don't really mind either way.\n\n> \n> > + die \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n> > + fi\n> > + remote_name=$(get_default_remote)\n> \n> This get_default_remote finds the remote for the remote-tracking\n> branch for HEAD in the superproject. It is possible that HEAD !=\n> $branch, so we have very few clues to go on here to get a more\n> reasonable answer, so I do not have any good suggestions to improve\n> this.\n\nFor detached HEADs, get_default_remote should fall back to 'origin',\nwhich seems sane. If the user wants a different default, they've\nlikely checkout out a branch in the submodule, setup that branch's\nremote, and will be using --merge or --rebase. If anyone expects\nusers who will be using detached heads to *want* to specify a\ndifferent remote than 'origin', that would be a good argument for\nreinstating my submodule..remote patch from v6.\n\n> > + sha1=$(clear_local_git_env; cd \"$sm_path\" &&\n> > + git rev-parse --verify \"${remote_name}/${branch}\") ||\n> \n> This does assume the submodule remote names will match those in the\n> superproject. Is this safe?\n\nAnother good catch. I should be calling get_default_remote after\ncd-ing into the submodule. Will change in v8.\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":"204802","messageId":"20121212230926.GC7729@odin.tremily.us","threadId":"32245","inReplyTo":"7vlid23nnc.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] submodule: add 'deinit' command","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-12T23:09:26Z","receivedAt":"2012-12-12T23:09:26Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Wed, Dec 12, 2012 at 02:34:47PM -0800, Junio C Hamano wrote:\n> Jens Lehmann writes:\n> \n> > So unless people agree that deinit should also remove the work\n> > tree I'll prepare some patches teaching all git commands to\n> > consistently ignore deinitialized submodules. Opinions?\n> \n> While I agree that consistency is good, \"deinit\" that does not\n> remove the working tree of the submodule the user explicitly said he\n> no longer wants to have the checkout for is a bug, and I think these\n> two are orthogonal issues.\n\nShould `deinit` remove the submodule checkout, replace it with the\noriginal gitlink, and clear the .git/config information then? That\nwould restore the user to the state they'd be in if they were never\ninterested in the submodule.\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":"204807","messageId":"7vsj7a268w.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"20121212230926.GC7729@odin.tremily.us","subject":"Re: [PATCH v2] submodule: add 'deinit' command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-12T23:35:59Z","receivedAt":"2012-12-12T23:35:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n> Should `deinit` remove the submodule checkout, replace it with the\n> original gitlink, and clear the .git/config information then? That\n> would restore the user to the state they'd be in if they were never\n> interested in the submodule.\n\nAFAIU, \"restore the user to the state\" is the goal. I am not sure\nwhat you meant by \"replace it with the original gitlink\", though. A\ncheckout with a submodule that the user is not interested in would\nhave an empty directory at that path, no?\n"},{"id":"204814","messageId":"20121213002805.GA8380@odin.tremily.us","threadId":"32245","inReplyTo":"7vsj7a268w.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] submodule: add 'deinit' command","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-13T00:28:05Z","receivedAt":"2012-12-13T00:28:05Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Wed, Dec 12, 2012 at 03:35:59PM -0800, Junio C Hamano wrote:\n> \"W. Trevor King\" writes:\n> \n> > Should `deinit` remove the submodule checkout, replace it with the\n> > original gitlink, and clear the .git/config information then? That\n> > would restore the user to the state they'd be in if they were never\n> > interested in the submodule.\n> \n> AFAIU, \"restore the user to the state\" is the goal. I am not sure\n> what you meant by \"replace it with the original gitlink\", though. A\n> checkout with a submodule that the user is not interested in would\n> have an empty directory at that path, no?\n\nAh yes, the gitlink is only in the index. Sorry for the noise.\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":"204836","messageId":"50C9F87E.6090902@xiplink.com","threadId":"32245","inReplyTo":"50C90469.8080303@web.de","subject":"Re: [PATCH v2] submodule: add 'deinit' command","fromName":"Marc Branchaud","fromEmail":"mbranchaud@xiplink.com","sentAt":"2012-12-13T15:47:10Z","receivedAt":"2012-12-13T15:47:10Z","isPatch":true,"sender":{"key":"mbranchaud@xiplink.com","avatar":null},"body":"On 12-12-12 05:25 PM, Jens Lehmann wrote:\n> \n> So unless people agree that deinit should also remove the work\n> tree I'll prepare some patches teaching all git commands to\n> consistently ignore deinitialized submodules. Opinions?\n\nI agree with Trevor's suggestion that deinit should restore the user to the\nstate he would be in if he were never interested in the submodule. So clean\nup .git/config and remove the work tree. (Maybe just issue a warning instead\nif the submodule's work tree is dirty.)\n\nAlso, given that semantic, I agree with Michael that a bare \"git submodule\ndeinit\" should *not* deinitialize all the submodules. It should require a\n\"--all\" for that. The bare command should just print a usage summary.\n\n\t\tM.\n"},{"id":"205195","messageId":"cover.1355932282.git.wking@tremily.us","threadId":"32245","inReplyTo":"20121212230217.GB7729@odin.tremily.us","subject":"[PATCH v8 0/3] submodule update: add --remote for submodule's upstream changes","fromName":"","fromEmail":"wking@tremily.us","sentAt":"2012-12-19T16:03:30Z","receivedAt":"2012-12-19T16:03:30Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nComments on v7 seem to have petered out, so here's v8. Changes since\nv7:\n\n* Series based on gitster/master instead of v1.8.0.\n* In Documentation/config.txt, restored trailing line of\n submodule..update documentation, which I had accidentally\n removed in v7.\n* In Documentation/git-submodule.txt, make --no-fetch example in the\n --remote description more general, following Phil's suggestion.\n* In git-submodule.sh:\n * Remove accidental \"ges\" line.\n * Use the submodule's default remote to determine which tracking\n branch to fetch. In v7 I'd been using the superproject's default\n remote.\n * In cmd_add(), use sm_name instead of sm_path to store the --branch\n option (catching up with 73b0898).\n\nW. Trevor King (3):\n submodule: add get_submodule_config helper funtion\n submodule update: add --remote for submodule's upstream changes\n submodule add: If --branch is given, record it in .gitmodules\n\n Documentation/config.txt | 6 +++++\n Documentation/git-submodule.txt | 25 +++++++++++++++++++-\n Documentation/gitmodules.txt | 5 ++++\n git-submodule.sh | 51 ++++++++++++++++++++++++++++++++++++++++-\n t/t7400-submodule-basic.sh | 1 +\n t/t7406-submodule-update.sh | 31 +++++++++++++++++++++++++\n 6 files changed, 117 insertions(+), 2 deletions(-)\n\n-- \n1.8.0\n"},{"id":"205198","messageId":"3377beb925bc209d90058493b74d174db1b7aa50.1355932282.git.wking@tremily.us","threadId":"32245","inReplyTo":"cover.1355932282.git.wking@tremily.us","subject":"[PATCH v8 1/3] submodule: add get_submodule_config helper funtion","fromName":"","fromEmail":"wking@tremily.us","sentAt":"2012-12-19T16:03:31Z","receivedAt":"2012-12-19T16:03:31Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nSeveral submodule configuration variables\n(e.g. fetchRecurseSubmodules) are read from .gitmodules with local\noverrides from the usual git config files. This shell function mimics\nthat logic to help initialize configuration variables in\ngit-submodule.sh.\n\nSigned-off-by: W. Trevor King \n---\n git-submodule.sh | 26 ++++++++++++++++++++++++++\n 1 file changed, 26 insertions(+)\n\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 2365149..263a60c 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -153,6 +153,32 @@ die_if_unmatched ()\n }\n \n #\n+# Print a submodule configuration setting\n+#\n+# $1 = submodule name\n+# $2 = option name\n+# $3 = default value\n+#\n+# Checks in the usual git-config places first (for overrides),\n+# otherwise it falls back on .gitmodules. This allows you to\n+# distribute project-wide defaults in .gitmodules, while still\n+# customizing individual repositories if necessary. If the option is\n+# not in .gitmodules either, print a default value.\n+#\n+get_submodule_config () {\n+\tname=\"$1\"\n+\toption=\"$2\"\n+\tdefault=\"$3\"\n+\tvalue=$(git config submodule.\"$name\".\"$option\")\n+\tif test -z \"$value\"\n+\tthen\n+\t\tvalue=$(git config -f .gitmodules submodule.\"$name\".\"$option\")\n+\tfi\n+\tprintf '%s' \"${value:-$default}\"\n+}\n+\n+\n+#\n # Map submodule path to submodule name\n #\n # $1 = path\n-- \n1.8.0\n"},{"id":"205196","messageId":"6f5822c998ad01146727214941b4b52a5b3680dd.1355932282.git.wking@tremily.us","threadId":"32245","inReplyTo":"cover.1355932282.git.wking@tremily.us","subject":"[PATCH v8 2/3] submodule update: add --remote for submodule's upstream changes","fromName":"","fromEmail":"wking@tremily.us","sentAt":"2012-12-19T16:03:32Z","receivedAt":"2012-12-19T16:03:32Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nThe current `update` command incorporates the superproject's gitlinked\nSHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the\noptions you use, it may checkout $sha1, rebase the $subsha1 onto\n$sha1, or merge $sha1 into $subsha1. This helps you keep up with\nchanges in the upstream superproject.\n\nHowever, it's also useful to stay up to date with changes in the\nupstream subproject. Previous workflows for incorporating such\nchanges include the ungainly:\n\n $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'\n\nWith this patch, all of the useful functionality for incorporating\nsuperproject changes can be reused to incorporate upstream subproject\nupdates. When you specify --remote, the target $sha1 is replaced with\na $sha1 of the submodule's origin/master tracking branch. If you want\nto merge a different tracking branch, you can configure the\n`submodule..branch` option in `.gitmodules`. You can override\nthe `.gitmodules` configuration setting for a particular superproject\nby configuring the option in that superproject's default configuration\n(using the usual configuration hierarchy, e.g. `.git/config`,\n`~/.gitconfig`, etc.).\n\nPrevious use of submodule..branch\n=======================================\n\nBecause we're adding a new configuration option, it's a good idea to\ncheck if anyone else is already using the option. The foreach-pull\nexample above was described by Ævar 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\nAlthough the --remote functionality is using `submodule..branch`\nslightly differently, the effect is the same. The foreach-pull\nexample uses the option to record the name of the local branch to\ncheckout before pulls. The tracking branch to be pulled is recorded\nin `.git/modules//config`, which was initialized by the module\nclone during `submodule add` or `submodule init`. Because the branch\nname stored in `submodule..branch` was likely the same as the\nbranch name used during the initial `submodule add`, the same branch\nwill be pulled in each workflow.\n\nImplementation details\n======================\n\nIn order to ensure a current tracking branch state, `update --remote`\nfetches the submodule's remote repository before calculating the\nSHA-1. However, I didn't change the logic guarding the existing fetch:\n\n if test -z \"$nofetch\"\n then\n # Run fetch only if $sha1 isn't present or it\n # is not reachable from a ref.\n (clear_local_git_env; cd \"$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 '\\$path'\")\"\n fi\n\nThere will not be a double-fetch, because the new $sha1 determined\nafter the `--remote` triggered fetch should always exist in the\nrepository. If it doesn't, it's because some racy process removed it\nfrom the submodule's repository and we *should* be re-fetching.\n\nSigned-off-by: W. Trevor King \n---\n Documentation/config.txt | 6 ++++++\n Documentation/git-submodule.txt | 23 ++++++++++++++++++++++-\n Documentation/gitmodules.txt | 5 +++++\n git-submodule.sh | 21 ++++++++++++++++++++-\n t/t7406-submodule-update.sh | 31 +++++++++++++++++++++++++++++++\n 5 files changed, 84 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex bf8f911..7976a6b 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1995,6 +1995,12 @@ submodule..update::\n \tURL and other values found in the `.gitmodules` file. See\n \tlinkgit:git-submodule[1] and linkgit:gitmodules[5] for details.\n \n+submodule..branch::\n+\tThe remote branch name for a submodule, used by `git submodule\n+\tupdate --remote`. Set this option to override the value found in\n+\tthe `.gitmodules` file. See linkgit:git-submodule[1] and\n+\tlinkgit:gitmodules[5] for details.\n+\n submodule..fetchRecurseSubmodules::\n \tThis option can be used to control recursive fetching of this\n \tsubmodule. It can be overridden by using the --[no-]recurse-submodules\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex b1de3ba..8bf173a 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -13,7 +13,7 @@ SYNOPSIS\n \t [--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] [--remote] [-N|--no-fetch] [--rebase]\n \t [--reference ] [--merge] [--recursive] [--] [...]\n 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) ]\n \t [commit] [--] [...]\n@@ -236,6 +236,27 @@ OPTIONS\n \t(the default). This limit only applies to modified submodules. The\n \tsize is always limited to 1 for added/deleted/typechanged submodules.\n \n+--remote::\n+\tThis option is only valid for the update command. Instead of using\n+\tthe superproject's recorded SHA-1 to update the submodule, use the\n+\tstatus of the submodule's remote tracking branch. The remote used\n+\tis branch's remote (`branch..remote`), defaulting to `origin`.\n+\tThe remote branch used defaults to `master`, but the branch name may\n+\tbe overridden by setting the `submodule..branch` option in\n+\teither `.gitmodules` or `.git/config` (with `.git/config` taking\n+\tprecedence).\n++\n+This works for any of the supported update procedures (`--checkout`,\n+`--rebase`, etc.). The only change is the source of the target SHA-1.\n+For example, `submodule update --remote --merge` will merge upstream\n+submodule changes into the submodules, while `submodule update\n+--merge` will merge superproject gitlink changes into the submodules.\n++\n+In order to ensure a current tracking branch state, `update --remote`\n+fetches the submodule's remote repository before calculating the\n+SHA-1. If you don't want to fetch, you should use `submodule update\n+--remote --no-fetch`.\n+\n -N::\n --no-fetch::\n \tThis option is only valid for the update command.\ndiff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt\nindex ab3e91c..52d7ae4 100644\n--- a/Documentation/gitmodules.txt\n+++ b/Documentation/gitmodules.txt\n@@ -49,6 +49,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 remote branch name for tracking updates in the upstream submodule.\n+\tIf the option is not specified, it defaults to 'master'. See the\n+\t`--remote` documentation in linkgit:git-submodule[1] for details.\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 263a60c..6ae51c6 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 ] [-f|--force] [--name ] [--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] [--remote] [-N|--no-fetch] [-f|--force] [--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 [--recursive] [--] [...]\"\n@@ -26,6 +26,7 @@ cached=\n recursive=\n init=\n files=\n+remote=\n nofetch=\n update=\n prefix=\n@@ -559,6 +560,9 @@ cmd_update()\n \t\t-i|--init)\n \t\t\tinit=1\n \t\t\t;;\n+\t\t--remote)\n+\t\t\tremote=1\n+\t\t\t;;\n \t\t-N|--no-fetch)\n \t\t\tnofetch=1\n \t\t\t;;\n@@ -619,6 +623,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=$(get_submodule_config \"$name\" branch master)\n \t\tif ! test -z \"$update\"\n \t\tthen\n \t\t\tupdate_module=$update\n@@ -653,6 +658,20 @@ 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 -n \"$remote\"\n+\t\tthen\n+\t\t\tif test -z \"$nofetch\"\n+\t\t\tthen\n+\t\t\t\t# Fetch remote before determining tracking $sha1\n+\t\t\t\t(clear_local_git_env; cd \"$sm_path\" && git-fetch) ||\n+\t\t\t\tdie \"$(eval_gettext \"Unable to fetch in submodule path '\\$sm_path'\")\"\n+\t\t\tfi\n+\t\t\tremote_name=$(clear_local_git_env; cd \"$sm_path\" && get_default_remote)\n+\t\t\tsha1=$(clear_local_git_env; cd \"$sm_path\" &&\n+\t\t\t\tgit rev-parse --verify \"${remote_name}/${branch}\") ||\n+\t\t\tdie \"$(eval_gettext \"Unable to find current ${remote_name}/${branch} revision in submodule path '\\$sm_path'\")\"\n+\t\tfi\n+\n \t\tif test \"$subsha1\" != \"$sha1\" -o -n \"$force\"\n \t\tthen\n \t\t\tsubforce=$force\ndiff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\nindex feaec6c..4975ec0 100755\n--- a/t/t7406-submodule-update.sh\n+++ b/t/t7406-submodule-update.sh\n@@ -135,6 +135,37 @@ test_expect_success 'submodule update --force forcibly checks out submodules' '\n \t)\n '\n \n+test_expect_success 'submodule update --remote should fetch upstream changes' '\n+\t(cd submodule &&\n+\t echo line4 >> file &&\n+\t git add file &&\n+\t test_tick &&\n+\t git commit -m \"upstream line4\"\n+\t) &&\n+\t(cd super &&\n+\t git submodule update --remote --force submodule &&\n+\t cd submodule &&\n+\t test \"$(git log -1 --oneline)\" = \"$(GIT_DIR=../../submodule/.git git log -1 --oneline)\"\n+\t)\n+'\n+\n+test_expect_success 'local config should override .gitmodules branch' '\n+\t(cd submodule &&\n+\t git checkout -b test-branch &&\n+\t echo line5 >> file &&\n+\t git add file &&\n+\t test_tick &&\n+\t git commit -m \"upstream line5\" &&\n+\t git checkout master\n+\t) &&\n+\t(cd super &&\n+\t git config submodule.submodule.branch test-branch &&\n+\t git submodule update --remote --force submodule &&\n+\t cd submodule &&\n+\t test \"$(git log -1 --oneline)\" = \"$(GIT_DIR=../../submodule/.git git log -1 --oneline test-branch)\"\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\n"},{"id":"205197","messageId":"2c8df95b9f4cc9ceb9d6d96d5deac22320541dd9.1355932282.git.wking@tremily.us","threadId":"32245","inReplyTo":"cover.1355932282.git.wking@tremily.us","subject":"[PATCH v8 3/3] submodule add: If --branch is given, record it in .gitmodules","fromName":"","fromEmail":"wking@tremily.us","sentAt":"2012-12-19T16:03:33Z","receivedAt":"2012-12-19T16:03:33Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"From: \"W. Trevor King\" \n\nThis allows you to easily record a submodule..branch option in\n.gitmodules when you add a new submodule. With this patch,\n\n $ git submodule add -b []\n $ git config -f .gitmodules submodule..branch \n\nreduces to\n\n $ git submodule add -b []\n\nThis means that future calls to\n\n $ git submodule update --remote ...\n\nwill get updates from the same branch that you used to initialize the\nsubmodule, which is usually what you want.\n\nSigned-off-by: W. Trevor King \n---\n Documentation/git-submodule.txt | 2 ++\n git-submodule.sh | 4 ++++\n t/t7400-submodule-basic.sh | 1 +\n 3 files changed, 7 insertions(+)\n\ndiff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt\nindex 8bf173a..b1996f1 100644\n--- a/Documentation/git-submodule.txt\n+++ b/Documentation/git-submodule.txt\n@@ -208,6 +208,8 @@ OPTIONS\n -b::\n --branch::\n \tBranch of repository to add as submodule.\n+\tThe name of the branch is recorded as `submodule..branch` in\n+\t`.gitmodules` for `update --remote`.\n \n -f::\n --force::\ndiff --git a/git-submodule.sh b/git-submodule.sh\nindex 6ae51c6..22ec5b6 100755\n--- a/git-submodule.sh\n+++ b/git-submodule.sh\n@@ -417,6 +417,10 @@ Use -f if you really want to add it.\" >&2\n \n \tgit config -f .gitmodules submodule.\"$sm_name\".path \"$sm_path\" &&\n \tgit config -f .gitmodules submodule.\"$sm_name\".url \"$repo\" &&\n+\tif test -n \"$branch\"\n+\tthen\n+\t\tgit config -f .gitmodules submodule.\"$sm_name\".branch \"$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 de7d453..2683cba 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 \"initial\" = \"$(git config -f .gitmodules submodule.submod-branch.branch)\" &&\n \t\tgit submodule init\n \t) &&\n \n-- \n1.8.0\n"},{"id":"205202","messageId":"7vhani9bul.fsf@alter.siamese.dyndns.org","threadId":"32245","inReplyTo":"2c8df95b9f4cc9ceb9d6d96d5deac22320541dd9.1355932282.git.wking@tremily.us","subject":"Re: [PATCH v8 3/3] submodule add: If --branch is given, record it in .gitmodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-19T17:43:30Z","receivedAt":"2012-12-19T17:43:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"wking@tremily.us writes:\n\n> From: \"W. Trevor King\" \n>\n> This allows you to easily record a submodule..branch option in\n> .gitmodules when you add a new submodule. With this patch,\n>\n> $ git submodule add -b []\n> $ git config -f .gitmodules submodule..branch \n>\n> reduces to\n>\n> $ git submodule add -b []\n>\n> This means that future calls to\n>\n> $ git submodule update --remote ...\n>\n> will get updates from the same branch that you used to initialize the\n> submodule, which is usually what you want.\n\nI agree that it would usually be what you want when you are using\nthe --remote option.\n\nWill replace the previous round with this. Thanks.\n"},{"id":"205322","messageId":"20121221081803.GA560@book.hvoigt.net","threadId":"32245","inReplyTo":"cover.1355932282.git.wking@tremily.us","subject":"Re: [PATCH v8 0/3] submodule update: add --remote for submodule's upstream changes","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-12-21T08:18:03Z","receivedAt":"2012-12-21T08:18:03Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"Hi,\n\nOn Wed, Dec 19, 2012 at 11:03:30AM -0500, wking@tremily.us wrote:\n> From: \"W. Trevor King\" \n> \n> Comments on v7 seem to have petered out, so here's v8. Changes since\n> v7:\n> \n> * Series based on gitster/master instead of v1.8.0.\n> * In Documentation/config.txt, restored trailing line of\n> submodule..update documentation, which I had accidentally\n> removed in v7.\n> * In Documentation/git-submodule.txt, make --no-fetch example in the\n> --remote description more general, following Phil's suggestion.\n> * In git-submodule.sh:\n> * Remove accidental \"ges\" line.\n> * Use the submodule's default remote to determine which tracking\n> branch to fetch. In v7 I'd been using the superproject's default\n> remote.\n> * In cmd_add(), use sm_name instead of sm_path to store the --branch\n> option (catching up with 73b0898).\n\nSorry, I was not able to follow the discussion that closely lately but I\nlike the outcome. For me there is nothing to change or add functionality\nwise. Thanks.\n\nCheers Heiko\n"},{"id":"205323","messageId":"20121221082033.GB560@book.hvoigt.net","threadId":"32245","inReplyTo":"3377beb925bc209d90058493b74d174db1b7aa50.1355932282.git.wking@tremily.us","subject":"Re: [PATCH v8 1/3] submodule: add get_submodule_config helper funtion","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-12-21T08:20:33Z","receivedAt":"2012-12-21T08:20:33Z","isPatch":true,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Wed, Dec 19, 2012 at 11:03:31AM -0500, wking@tremily.us wrote:\n> diff --git a/git-submodule.sh b/git-submodule.sh\n> index 2365149..263a60c 100755\n> --- a/git-submodule.sh\n> +++ b/git-submodule.sh\n> @@ -153,6 +153,32 @@ die_if_unmatched ()\n[...]\n> +get_submodule_config () {\n> +\tname=\"$1\"\n> +\toption=\"$2\"\n> +\tdefault=\"$3\"\n> +\tvalue=$(git config submodule.\"$name\".\"$option\")\n> +\tif test -z \"$value\"\n> +\tthen\n> +\t\tvalue=$(git config -f .gitmodules submodule.\"$name\".\"$option\")\n> +\tfi\n> +\tprintf '%s' \"${value:-$default}\"\n> +}\n> +\n> +\n> +#\n\nMinor nit: For all other functions we only have one newline as\nseparator.\n\nCheers Heiko\n"},{"id":"205327","messageId":"20121221110425.GE16849@odin.tremily.us","threadId":"32245","inReplyTo":"20121221082033.GB560@book.hvoigt.net","subject":"Re: [PATCH v8 1/3] submodule: add get_submodule_config helper funtion","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2012-12-21T11:04:25Z","receivedAt":"2012-12-21T11:04:25Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Dec 21, 2012 at 09:20:33AM +0100, Heiko Voigt wrote:\n> On Wed, Dec 19, 2012 at 11:03:31AM -0500, wking@tremily.us wrote:\n> > diff --git a/git-submodule.sh b/git-submodule.sh\n> > index 2365149..263a60c 100755\n> > --- a/git-submodule.sh\n> > +++ b/git-submodule.sh\n> > @@ -153,6 +153,32 @@ die_if_unmatched ()\n> [...]\n> > +get_submodule_config () {\n> > +\tname=\"$1\"\n> > +\toption=\"$2\"\n> > +\tdefault=\"$3\"\n> > +\tvalue=$(git config submodule.\"$name\".\"$option\")\n> > +\tif test -z \"$value\"\n> > +\tthen\n> > +\t\tvalue=$(git config -f .gitmodules submodule.\"$name\".\"$option\")\n> > +\tfi\n> > +\tprintf '%s' \"${value:-$default}\"\n> > +}\n> > +\n> > +\n> > +#\n> \n> Minor nit: For all other functions we only have one newline as\n> separator.\n\nI'm fine rerolling this, or Junio can make the change on my behalf, or\nit can be left as is ;).\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"}]}