{"thread":{"id":"26542","subject":"[1.8.0] Summary of the discussions","startedAt":"2011-02-18T01:02:47Z","lastAt":"2011-02-22T08:11:24Z","messageCount":14,"participants":["Junio C Hamano","Martin von Zweigbergk","Jens Lehmann","Marc Branchaud","Miles Bader","Phil Hord"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"161484","messageId":"7vwrky5f48.fsf@alter.siamese.dyndns.org","threadId":"26542","inReplyTo":null,"subject":"[1.8.0] Summary of the discussions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-18T01:02:47Z","receivedAt":"2011-02-18T01:02:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"It seems that not many things need breaking, but we will break some.\n\nHere are the ones that needed discussion and were discussed that I am\naware of, with my comments (which shouldn't be read as final decision).\n\nThe next step will be to design the migration path, and execution.\n\n * \"git branch --set-upstream \" should not be about setting the\n upstream of to the current branch.\n\n From: Jay Soffian \n Date: Tue, 1 Feb 2011 01:57:03 -0500\n Message-ID: \n\n -- summary --\n\n The current behaviour is misdesigned. It should be setting the upstream\n of the current branch to .\n\n -- comments --\n\n I agree.\n\n * \"git push\" default semantics will be \"upstream\" (renamed from\n \"tracking\"), not \"matching\".\n \n From: Matthieu Moy \n Date: Mon, 14 Feb 2011 22:57:24 +0100\n Message-ID: \n\n -- comments --\n\n Ok.\n\n * \"git merge\" without \"what to merge\" default to @{upstream}\n\n From: Junio C Hamano \n Date: Mon, 31 Jan 2011 12:50:30 -0800\n Message-ID: <7vzkqg4x2h.fsf_-_@alter.siamese.dyndns.org>\n\n -- summary --\n\n Instead of failing, \"git merge\" to behave more in line with \"git pull\".\n\n -- comments --\n\n I think this makes sense.\n\n * Unify pathspec semantics\n\n From: Junio C Hamano \n Date: Mon, 31 Jan 2011 09:07:14 -0800\n Message-ID: <7voc6x57el.fsf_-_@alter.siamese.dyndns.org>\n \n -- summary --\n\n Some commands and operations understand leading-path-components but not\n globs, while many others do. This inconsistency leads to some surprises.\n Make everybody understand globs.\n\n -- comments --\n\n This is already underway, I think.\n\n * Making more operations full-tree by default.\n\n From: Jeff King \n Date: Wed, 9 Feb 2011 18:46:21 -0500\n Subject: Re: \"git add -u\" broken in git 1.7.4?\n Message-ID: <20110209234621.GA12575@sigill.intra.peff.net>\n\n -- summary --\n\n These two commands currently affect only paths within the current\n working directory when run from a subdirectory without a pathspec:\n\n . \"add -u\"\n . \"add -A\"\n\n Make them to add everything in the working tree, from the root level,\n even when they are run from a subdirectory.\n\n The following are left as exceptions, keeping the current behaviour to\n work within the current directory given no pathspecs:\n\n . \"grep\"\n . \"archive\"\n . \"clean\"\n\n Plumbing like these are also left as exceptions.\n\n . \"ls-files\"\n . \"ls-tree\"\n\n -- comments --\n\n As long as transition plan is made carefully, I think this is fine.\n\n * Extend \"separate remote\" to tags and notes.\n\n From: Johan Herland \n Date: Mon, 07 Feb 2011 04:35:31 +0100\n Message-ID: <201102070435.31674.johan@herland.net>\n\n -- summary --\n\n Instead of using refs/remotes/origin/$branch to store copies of\n branches, which has two downsides:\n\n - HEAD as the \"primary branch pointer\" and as a branch name could\n collide;\n - tags are forced into a single global namespace. \n\n Use refs/remotes/origin/{HEAD,heads/$branch,tags/$tag} to track what\n we copy from a remote in separate namespaces.\n\n -- comments --\n\n Making this coexist with repositories created before 1.8.0 might be\n tricky, but otherwise this is fine.\n\n * \"git checkout refs/heads/\" checks out branch.\n\n From: Martin von Zweigbergk \n Date: Mon, 7 Feb 2011 06:01:51 -0500 (EST)\n Message-ID: \n\n -- summary --\n\n In addition to \"git checkout \" that names an existing branch,\n special case \"git checkout refs/heads/\" to check the branch out,\n instead of detaching HEAD at the tip of the branch. If you want to\n detach at a specific commit and wanted to disambiguate that is\n both a branch and another ref by checking out refs/heads/, your\n workflow will be broken by this change, but you can still say\n refs/heads/^0 to work it around.\n\n -- comments --\n\n I do not think this backward incompatible breakage would seriously\n hurt in practice, and if people see newbies are hurt by getting a\n detached HEAD when they check out refs/heads/, this proposal\n might be an improvement, but I have a feeling that this may be trying\n to solve a wrong problem.\n\n Why are these people _tempted_ to type refs/heads/ explicitly? It\n could be our tutorial or documentation. That might be the thing to\n fix.\n\n * \"git fetch $from $branch...\" to update tracking branches\n\n From: Thomas Rast \n Date: Mon, 31 Jan 2011 22:44:09 +0100\n Message-ID: <201101312244.10047.trast@student.ethz.ch>\n\n -- summary --\n\n Traditionally, giving explicit refspecs from the command line was a way\n to disable the tracking copy specified with \"remote..fetch\"\n configuration. A good workflow should however not rely on such a\n \"pretending that a bad update on the other side did not happen\".\n Always update tracking branches we observed with \"git fetch\".\n\n -- comments --\n\n I think this makes sense.\n\n * Moving files around in the source tree, thinning the top-level.\n\n From: Nicolas Pitre \n Date: Mon, 31 Jan 2011 15:28:37 -0500 (EST)\n Message-ID: \n\n -- summary --\n\n well not concrete enough concensus to summarize other than \"too many\n files at the top is considered ugly\".\n\n -- comments --\n\n I am not tempted to do the heavy-lifting myself; as long as the\n resulting tree looks sane, I won't object ;-)\n"},{"id":"161488","messageId":"alpine.DEB.2.00.1102172033340.14950@debian","threadId":"26542","inReplyTo":"7vwrky5f48.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Summary of the discussions","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2011-02-18T02:08:14Z","receivedAt":"2011-02-18T02:08:14Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Thu, 17 Feb 2011, Junio C Hamano wrote:\n\n> * \"git checkout refs/heads/\" checks out branch.\n> \n> From: Martin von Zweigbergk \n> Date: Mon, 7 Feb 2011 06:01:51 -0500 (EST)\n> Message-ID: \n> \n> -- summary --\n> \n> In addition to \"git checkout \" that names an existing branch,\n> special case \"git checkout refs/heads/\" to check the branch out,\n\nAt first I was going to say that I don't think special casing it\nshould be necessary. It seemed like as long as the name resolves to\nsomething like refs/heads/, the branch should be checked\nout. Then I think I realized why you said to special case it. Since\ncheckout favors branches to tags, we would first have to check if\nrefs/heads/ is valid and if it is not, check if the argument\nresolves to refs/heads/ (maybe ignoring tags called\n\"heads/\").\n\n> instead of detaching HEAD at the tip of the branch. If you want to\n> detach at a specific commit and wanted to disambiguate that is\n> both a branch and another ref by checking out refs/heads/, your\n> workflow will be broken by this change, but you can still say\n> refs/heads/^0 to work it around.\n> \n> -- comments --\n> \n> I do not think this backward incompatible breakage would seriously\n> hurt in practice, and if people see newbies are hurt by getting a\n> detached HEAD when they check out refs/heads/, this proposal\n> might be an improvement, but I have a feeling that this may be trying\n> to solve a wrong problem.\n> \n> Why are these people _tempted_ to type refs/heads/ explicitly? It\n> could be our tutorial or documentation. That might be the thing to\n> fix.\n\nIt wasn't until recently that I learned that \"git checkout\n[refs/]heads/\" (and rebase [refs/]heads/name)\ndetaches the head, so it wasn't really to try to help newbies that I\nproposed changing it. It was just that the current behavior is not\nwhat I think most people would expect.\n\n\n/Martin\n"},{"id":"161635","messageId":"4D5FF264.5050002@web.de","threadId":"26542","inReplyTo":"7vwrky5f48.fsf@alter.siamese.dyndns.org","subject":"[1.7.5] Let fetch and pull recurse into submodules when new commits are recorded","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-02-19T16:40:04Z","receivedAt":"2011-02-19T16:40:04Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 18.02.2011 02:02, schrieb Junio C Hamano:\n> It seems that not many things need breaking, but we will break some.\n> \n> Here are the ones that needed discussion and were discussed that I am\n> aware of, with my comments (which shouldn't be read as final decision).\n\nSorry for not having posted this earlier:\n\nProposal:\nAdd a new \"on-demand\" mode to fetch and pull and make it the default.\n\nWhen using the new \"on-demand\" mode every time new commits are fetched\nin the superproject they will be parsed for submodule commits. If these\ncommits aren't present in a populated submodule, run \"git fetch\" inside\nthat submodule. (Also see this thread for an in depth discussion:\nhttp://article.gmane.org/gmane.comp.version-control.git/158979/ )\n\nAdditionally change \"git submodule update\" to only then run fetch in a\nsubmodule when the commit it wants to check out is not already present\nthere.\n\nThis behavior can be configured per submodule, per repo and globally.\n\nAdvantages:\n* Disconnected operation. Right now it is really easy to forget to fetch\n all submodules before you get on a plane, possibly leaving you unable\n to check out certain revisions.\n* \"git diff --submodule\" (which is used by git gui and gitk) needs those\n submodule commits to provide meaningful output\n* \"git merge\" needs them to be able to merge submodule commits\n* This is the least surprising behavior for new submodule users\n(The upcoming recursive checkout will rely on the commits being present\ntoo)\n\nRisks:\nPeople might be annoyed by the extra time it takes to fetch the submodules\nwhen they only expect the superproject to be fetched. Others might be\nsurprised that \"git submodule update\" doesn't do a fetch anymore.\n\nMigration plan:\nAnnounce the change in behavior and document how to easily configure the\nold behavior when wanted and enable this functionality in 1.7.5.\n"},{"id":"161636","messageId":"4D5FF6E7.8090104@web.de","threadId":"26542","inReplyTo":"7vwrky5f48.fsf@alter.siamese.dyndns.org","subject":"[1.8.0] Recursively checkout, merge and reset populated submodules","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-02-19T16:59:19Z","receivedAt":"2011-02-19T16:59:19Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Proposal:\nWhen switching branches, merging or resetting the work tree of\npopulated submodules should be checked out too according to the\ncommit recorded in the superproject. Make this the default for\nporcelain and optional for plumbing.\n\nThe same safety precautions that are used for files in the\nsuperproject apply to the changes present in the submodules,\nno local modifications may be overwritten unless -f is used.\nWhen the \"update\" config option is set to \"merge\" or \"rebase\"\nthe submodule will be left unchanged.\n\nThe \"update\" config option will learn a new value \"none\" to let\nthe user turn off this behavior for single submodules. A global\nconfig option and the command line parameter \"--recurse-submodules\"\nwill also be added. This change will remove the need to call \"git\nsubmodule update\" for all populated submodules (except those who\nuse the \"update=merge\" or \"update=rebase\" configuration settings).\n\nAdvantages:\n* This makes submodules behave like the files in the superproject.\n Every time the work tree of the superproject changes, the work\n trees of the populated submodules are updated accordingly.\n* This is the least surprising behavior for new submodule users.\n\nRisks:\nThe commands might run longer, for those users who use submodules\nto gain performance by putting large and/or many files into\nsubmodules this may be unacceptable. Also people might be\nsurprised by submodule work trees changing without explicitly\ninvoking \"git submodule update\". These commands will now fail in\nthe presence of changed submodules where they would have\nsucceeded before.\n\nMigration plan:\nAnnounce the change in behavior and document how to easily configure\nthe old behavior when needed and enable this functionality in 1.8.0.\n"},{"id":"161736","messageId":"7vd3mnmc9q.fsf@alter.siamese.dyndns.org","threadId":"26542","inReplyTo":"4D5FF6E7.8090104@web.de","subject":"Re: [1.8.0] Recursively checkout, merge and reset populated submodules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-20T06:49:05Z","receivedAt":"2011-02-20T06:49:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann writes:\n\n> Risks:\n> The commands might run longer, for those users who use submodules\n> to gain performance by putting large and/or many files into\n> submodules this may be unacceptable.\n\nNobody would object to make this facility available via config, I think,\nbut I suspect that it is way too premature to decide which way should\neventually be the default at this point.\n\nMy recommendation is to ease this in as an optional feature you can easily\nturn on with a config, let people try it for a few release cycles and then\nif we reach the concensus that this should be on by the default, start the\nusual \"warn and tell how to keep the old behavior\" one cycle before 1.8.0\n(or 1.9.0 if we end up not having enough cycles before 1.8.0).\n"},{"id":"161819","messageId":"4D6280F2.5000409@xiplink.com","threadId":"26542","inReplyTo":"4D5FF264.5050002@web.de","subject":"Re: [1.7.5] Let fetch and pull recurse into submodules when new commits are recorded","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-02-21T15:12:50Z","receivedAt":"2011-02-21T15:12:50Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-02-19 11:40 AM, Jens Lehmann wrote:\n> Am 18.02.2011 02:02, schrieb Junio C Hamano:\n>> It seems that not many things need breaking, but we will break some.\n>>\n>> Here are the ones that needed discussion and were discussed that I am\n>> aware of, with my comments (which shouldn't be read as final decision).\n> \n> Sorry for not having posted this earlier:\n> \n> Proposal:\n> Add a new \"on-demand\" mode to fetch and pull and make it the default.\n> \n> When using the new \"on-demand\" mode every time new commits are fetched\n> in the superproject they will be parsed for submodule commits. If these\n> commits aren't present in a populated submodule, run \"git fetch\" inside\n> that submodule. (Also see this thread for an in depth discussion:\n> http://article.gmane.org/gmane.comp.version-control.git/158979/ )\n> \n> Additionally change \"git submodule update\" to only then run fetch in a\n> submodule when the commit it wants to check out is not already present\n> there.\n> \n> This behavior can be configured per submodule, per repo and globally.\n> \n> Advantages:\n> * Disconnected operation. Right now it is really easy to forget to fetch\n> all submodules before you get on a plane, possibly leaving you unable\n> to check out certain revisions.\n\nI support the proposal, but just to be clear I'd rephrase that advantage as:\n\nDisconnected operation. Right now it is really easy to forget to update\npopulated submodules before you get on a plane, possibly leaving you unable\nto check out certain revisions.\n\n(Obviously, I think the only-works-on-already-populated-submodules part is\nvery important.)\n\n\t\tM.\n"},{"id":"161824","messageId":"4D628F21.3050808@xiplink.com","threadId":"26542","inReplyTo":"4D5FF6E7.8090104@web.de","subject":"Re: [1.8.0] Recursively checkout, merge and reset populated submodules","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-02-21T16:13:21Z","receivedAt":"2011-02-21T16:13:21Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-02-19 11:59 AM, Jens Lehmann wrote:\n> Proposal:\n> When switching branches, merging or resetting the work tree of\n> populated submodules should be checked out too according to the\n> commit recorded in the superproject. Make this the default for\n> porcelain and optional for plumbing.\n> \n> The same safety precautions that are used for files in the\n> superproject apply to the changes present in the submodules,\n> no local modifications may be overwritten unless -f is used.\n> When the \"update\" config option is set to \"merge\" or \"rebase\"\n> the submodule will be left unchanged.\n> \n> The \"update\" config option will learn a new value \"none\" to let\n> the user turn off this behavior for single submodules. A global\n> config option and the command line parameter \"--recurse-submodules\"\n> will also be added. This change will remove the need to call \"git\n> submodule update\" for all populated submodules (except those who\n> use the \"update=merge\" or \"update=rebase\" configuration settings).\n\nA big +1 from me for all the submodule work -- thanks Jens!\n\nCould you clarify the proposal a bit? A few questions occurred to me as I\nread it:\n\n* How is the initial set of populated submodules set up during a clone\noperation? Specifically, how would the origin repo specify which submodules\nto recursively clone? (My understanding is that the origin's .gitmodules\nfile, as it exists in whatever branch is being cloned, would specify\nsubmodule..update values, and those would drive the recursion.)\n\n* Which values of submodule..update would enable/disable recursion\nduring a clone? Would just \"checkout\" enable it, or should \"merge\" and\n\"rebase\" also trigger recursion when cloning?\n\n* What happens when a clone's user manually populates one of the other\nsubmodules that wasn't part of the initial set? Automatic recursion into\nthis newly-populated submodule is controlled by the setting of the global\nrecurse-submodules option, right?\n\n* What are the possible values of the global recurse-submodules option?\nHere's what I came up with:\n\n all -- Always recurse\n populated -- Only recurse into *all* currently-populated submodules\n respect -- Respect each submodule's \"update\" option (better name?)\n none -- Never recurse\n\n* What will happen when I start checked out at commit A, with a populated\nsubmodule, then check out commit B where that submodule doesn't exist, then\nreturn to commit A? How will whatever recursion settings I had at the start\nbe preserved?\n\n\t\tM.\n"},{"id":"161829","messageId":"4D62A31B.7060900@web.de","threadId":"26542","inReplyTo":"4D6280F2.5000409@xiplink.com","subject":"Re: [1.7.5] Let fetch and pull recurse into submodules when new commits are recorded","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-02-21T17:38:35Z","receivedAt":"2011-02-21T17:38:35Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 21.02.2011 16:12, schrieb Marc Branchaud:\n> On 11-02-19 11:40 AM, Jens Lehmann wrote:\n>> Proposal:\n>> Add a new \"on-demand\" mode to fetch and pull and make it the default.\n>>\n>> When using the new \"on-demand\" mode every time new commits are fetched\n>> in the superproject they will be parsed for submodule commits. If these\n>> commits aren't present in a populated submodule, run \"git fetch\" inside\n>> that submodule. (Also see this thread for an in depth discussion:\n>> http://article.gmane.org/gmane.comp.version-control.git/158979/ )\n>>\n>> Additionally change \"git submodule update\" to only then run fetch in a\n>> submodule when the commit it wants to check out is not already present\n>> there.\n>>\n>> This behavior can be configured per submodule, per repo and globally.\n>>\n>> Advantages:\n>> * Disconnected operation. Right now it is really easy to forget to fetch\n>> all submodules before you get on a plane, possibly leaving you unable\n>> to check out certain revisions.\n> \n> I support the proposal, but just to be clear I'd rephrase that advantage as:\n> \n> Disconnected operation. Right now it is really easy to forget to update\n> populated submodules before you get on a plane, possibly leaving you unable\n> to check out certain revisions.\n> \n> (Obviously, I think the only-works-on-already-populated-submodules part is\n> very important.)\n\nThanks and yes, that is exactly what this proposal is about.\n"},{"id":"161831","messageId":"4D62AF46.8030508@web.de","threadId":"26542","inReplyTo":"4D628F21.3050808@xiplink.com","subject":"Re: [1.8.0] Recursively checkout, merge and reset populated submodules","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-02-21T18:30:30Z","receivedAt":"2011-02-21T18:30:30Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 21.02.2011 17:13, schrieb Marc Branchaud:\n> On 11-02-19 11:59 AM, Jens Lehmann wrote:\n> Could you clarify the proposal a bit? A few questions occurred to me as I\n> read it:\n> \n> * How is the initial set of populated submodules set up during a clone\n> operation? Specifically, how would the origin repo specify which submodules\n> to recursively clone? (My understanding is that the origin's .gitmodules\n> file, as it exists in whatever branch is being cloned, would specify\n> submodule..update values, and those would drive the recursion.)\n\nThat is what I have in mind. I tend towards updating all populated\nsubmodules on local operations (like switching branches, merging and so\non) unless configured otherwise, while for cloning me thinks an explicit\n\"submodule..update=checkout\" or such should be necessary.\n\n(But please note that cloning was not part of my proposal, I was only\ntalking about the local operations for now ;-)\n\n> * Which values of submodule..update would enable/disable recursion\n> during a clone? Would just \"checkout\" enable it, or should \"merge\" and\n> \"rebase\" also trigger recursion when cloning?\n\n\"merge\" and \"rebase\" could do that too, but wait: That would make it\nimpossible to say \"I want his submodule merged/rebased but *not* cloned\"\n... Hmm, good point, I'll have to think about that some more ...\n\n> * What happens when a clone's user manually populates one of the other\n> submodules that wasn't part of the initial set? Automatic recursion into\n> this newly-populated submodule is controlled by the setting of the global\n> recurse-submodules option, right?\n\nThere will be a global and a per-submodule configuration. But yes, if the\n.git/config or .gitmodules don't specify anything for this submodule the\nglobal config will kick in. And if that isn't set I imagine that porcelain\nby default will recurse into populated submodules while plumbing won't.\n\n> * What are the possible values of the global recurse-submodules option?\n> Here's what I came up with:\n> \n> all -- Always recurse\n> populated -- Only recurse into *all* currently-populated submodules\n> respect -- Respect each submodule's \"update\" option (better name?)\n> none -- Never recurse\n\nFor porcelain I tend to unify \"all\", \"populated\" and \"respect\": recurse\ninto all populated submodules unless configured otherwise (\"all\" seems\nkind of superfluous, as I would respect the users choice not to populate\na submodule after the initial clone). But for plumbing a \"respect\" option\nmakes sense, using it could tell it to use the same defaults and config\nthat porcelain uses to make writing scripts easier.\n\n> * What will happen when I start checked out at commit A, with a populated\n> submodule, then check out commit B where that submodule doesn't exist, then\n> return to commit A? How will whatever recursion settings I had at the start\n> be preserved?\n\nI think the same option that controls the cloning of submodules should\ncontrol whether a new submodule will be populated or not. For submodules\nthat already existed despite that it might be nice to remember and respect\nthe users choice and restore it if it existed before.\n\n\nMaybe I'll have to mention the next steps not covered by my proposal:\n\n2) Checkout submodules on clone\n\n3) Move .git-Directories into the .git of the superproject (this will\n enable us to delete and recreate submodules without cloning again or\n loosing local branches and/or tags).\n\n\nAfter thinking about it again I now tend to agree with Junio that we should\nbring in the functionality without enabling it by default first and then\nlater decide if and to what we change the defaults. So I draw back this\nproposal and will post it again when all three steps are implemented and can\nbe properly evaluated.\n\nThanks both for your feedback!\n"},{"id":"161836","messageId":"4D62C385.90204@xiplink.com","threadId":"26542","inReplyTo":"4D62AF46.8030508@web.de","subject":"Re: [1.8.0] Recursively checkout, merge and reset populated submodules","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-02-21T19:56:53Z","receivedAt":"2011-02-21T19:56:53Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-02-21 01:30 PM, Jens Lehmann wrote:\n> Am 21.02.2011 17:13, schrieb Marc Branchaud:\n>> On 11-02-19 11:59 AM, Jens Lehmann wrote:\n>> Could you clarify the proposal a bit? A few questions occurred to me as I\n>> read it:\n>>\n>> * How is the initial set of populated submodules set up during a clone\n>> operation? Specifically, how would the origin repo specify which submodules\n>> to recursively clone? (My understanding is that the origin's .gitmodules\n>> file, as it exists in whatever branch is being cloned, would specify\n>> submodule..update values, and those would drive the recursion.)\n> \n> That is what I have in mind. I tend towards updating all populated\n> submodules on local operations (like switching branches, merging and so\n> on) unless configured otherwise, while for cloning me thinks an explicit\n> \"submodule..update=checkout\" or such should be necessary.\n> \n> (But please note that cloning was not part of my proposal, I was only\n> talking about the local operations for now ;-)\n\nOoops, sorry for jumping the gun! I figured that since clone normally does a\ncheckout that this would have to be worked out as part of the proposal.\n\n>> * Which values of submodule..update would enable/disable recursion\n>> during a clone? Would just \"checkout\" enable it, or should \"merge\" and\n>> \"rebase\" also trigger recursion when cloning?\n> \n> \"merge\" and \"rebase\" could do that too, but wait: That would make it\n> impossible to say \"I want his submodule merged/rebased but *not* cloned\"\n> ... Hmm, good point, I'll have to think about that some more ...\n> \n>> * What happens when a clone's user manually populates one of the other\n>> submodules that wasn't part of the initial set? Automatic recursion into\n>> this newly-populated submodule is controlled by the setting of the global\n>> recurse-submodules option, right?\n> \n> There will be a global and a per-submodule configuration. But yes, if the\n> .git/config or .gitmodules don't specify anything for this submodule the\n> global config will kick in. And if that isn't set I imagine that porcelain\n> by default will recurse into populated submodules while plumbing won't.\n> \n>> * What are the possible values of the global recurse-submodules option?\n>> Here's what I came up with:\n>>\n>> all -- Always recurse\n>> populated -- Only recurse into *all* currently-populated submodules\n>> respect -- Respect each submodule's \"update\" option (better name?)\n>> none -- Never recurse\n> \n> For porcelain I tend to unify \"all\", \"populated\" and \"respect\": recurse\n> into all populated submodules unless configured otherwise (\"all\" seems\n> kind of superfluous, as I would respect the users choice not to populate\n> a submodule after the initial clone).\n\nA lot of what I'm confused about is how git would distinguish between 2 things:\n\n - How the user specifies submodule recursion within a local repo.\n\n - How a repo specifies initial submodule recursion for clones.\n\nI'm happy to wait for your follow-up work to discuss this. Cloning aside,\nwhat you're proposing looks good to me.\n\n> But for plumbing a \"respect\" option\n> makes sense, using it could tell it to use the same defaults and config\n> that porcelain uses to make writing scripts easier.\n\nI haven't thought enough about plumbing to tell if it makes sense to\nconfigure plumbing behavior explicitly. But at first glance it seems odd...\n\n>> * What will happen when I start checked out at commit A, with a populated\n>> submodule, then check out commit B where that submodule doesn't exist, then\n>> return to commit A? How will whatever recursion settings I had at the start\n>> be preserved?\n> \n> I think the same option that controls the cloning of submodules should\n> control whether a new submodule will be populated or not. For submodules\n> that already existed despite that it might be nice to remember and respect\n> the users choice and restore it if it existed before.\n\nSo, .gitmodules initially controls recursion. When a submodule gets\npopulated, it gets an entry in .git/config which then determines the\nrecursion behavior from then on. Changing branches might change .gitmodules,\nbut anything in .git/config will persist so any customizations the user makes\nwill also persist.\n\nSounds good to me!\n\n\t\tM.\n"},{"id":"161840","messageId":"4D62ED38.7070408@web.de","threadId":"26542","inReplyTo":"4D62C385.90204@xiplink.com","subject":"Re: [1.8.0] Recursively checkout, merge and reset populated submodules","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-02-21T22:54:48Z","receivedAt":"2011-02-21T22:54:48Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 21.02.2011 20:56, schrieb Marc Branchaud:\n> On 11-02-21 01:30 PM, Jens Lehmann wrote:\n>> Am 21.02.2011 17:13, schrieb Marc Branchaud:\n> A lot of what I'm confused about is how git would distinguish between 2 things:\n> \n> - How the user specifies submodule recursion within a local repo.\n> \n> - How a repo specifies initial submodule recursion for clones.\n> \n> I'm happy to wait for your follow-up work to discuss this. Cloning aside,\n> what you're proposing looks good to me.\n\nCool. When I'm done with the local repo stuff I'll continue working on the\ncloning part, so stay tuned for further discussions on that topic :-)\n\n>> But for plumbing a \"respect\" option\n>> makes sense, using it could tell it to use the same defaults and config\n>> that porcelain uses to make writing scripts easier.\n> \n> I haven't thought enough about plumbing to tell if it makes sense to\n> configure plumbing behavior explicitly. But at first glance it seems odd...\n\nPlumbing shouldn't care about user config by default because the aim is to\nhave predictable behavior. But e.g. git gui, which is using plumbing under\nthe hood to do the actual checkout, should honor user configuration and\nporcelain defaults (because it is percieved by the user as being porcelain\nitself). So git gui would benefit from being able to simply tell plumbing\n\"behave like you were porcelain\" through an option instead of coding\nrecursion, user configuration and the safety checks needed before checkout\nitself. And this would avoid code duplication too.\n\n>>> * What will happen when I start checked out at commit A, with a populated\n>>> submodule, then check out commit B where that submodule doesn't exist, then\n>>> return to commit A? How will whatever recursion settings I had at the start\n>>> be preserved?\n>>\n>> I think the same option that controls the cloning of submodules should\n>> control whether a new submodule will be populated or not. For submodules\n>> that already existed despite that it might be nice to remember and respect\n>> the users choice and restore it if it existed before.\n> \n> So, .gitmodules initially controls recursion. When a submodule gets\n> populated, it gets an entry in .git/config which then determines the\n> recursion behavior from then on. Changing branches might change .gitmodules,\n> but anything in .git/config will persist so any customizations the user makes\n> will also persist.\n\nYes. Upstream can give sane defaults but the user has the last word.\n\n> Sounds good to me!\n\nGreat to hear!\n"},{"id":"161852","messageId":"87ei70riw1.fsf@catnip.gol.com","threadId":"26542","inReplyTo":"4D62ED38.7070408@web.de","subject":"Re: [1.8.0] Recursively checkout, merge and reset populated submodules","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-22T00:51:42Z","receivedAt":"2011-02-22T00:51:42Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Jens Lehmann writes:\n>> So, .gitmodules initially controls recursion. When a submodule gets\n>> populated, it gets an entry in .git/config which then determines the\n>> recursion behavior from then on. Changing branches might change .gitmodules,\n>> but anything in .git/config will persist so any customizations the user makes\n>> will also persist.\n>\n> Yes. Upstream can give sane defaults but the user has the last word.\n\nIf .git/config entries are created _automatically_ based on the initial\n.gitmodules, doesn't that means it will cease to respect the upstream\ndefaults in the case where .gitmodules changes, even if the user didn't\nactually change anything himself...?\n\n-Miles\n\n-- \n`The suburb is an obsolete and contradictory form of human settlement'\n"},{"id":"161855","messageId":"4D632029.7040501@cisco.com","threadId":"26542","inReplyTo":"87ei70riw1.fsf@catnip.gol.com","subject":"Re: [1.8.0] Recursively checkout, merge and reset populated submodules","fromName":"Phil Hord","fromEmail":"hordp@cisco.com","sentAt":"2011-02-22T02:32:09Z","receivedAt":"2011-02-22T02:32:09Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On 02/21/2011 07:51 PM, Miles Bader wrote:\n> Jens Lehmann writes:\n>>> >> So, .gitmodules initially controls recursion. When a submodule gets\n>>> >> populated, it gets an entry in .git/config which then determines the\n>>> >> recursion behavior from then on. Changing branches might change .gitmodules,\n>>> >> but anything in .git/config will persist so any customizations the user makes\n>>> >> will also persist.\n>> >\n>> > Yes. Upstream can give sane defaults but the user has the last word.\n> If .git/config entries are created _automatically_ based on the initial\n> .gitmodules, doesn't that means it will cease to respect the upstream\n> defaults in the case where .gitmodules changes, even if the user didn't\n> actually change anything himself...?\n\nAlso consider that the .gitmodules' \"upstream defaults\" may have many\nchanges\nwithin the existing repository. So, $(git checkout foo) will load some\n\"defaults\" and\n$(git checkout bar) may load different \"defaults\". I guess the defaults\ncan be migrated\ninto .git/config using $(git submodule init)...?\n\nPhil\n"},{"id":"161866","messageId":"4D636FAC.3000105@web.de","threadId":"26542","inReplyTo":"4D632029.7040501@cisco.com","subject":"Re: [1.8.0] Recursively checkout, merge and reset populated submodules","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2011-02-22T08:11:24Z","receivedAt":"2011-02-22T08:11:24Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 22.02.2011 03:32, schrieb Phil Hord:\n> On 02/21/2011 07:51 PM, Miles Bader wrote:\n>> Jens Lehmann writes:\n>>>>>> So, .gitmodules initially controls recursion. When a submodule gets\n>>>>>> populated, it gets an entry in .git/config which then determines the\n>>>>>> recursion behavior from then on. Changing branches might change .gitmodules,\n>>>>>> but anything in .git/config will persist so any customizations the user makes\n>>>>>> will also persist.\n>>>>\n>>>> Yes. Upstream can give sane defaults but the user has the last word.\n>> If .git/config entries are created _automatically_ based on the initial\n>> .gitmodules, doesn't that means it will cease to respect the upstream\n>> defaults in the case where .gitmodules changes, even if the user didn't\n>> actually change anything himself...?\n\nYes, unfortunately that is the current behavior of the git-submodule\ncommand, it copies the \"update\" entry into .git/config on init (but\nnot on sync, so it is not updated then if it changed). The other\nsubmodule flags (\"ignore\" & \"fetchRecurseSubmodules\" don't show that\nbehavior, the user has to copy them herself to override upstream\nsettings). I'm in favor of removing that copy and using the setting\nfrom .gitmodules when \"update\" is not found in .git/config, but this\nchanges behavior. But maybe that is a worthwhile change for 1.8.0\npreparing for the things to come?\n\n> Also consider that the .gitmodules' \"upstream defaults\" may have many\n> changes\n> within the existing repository. So, $(git checkout foo) will load some\n> \"defaults\" and\n> $(git checkout bar) may load different \"defaults\".\n\nYes, and that is a feature. E.g. when you have a \"working on foo\"\nbranch you can set the \"fetchRecurseSubmodules\" to \"yes\" there because\nyou want to get all commits in the submodule to be able to commit some\nnew ones in the superproject. But in every other branch setting that to\n\"on-demand\" will suffice.\n\n> I guess the defaults\n> can be migrated\n> into .git/config using $(git submodule init)...?\n\nNot with \"git submodule init\", as they then would be set in stone from\nthe beginning. But I can imagine a \"git submodule config \"\nhelper program, which copies the setting into .git/config or updates\nit there when wanted.\n"}]}