{"thread":{"id":"40763","subject":"Allow git alias to override existing Git commands","startedAt":"2015-11-10T16:31:21Z","lastAt":"2015-11-11T19:44:43Z","messageCount":13,"participants":["Jeremy Morton","Stefan Beller","Jens Lehmann","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"273151","messageId":"56421BD9.5060501@game-point.net","threadId":"40763","inReplyTo":null,"subject":"Allow git alias to override existing Git commands","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2015-11-10T16:31:21Z","receivedAt":"2015-11-10T16:31:21Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"It's recently come to my attention that the \"git alias\" config \nfunctionality ignores all aliases that would override existing Git \ncommands. This seems like a bad idea to me.\n\nFor example, I wanted to setup \"git clone\" to automatically act as \n\"git clone --recursive\". Sure I could do it in the shell, but it's \nmore of a pain - any tutorial I set up about doing it would have to \nworry about what shell the user was using - and if you're going to \nmake that argument, why have \"git alias\" at all? It can all be done \nfrom the shell.\n\nObviously I could also use a different alias that wasn't an existing \nGit command for this behaviour, but that would rather defeat the \npoint: I want \"git clone\" to have different functionality. If I \nremembered to use a different Git command, I might as well remember to \ntype \"git clone --recursive\". Also, if a future Git command were \nintroduced with the same name as my alias, my alias's functionality \nwould suddenly be ignored, giving unexpected behaviour.\n\nThe reasoning behind this that it's \"to avoid confusion and troubles \nwith script usage\" seems to be at odds with the general Git mentality \nthat the user is given lots of power, and if they screw it up it's \nbasically just user error. For example, Git doesn't *have* to allow \nyou to rebase. It's a potentially dangerous operation, so why is it \nallowed? It might \"cause confusion and troubles\".\n\nOn the other hand, by disallowing the overriding of existing Git \ncommands through aliases you are preventing a lot of useful \nfunctionality that those aliases might be used for.\n\nSo I think you should either allow Git aliases to override existing \nGit commands by default, or at least provide a config option that \nallows the user to say that this should happen.\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"273154","messageId":"CAGZ79kZxQWVMe3N1ti8npyp9_4DUPAVy9Uk5a75Jwh3Eud2eZQ@mail.gmail.com","threadId":"40763","inReplyTo":"56421BD9.5060501@game-point.net","subject":"Re: Allow git alias to override existing Git commands","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-11-10T18:12:45Z","receivedAt":"2015-11-10T18:12:45Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton wrote:\n> It's recently come to my attention that the \"git alias\" config functionality\n> ignores all aliases that would override existing Git commands. This seems\n> like a bad idea to me.\n\nThis ensures that the plumbing commands always work as expected.\nAs scripts *should* only use plumbing commands, the scripts should\nwork with high probability despite all the crazy user configuration/aliases.\n\n>\n> For example, I wanted to setup \"git clone\" to automatically act as \"git\n> clone --recursive\". Sure I could do it in the shell, but it's more of a\n> pain - any tutorial I set up about doing it would have to worry about what\n> shell the user was using - and if you're going to make that argument, why\n> have \"git alias\" at all? It can all be done from the shell.\n\nI think the git way for your example would be to configure git to include that\noption by default, something like\n\n git config --global submodules.recursiveClone yes\n\nthough I was skimming through the man page of git config and did not find\nthat option there. I guess it's missing.\n\n\n>\n> Obviously I could also use a different alias that wasn't an existing Git\n> command for this behaviour, but that would rather defeat the point: I want\n> \"git clone\" to have different functionality. If I remembered to use a\n> different Git command, I might as well remember to type \"git clone\n> --recursive\". Also, if a future Git command were introduced with the same\n> name as my alias, my alias's functionality would suddenly be ignored, giving\n> unexpected behaviour.\n>\n> The reasoning behind this that it's \"to avoid confusion and troubles with\n> script usage\" seems to be at odds with the general Git mentality that the\n> user is given lots of power, and if they screw it up it's basically just\n> user error.\n\nFor scripting the plumbing commands are recommended. The plumbing commands\nusually cannot be configured to do crazy stuff.\n\n> For example, Git doesn't *have* to allow you to rebase. It's a\n> potentially dangerous operation, so why is it allowed? It might \"cause\n> confusion and troubles\".\n\nGit doesn't try to hide its complexity from the users. And if a user would need\nto hack their way around to get rebasing working again, might also\n\"cause confusion\nand troubles\".\n\n>\n> On the other hand, by disallowing the overriding of existing Git commands\n> through aliases you are preventing a lot of useful functionality that those\n> aliases might be used for.\n>\n> So I think you should either allow Git aliases to override existing Git\n> commands by default, or at least provide a config option that allows the\n> user to say that this should happen.\n>\n> --\n> Best regards,\n> Jeremy Morton (Jez)\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"273156","messageId":"56424DDE.2030808@game-point.net","threadId":"40763","inReplyTo":"CAGZ79kZxQWVMe3N1ti8npyp9_4DUPAVy9Uk5a75Jwh3Eud2eZQ@mail.gmail.com","subject":"Re: Allow git alias to override existing Git commands","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2015-11-10T20:04:46Z","receivedAt":"2015-11-10T20:04:46Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 10/11/2015 18:12, Stefan Beller wrote:\n> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton wrote:\n>> It's recently come to my attention that the \"git alias\" config functionality\n>> ignores all aliases that would override existing Git commands. This seems\n>> like a bad idea to me.\n>\n> This ensures that the plumbing commands always work as expected.\n> As scripts *should* only use plumbing commands, the scripts should\n> work with high probability despite all the crazy user configuration/aliases.\n>\n\nI just disagree with this. If a user chooses to override their Git \ncommands, it's their problem. Why should Git care about this? It \nshould provide the user with the option to do this, and if the user \nruins scripts because of their aliases, it is not Git's problem. What \nyou are doing is taking away power from users to use git aliases to \ntheir full potential.\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"273159","messageId":"CAGZ79kZ9zw+Lf4P7EFxZ6Q7PK7GrTFZokPgtEJ-Gcdp3pHkurA@mail.gmail.com","threadId":"40763","inReplyTo":"56424DDE.2030808@game-point.net","subject":"Re: Allow git alias to override existing Git commands","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-11-10T20:22:56Z","receivedAt":"2015-11-10T20:22:56Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Nov 10, 2015 at 12:04 PM, Jeremy Morton wrote:\n> On 10/11/2015 18:12, Stefan Beller wrote:\n>>\n>> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton\n>> wrote:\n>>>\n>>> It's recently come to my attention that the \"git alias\" config\n>>> functionality\n>>> ignores all aliases that would override existing Git commands. This\n>>> seems\n>>> like a bad idea to me.\n>>\n>>\n>> This ensures that the plumbing commands always work as expected.\n>> As scripts *should* only use plumbing commands, the scripts should\n>> work with high probability despite all the crazy user\n>> configuration/aliases.\n>>\n>\n> I just disagree with this. If a user chooses to override their Git\n> commands, it's their problem. Why should Git care about this?\n\nBecause we still have some Git commands (i.e. git submodule) as scripts,\nwhich would break if the user aliases plumbing commands. This is unexpected,\nso should be avoided. Maybe we could allow aliasing porcelain commands though,\nbut that is extra effort, which nobody looked into yet.\n\n> It should\n> provide the user with the option to do this, and if the user ruins scripts\n> because of their aliases, it is not Git's problem. What you are doing is\n> taking away power from users to use git aliases to their full potential.\n\nYeah, no user asked for that power I guess, you're the first. :)\n\nAs from your initial email, I think before trying to overriding 'clone'\nto 'clone --recurse' you'd rather want to have a globally configured\noption to recurse by default on invocation of 'clone'.\nThat sounds saner to me at least.\n\nStefan\n"},{"id":"273162","messageId":"5642685F.9070405@web.de","threadId":"40763","inReplyTo":"CAGZ79kZxQWVMe3N1ti8npyp9_4DUPAVy9Uk5a75Jwh3Eud2eZQ@mail.gmail.com","subject":"Re: Allow git alias to override existing Git commands","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2015-11-10T21:57:51Z","receivedAt":"2015-11-10T21:57:51Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 10.11.2015 um 19:12 schrieb Stefan Beller:\n> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton wrote:\n>> It's recently come to my attention that the \"git alias\" config functionality\n>> ignores all aliases that would override existing Git commands. This seems\n>> like a bad idea to me.\n>\n> This ensures that the plumbing commands always work as expected.\n> As scripts *should* only use plumbing commands, the scripts should\n> work with high probability despite all the crazy user configuration/aliases.\n\nExactly.\n\n>> For example, I wanted to setup \"git clone\" to automatically act as \"git\n>> clone --recursive\". Sure I could do it in the shell, but it's more of a\n>> pain - any tutorial I set up about doing it would have to worry about what\n>> shell the user was using - and if you're going to make that argument, why\n>> have \"git alias\" at all? It can all be done from the shell.\n>\n> I think the git way for your example would be to configure git to include that\n> option by default, something like\n>\n> git config --global submodules.recursiveClone yes\n>\n> though I was skimming through the man page of git config and did not find\n> that option there. I guess it's missing.\n\nWe thought about adding such a config option, but I believe that would\nfall a bit short. If I want to have recursive clone I also want to init\nall those submodules appearing in later fetches too (otherwise the end\nresult would depend on whether you cloned before or after a submodule\nwas added upstream, which is confusing). Extra points for populating\nthe submodule in my work tree when switching to a commit containing\nthe new submodule.\n\nSo what about a \"submodule.autoupdate\" config option? If set to true,\nall submodules not marked \"update=none\" would automatically be fetched\nand inited by fetch (and thus clone too) and then checked out (with my\nrecursive update changes) in every work tree manipulating command\n(again including clone).\n\nUsers who only want the submodules to be present in the work tree but\nnot automagically updated could set \"submodule.autoupdate=clone\" to\navoid the extra cost of updating the work tree every time they switch\nbetween commits. Now that Heiko's config-from-commit changes are in\nmaster, someone could easily add that to fetch and clone as the first\nstep. We could also teach clone to make \"submodule.autoupdate=true\"\nimply --recursive and execute the \"git submodule\" command to update\nthe work tree as a first step until the recursive checkout patches\nare ready.\n\nDoes that make sense?\n"},{"id":"273165","messageId":"CAGZ79ka_RACVEDJBU8_5UsEyUBvQgKTh7FbvSoHxpMjDYDgPOw@mail.gmail.com","threadId":"40763","inReplyTo":"5642685F.9070405@web.de","subject":"Re: Allow git alias to override existing Git commands","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-11-10T22:49:42Z","receivedAt":"2015-11-10T22:49:42Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Nov 10, 2015 at 1:57 PM, Jens Lehmann wrote:\n> Am 10.11.2015 um 19:12 schrieb Stefan Beller:\n>>\n>> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton \n>> wrote:\n>>>\n>>> It's recently come to my attention that the \"git alias\" config\n>>> functionality\n>>> ignores all aliases that would override existing Git commands. This\n>>> seems\n>>> like a bad idea to me.\n>>\n>>\n>> This ensures that the plumbing commands always work as expected.\n>> As scripts *should* only use plumbing commands, the scripts should\n>> work with high probability despite all the crazy user\n>> configuration/aliases.\n>\n>\n> Exactly.\n>\n>>> For example, I wanted to setup \"git clone\" to automatically act as \"git\n>>> clone --recursive\". Sure I could do it in the shell, but it's more of a\n>>> pain - any tutorial I set up about doing it would have to worry about\n>>> what\n>>> shell the user was using - and if you're going to make that argument, why\n>>> have \"git alias\" at all? It can all be done from the shell.\n>>\n>>\n>> I think the git way for your example would be to configure git to include\n>> that\n>> option by default, something like\n>>\n>> git config --global submodules.recursiveClone yes\n>>\n>> though I was skimming through the man page of git config and did not find\n>> that option there. I guess it's missing.\n>\n>\n> We thought about adding such a config option, but I believe that would\n> fall a bit short. If I want to have recursive clone I also want to init\n> all those submodules appearing in later fetches too (otherwise the end\n> result would depend on whether you cloned before or after a submodule\n> was added upstream, which is confusing). Extra points for populating\n> the submodule in my work tree when switching to a commit containing\n> the new submodule.\n>\n> So what about a \"submodule.autoupdate\" config option? If set to true,\n> all submodules not marked \"update=none\" would automatically be fetched\n> and inited by fetch (and thus clone too) and then checked out (with my\n> recursive update changes) in every work tree manipulating command\n> (again including clone).\n>\n> Users who only want the submodules to be present in the work tree but\n> not automagically updated could set \"submodule.autoupdate=clone\" to\n> avoid the extra cost of updating the work tree every time they switch\n> between commits. Now that Heiko's config-from-commit changes are in\n> master, someone could easily add that to fetch and clone as the first\n> step. We could also teach clone to make \"submodule.autoupdate=true\"\n> imply --recursive and execute the \"git submodule\" command to update\n> the work tree as a first step until the recursive checkout patches\n> are ready.\n>\n> Does that make sense?\n\nI guess.\n\nSo the repo tool has the concepts of groups. I plan to add that to git\neventually, too.\ni.e. with comma separated list that looks like:\n\n git clone --submodule-groups=default,x86builds,new-phone-codename\n\nHaving a new option there there I would also set the\n\n submodule.autoupdate=all\n\nimplicitly which then enables --recurse-submodules on all supported commands.\n\nBy introducing such a new submodule groups option we don't need to tell\nthe users about all the new submodule options, but they can still take\nadvantage of them,\nI'd assume.\n\nDoes that make sense, too?\n"},{"id":"273177","messageId":"5642C8BA.8030003@gmail.com","threadId":"40763","inReplyTo":"56424DDE.2030808@game-point.net","subject":"Re: Allow git alias to override existing Git commands","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2015-11-11T04:48:58Z","receivedAt":"2015-11-11T04:48:58Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 11/11/15 01:34, Jeremy Morton wrote:\n> On 10/11/2015 18:12, Stefan Beller wrote:\n>> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton wrote:\n>>> It's recently come to my attention that the \"git alias\" config functionality\n>>> ignores all aliases that would override existing Git commands. This seems\n>>> like a bad idea to me.\n>>\n>> This ensures that the plumbing commands always work as expected.\n>> As scripts *should* only use plumbing commands, the scripts should\n>> work with high probability despite all the crazy user configuration/aliases.\n>>\n> \n> I just disagree with this. If a user chooses to override their Git\n> commands, it's their problem. Why should Git care about this? It\n> should provide the user with the option to do this, and if the user\n> ruins scripts because of their aliases, it is not Git's problem. What\n> you are doing is taking away power from users to use git aliases to\n> their full potential.\n\nA lot of things in Unix do follow that \"give you rope to hang yourself\"\nphilosophy. I used to (and to *some* extent still do) think like that,\nbut some years of supporting normal users trying to do stuff has taught\nme it's not always that simple.\n\nI can easily see someone blogging some cool way to do something, and a\nless savvy user uses that in his gitconfig, and gets burned later\n(possibly much later, enough that he does not easily make the\nconnection!)\n\nSo for the record, I am definitely against this kind of change.\n\nBut if I were in your place, and really *needed* this, here's what I\nwould do:\n\n #!/bin/bash\n\n # this file is named 'git' and placed in a directory that is earlier in $PATH\n # than the real 'git' binary (typically $HOME/bin). This allows you to\n # override git sub-commands by adding stuff like this to your ~/.gitconfig\n # (notice the \"o-\" prefix):\n #\n # [alias]\n # o-clone = clone --recursive\n\n GIT=/bin/git # the real 'git' binary\n\n cmd=\"$1\"\n shift\n\n if $GIT config --get alias.o-$cmd >/dev/null\n then\n $GIT o-$cmd \"$@\"\n else\n $GIT $cmd \"$@\"\n fi\n"},{"id":"273179","messageId":"56430A27.2030604@game-point.net","threadId":"40763","inReplyTo":"5642C8BA.8030003@gmail.com","subject":"Re: Allow git alias to override existing Git commands","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2015-11-11T09:28:07Z","receivedAt":"2015-11-11T09:28:07Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 11/11/2015 04:48, Sitaram Chamarty wrote:\n> A lot of things in Unix do follow that \"give you rope to hang yourself\"\n> philosophy. I used to (and to *some* extent still do) think like that,\n> but some years of supporting normal users trying to do stuff has taught\n> me it's not always that simple.\n>\n> I can easily see someone blogging some cool way to do something, and a\n> less savvy user uses that in his gitconfig, and gets burned later\n> (possibly much later, enough that he does not easily make the\n> connection!)\n\nWe're not talking about \"normal users\" here, that's what Google Chrome \nis for. We're talking about Git users using the commandline client. \nThey ought to know what they're doing and if they don't, they're \nscrewed anyway because there are quite a few gotchas with Git.\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"273181","messageId":"56430F9F.7060900@gmail.com","threadId":"40763","inReplyTo":"56430A27.2030604@game-point.net","subject":"Re: Allow git alias to override existing Git commands","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2015-11-11T09:51:27Z","receivedAt":"2015-11-11T09:51:27Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 11/11/15 14:58, Jeremy Morton wrote:\n> On 11/11/2015 04:48, Sitaram Chamarty wrote:\n>> A lot of things in Unix do follow that \"give you rope to hang yourself\"\n>> philosophy. I used to (and to *some* extent still do) think like that,\n>> but some years of supporting normal users trying to do stuff has taught\n>> me it's not always that simple.\n>>\n>> I can easily see someone blogging some cool way to do something, and a\n>> less savvy user uses that in his gitconfig, and gets burned later\n>> (possibly much later, enough that he does not easily make the\n>> connection!)\n> \n> We're not talking about \"normal users\" here, that's what Google Chrome\n> is for. We're talking about Git users using the commandline client.\n> They ought to know what they're doing and if they don't, they're\n> screwed anyway because there are quite a few gotchas with Git.\n\nI can only repeat what I said before: it's not all black and white.\n\nReducing the opportunity to make mistakes is useful for everyone, even\nexpetrs. Especially stuff that you may have setup aeons ago and hits\nyou only aeons later when something (supposedly unrelated) somewhere\nelse changes and you didn't remember and you tear your hair out.\n\nIt happens to everyone. The only experts I know who have never torn\ntheir hair out over something silly they forgot (could be anything) are\nthe ones who were already bald :)\n"},{"id":"273183","messageId":"56431499.9010708@game-point.net","threadId":"40763","inReplyTo":"56430F9F.7060900@gmail.com","subject":"Re: Allow git alias to override existing Git commands","fromName":"Jeremy Morton","fromEmail":"admin@game-point.net","sentAt":"2015-11-11T10:12:41Z","receivedAt":"2015-11-11T10:12:41Z","isPatch":false,"sender":{"key":"admin@game-point.net","avatar":null},"body":"On 11/11/2015 09:51, Sitaram Chamarty wrote:\n> I can only repeat what I said before: it's not all black and white.\n>\n> Reducing the opportunity to make mistakes is useful for everyone, even\n> expetrs. Especially stuff that you may have setup aeons ago and hits\n> you only aeons later when something (supposedly unrelated) somewhere\n> else changes and you didn't remember and you tear your hair out.\n\nNot when it reduces useful functionality for experts, it's not.\n\n-- \nBest regards,\nJeremy Morton (Jez)\n"},{"id":"273186","messageId":"56431C3A.6060308@gmail.com","threadId":"40763","inReplyTo":"56431499.9010708@game-point.net","subject":"Re: Allow git alias to override existing Git commands","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2015-11-11T10:45:14Z","receivedAt":"2015-11-11T10:45:14Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 11/11/15 15:42, Jeremy Morton wrote:\n> On 11/11/2015 09:51, Sitaram Chamarty wrote:\n>> I can only repeat what I said before: it's not all black and white.\n>>\n>> Reducing the opportunity to make mistakes is useful for everyone, even\n>> expetrs. Especially stuff that you may have setup aeons ago and hits\n>> you only aeons later when something (supposedly unrelated) somewhere\n>> else changes and you didn't remember and you tear your hair out.\n> \n> Not when it reduces useful functionality for experts, it's not.\n\nSpeaking of... did you try the script I sent in an earlier mail?\n\nPutting it in /usr/local/bin (on Fedora. YMMV) seems to work fine,\nsince that appears earlier than /bin where the real git lives.\n"},{"id":"273199","messageId":"CAGZ79kZcgHknvZ03+T++1o3d2_YMo4+FCNkOMuG13qsHJp8V0Q@mail.gmail.com","threadId":"40763","inReplyTo":"56430A27.2030604@game-point.net","subject":"Re: Allow git alias to override existing Git commands","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-11-11T17:42:52Z","receivedAt":"2015-11-11T17:42:52Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Nov 11, 2015 at 1:28 AM, Jeremy Morton wrote:\n> On 11/11/2015 04:48, Sitaram Chamarty wrote:\n>>\n>> A lot of things in Unix do follow that \"give you rope to hang yourself\"\n>> philosophy. I used to (and to *some* extent still do) think like that,\n>> but some years of supporting normal users trying to do stuff has taught\n>> me it's not always that simple.\n>>\n>> I can easily see someone blogging some cool way to do something, and a\n>> less savvy user uses that in his gitconfig, and gets burned later\n>> (possibly much later, enough that he does not easily make the\n>> connection!)\n>\n>\n> We're not talking about \"normal users\" here, that's what Google Chrome is\n> for. We're talking about Git users using the commandline client. They ought\n> to know what they're doing and if they don't, they're screwed anyway because\n> there are quite a few gotchas with Git.\n>\n\nJust because you're an expert, doesn't mean you don't appreciate working without\nsafety net.\n\nThere are tons of people out there, who use Git for $REASONS (their\nboss told them so,\nit's cooler than $OTHERVCS, the project uses Git), without having the\ntime to take\na deep dive into Git. \"It should just work\".\n\nSo I haven't tried Sitaram's script, but it looks like it can get your job done?\n"},{"id":"273217","messageId":"56439AAB.4040104@web.de","threadId":"40763","inReplyTo":"CAGZ79ka_RACVEDJBU8_5UsEyUBvQgKTh7FbvSoHxpMjDYDgPOw@mail.gmail.com","subject":"Re: Allow git alias to override existing Git commands","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2015-11-11T19:44:43Z","receivedAt":"2015-11-11T19:44:43Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 10.11.2015 um 23:49 schrieb Stefan Beller:\n> On Tue, Nov 10, 2015 at 1:57 PM, Jens Lehmann wrote:\n>> Am 10.11.2015 um 19:12 schrieb Stefan Beller:\n>>> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton \n>>>> For example, I wanted to setup \"git clone\" to automatically act as \"git\n>>>> clone --recursive\". Sure I could do it in the shell, but it's more of a\n>>>> pain - any tutorial I set up about doing it would have to worry about\n>>>> what\n>>>> shell the user was using - and if you're going to make that argument, why\n>>>> have \"git alias\" at all? It can all be done from the shell.\n>>>\n>>>\n>>> I think the git way for your example would be to configure git to include\n>>> that\n>>> option by default, something like\n>>>\n>>> git config --global submodules.recursiveClone yes\n>>>\n>>> though I was skimming through the man page of git config and did not find\n>>> that option there. I guess it's missing.\n>>\n>>\n>> We thought about adding such a config option, but I believe that would\n>> fall a bit short. If I want to have recursive clone I also want to init\n>> all those submodules appearing in later fetches too (otherwise the end\n>> result would depend on whether you cloned before or after a submodule\n>> was added upstream, which is confusing). Extra points for populating\n>> the submodule in my work tree when switching to a commit containing\n>> the new submodule.\n>>\n>> So what about a \"submodule.autoupdate\" config option? If set to true,\n>> all submodules not marked \"update=none\" would automatically be fetched\n>> and inited by fetch (and thus clone too) and then checked out (with my\n>> recursive update changes) in every work tree manipulating command\n>> (again including clone).\n>>\n>> Users who only want the submodules to be present in the work tree but\n>> not automagically updated could set \"submodule.autoupdate=clone\" to\n>> avoid the extra cost of updating the work tree every time they switch\n>> between commits. Now that Heiko's config-from-commit changes are in\n>> master, someone could easily add that to fetch and clone as the first\n>> step. We could also teach clone to make \"submodule.autoupdate=true\"\n>> imply --recursive and execute the \"git submodule\" command to update\n>> the work tree as a first step until the recursive checkout patches\n>> are ready.\n>>\n>> Does that make sense?\n>\n> I guess.\n>\n> So the repo tool has the concepts of groups. I plan to add that to git\n> eventually, too.\n> i.e. with comma separated list that looks like:\n>\n> git clone --submodule-groups=default,x86builds,new-phone-codename\n>\n> Having a new option there there I would also set the\n>\n> submodule.autoupdate=all\n>\n> implicitly which then enables --recurse-submodules on all supported commands.\n\nAnd then only submodules contained in these groups would be cloned,\nautomatically initialized (including those being added to a group by\nupstream in the future) and their work trees updated every time the\nsuperproject commit changes? And all submodules that aren't part in\nany of these groups would be skipped and neither downloaded nor\nupdated? Sounds good.\n\nBut I'd rather use\n\n submodule.autoupdate=groups\n\nfor that use case. I expect \"all\" to really mean all submodules,\nnot only those contained in the selected groups.\n\n> By introducing such a new submodule groups option we don't need to tell\n> the users about all the new submodule options, but they can still take\n> advantage of them,\n> I'd assume.\n>\n> Does that make sense, too?\n\nYup.\n"}]}