{"thread":{"id":"20149","subject":"git silently ignores aliases of existing commands","startedAt":"2009-07-18T00:52:49Z","lastAt":"2009-07-18T16:12:22Z","messageCount":9,"participants":["Michael G Schwern","Sean Estabrooks","demerphq","Jeff King","A Large Angry SCM"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"118210","messageId":"4A611CE1.3080709@pobox.com","threadId":"20149","inReplyTo":null,"subject":"git silently ignores aliases of existing commands","fromName":"Michael G Schwern","fromEmail":"schwern@pobox.com","sentAt":"2009-07-18T00:52:49Z","receivedAt":"2009-07-18T00:52:49Z","isPatch":false,"sender":{"key":"schwern@pobox.com","avatar":"https://avatars.githubusercontent.com/u/25888?v=4"},"body":"Everyone says \"git tag\" does the wrong thing by default and what you really\nwant is an annotated tag with \"git tag -a\". So I figured I'd fix the default\nand in my .gitconfig added:\n\n[alias]\n tag = tag -a\n\nand considered it done. Weeks later I discovered git was ignoring that alias\nand I was still making lightweight tags.\n\nIt would be nice if git used the alias *before* the installed command. This\nlets me fix/change default behaviors without having to come up with a new\ncommand. (Another handy example: blame = blame -w) It doesn't do anything\nuseful right now anyway.\n\nWhether or not that changes, if an alias is being ignored git should warn me.\n This informs the user their perfectly sensible action has not done what they\nexpected. In addition, should git add a command in the future which conflicts\nwith the name of an alias they'll know.\n\n\nPS I couldn't find anything obvious about where to send bug reports / feature\nrequests in the git man page, just \"general upbringing\" pointing here. It\nwould be helpful if it was a bit more clear. None of \"bug\", \"report\" or\n\"issue\" pointed at anything relevant.\n\n-- \n184. When operating a military vehicle I may *not* attempt something\n \"I saw in a cartoon\".\n -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army\n http://skippyslist.com/list/\n"},{"id":"118215","messageId":"BLU0-SMTP9743008F68C14C8226D07BAE1F0@phx.gbl","threadId":"20149","inReplyTo":"4A611CE1.3080709@pobox.com","subject":"Re: git silently ignores aliases of existing commands","fromName":"Sean Estabrooks","fromEmail":"seanlkml@sympatico.ca","sentAt":"2009-07-18T02:01:31Z","receivedAt":"2009-07-18T02:01:31Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Fri, 17 Jul 2009 17:52:49 -0700\nMichael G Schwern wrote:\n\n[...]\n> It would be nice if git used the alias *before* the installed command. This\n> lets me fix/change default behaviors without having to come up with a new\n> command. (Another handy example: blame = blame -w) It doesn't do anything\n> useful right now anyway.\n\nHi Michael,\n\nThis has been discussed a few times on the list already. Here is one such\ndiscussion:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/112487/focus=112493\n\nYou'll see that it was decided that Git would not allow commands to be overridden\nso that you could always be sure what a given command would do when you sit\ndown at any installation. This is especially important for scripting but can\nalso be a problem for everyday usage. You'll just have to choose a new command\nname for the alternate default you want.\n\n[...]\n> PS I couldn't find anything obvious about where to send bug reports / feature\n> requests in the git man page, just \"general upbringing\" pointing here. It\n> would be helpful if it was a bit more clear. None of \"bug\", \"report\" or\n> \"issue\" pointed at anything relevant.\n\nThis list is the appropriate place for any of the issues you enumerate.\n\nCheers,\nSean\n"},{"id":"118220","messageId":"4A6176E6.4060708@pobox.com","threadId":"20149","inReplyTo":"BLU0-SMTP9743008F68C14C8226D07BAE1F0@phx.gbl","subject":"Re: git silently ignores aliases of existing commands","fromName":"Michael G Schwern","fromEmail":"schwern@pobox.com","sentAt":"2009-07-18T07:16:54Z","receivedAt":"2009-07-18T07:16:54Z","isPatch":false,"sender":{"key":"schwern@pobox.com","avatar":"https://avatars.githubusercontent.com/u/25888?v=4"},"body":"Sean Estabrooks wrote:\n> On Fri, 17 Jul 2009 17:52:49 -0700\n> Michael G Schwern wrote:\n> \n> [...]\n>> It would be nice if git used the alias *before* the installed command. This\n>> lets me fix/change default behaviors without having to come up with a new\n>> command. (Another handy example: blame = blame -w) It doesn't do anything\n>> useful right now anyway.\n> \n> This has been discussed a few times on the list already. Here is one such\n> discussion:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/112487/focus=112493\n> \n> You'll see that it was decided that Git would not allow commands to be overridden\n> so that you could always be sure what a given command would do when you sit\n> down at any installation. This is especially important for scripting but can\n> also be a problem for everyday usage. You'll just have to choose a new command\n> name for the alternate default you want.\n\nI'm in the \"more than enough rope\" camp myself, so count that as a -1 fwiw.\n\nMore importantly, what about the warning telling the user that what they did\nis not allowed and didn't work?\n\n\n-- \n What we learned was if you get confused, grab someone and swing\n them around a few times\n -- Life's lessons from square dancing\n"},{"id":"118223","messageId":"9b18b3110907180230p7fb432cdq56bfee794afc669e@mail.gmail.com","threadId":"20149","inReplyTo":"4A6176E6.4060708@pobox.com","subject":"Re: git silently ignores aliases of existing commands","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-07-18T09:30:25Z","receivedAt":"2009-07-18T09:30:25Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/7/18 Michael G Schwern :\n> Sean Estabrooks wrote:\n>> On Fri, 17 Jul 2009 17:52:49 -0700\n>> Michael G Schwern wrote:\n>>\n>> [...]\n>>> It would be nice if git used the alias *before* the installed command.  This\n>>> lets me fix/change default behaviors without having to come up with a new\n>>> command.  (Another handy example:  blame = blame -w)  It doesn't do anything\n>>> useful right now anyway.\n>>\n>> This has been discussed a few times on the list already.   Here is one such\n>> discussion:\n>>\n>> http://thread.gmane.org/gmane.comp.version-control.git/112487/focus=112493\n>>\n>> You'll see that it was decided that Git would not allow commands to be overridden\n>> so that you could always be sure what a given command would do when you sit\n>> down at any installation.  This is especially important for scripting but can\n>> also be a problem for everyday usage.   You'll just have to choose a new command\n>> name for the alternate default you want.\n>\n> I'm in the \"more than enough rope\" camp myself, so count that as a -1 fwiw.\n>\n> More importantly, what about the warning telling the user that what they did\n> is not allowed and didn't work?\n\nYeah it seems reasonable that if its going to be ignored it should not\nbe silently ignored.\n\nEspecially given that the silentness effectively means there cant be\nany new git tools added without possible breakage of installed setups.\n\ncheers,\nYves\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"118225","messageId":"20090718104631.GA27307@coredump.intra.peff.net","threadId":"20149","inReplyTo":"9b18b3110907180230p7fb432cdq56bfee794afc669e@mail.gmail.com","subject":"Re: git silently ignores aliases of existing commands","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-07-18T10:46:31Z","receivedAt":"2009-07-18T10:46:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jul 18, 2009 at 11:30:25AM +0200, demerphq wrote:\n\n> Yeah it seems reasonable that if its going to be ignored it should not\n> be silently ignored.\n\nI agree that there should be a warning. However, it's hard to do with\nthe code structured as it is now; we don't know that a command exists\nas an external command until we try to exec it. And if it succeeds, we\ndon't get to execute any more code.\n\nIt's certainly possible, but sadly it is more surgery than just\n\n if (alias_lookup(cmd))\n warn(\"you also have an alias defined\");\n\n> Especially given that the silentness effectively means there cant be\n> any new git tools added without possible breakage of installed setups.\n\nThe silentness makes it harder to diagnose problems, but even with a\nwarning, we can break things by creating new commands. If you have an\nalias \"foo\" and we ship \"git-foo\" in a newer version of git, your alias\nwill just stop working.\n\n-Peff\n"},{"id":"118226","messageId":"9b18b3110907180355s5bf08f8did180caa0c55b3389@mail.gmail.com","threadId":"20149","inReplyTo":"20090718104631.GA27307@coredump.intra.peff.net","subject":"Re: git silently ignores aliases of existing commands","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-07-18T10:55:26Z","receivedAt":"2009-07-18T10:55:26Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/7/18 Jeff King :\n> On Sat, Jul 18, 2009 at 11:30:25AM +0200, demerphq wrote:\n>\n>> Yeah it seems reasonable that if its going to be ignored it should not\n>> be silently ignored.\n>\n> I agree that there should be a warning. However, it's hard to do with\n> the code structured as it is now; we don't know that a command exists\n> as an external command until we try to exec it. And if it succeeds, we\n> don't get to execute any more code.\n>\n> It's certainly possible, but sadly it is more surgery than just\n>\n>  if (alias_lookup(cmd))\n>    warn(\"you also have an alias defined\");\n>\n>> Especially given that the silentness effectively means there cant be\n>> any new git tools added without possible breakage of installed setups.\n>\n> The silentness makes it harder to diagnose problems, but even with a\n> warning, we can break things by creating new commands. If you have an\n> alias \"foo\" and we ship \"git-foo\" in a newer version of git, your alias\n> will just stop working.\n\nThat was my point. At least if there were warnings about this the risk\nwould be mitigated.\n\ncheers,\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"118227","messageId":"20090718105855.GA29567@coredump.intra.peff.net","threadId":"20149","inReplyTo":"9b18b3110907180355s5bf08f8did180caa0c55b3389@mail.gmail.com","subject":"Re: git silently ignores aliases of existing commands","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-07-18T10:58:55Z","receivedAt":"2009-07-18T10:58:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jul 18, 2009 at 12:55:26PM +0200, demerphq wrote:\n\n> > The silentness makes it harder to diagnose problems, but even with a\n> > warning, we can break things by creating new commands. If you have an\n> > alias \"foo\" and we ship \"git-foo\" in a newer version of git, your alias\n> > will just stop working.\n> \n> That was my point. At least if there were warnings about this the risk\n> would be mitigated.\n\nI don't see how it's mitigated. You don't get any warning until _after_\nthings are broken. So yes, it may help you diagnose the breakage, but\npresumably the fact that the command is doing something completely\ndifferent would also alert you to the breakage.\n\nThe real problem comes from scripted use, where you don't necessarily\nhave a user reading warnings on stderr, or notice that some totally\nbogus code is being run (especially if said code happens not to produce\na non-zero exit code).\n\nBut perhaps that's what you meant, and I'm just nitpicking your\nlanguage.\n\n-Peff\n"},{"id":"118228","messageId":"9b18b3110907180420n67ec7fa1q4a0df2047f37435e@mail.gmail.com","threadId":"20149","inReplyTo":"20090718105855.GA29567@coredump.intra.peff.net","subject":"Re: git silently ignores aliases of existing commands","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-07-18T11:20:12Z","receivedAt":"2009-07-18T11:20:12Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/7/18 Jeff King :\n> On Sat, Jul 18, 2009 at 12:55:26PM +0200, demerphq wrote:\n>\n>> > The silentness makes it harder to diagnose problems, but even with a\n>> > warning, we can break things by creating new commands. If you have an\n>> > alias \"foo\" and we ship \"git-foo\" in a newer version of git, your alias\n>> > will just stop working.\n>>\n>> That was my point. At least if there were warnings about this the risk\n>> would be mitigated.\n>\n> I don't see how it's mitigated. You don't get any warning until _after_\n> things are broken. So yes, it may help you diagnose the breakage, but\n> presumably the fact that the command is doing something completely\n> different would also alert you to the breakage.\n>\n> The real problem comes from scripted use, where you don't necessarily\n> have a user reading warnings on stderr, or notice that some totally\n> bogus code is being run (especially if said code happens not to produce\n> a non-zero exit code).\n>\n> But perhaps that's what you meant, and I'm just nitpicking your\n> language.\n\nI think we are more or less in agreement, except maybe that i think\nthe situation would be marginally better if git detected this.\n\n:-)\n\nSeems an awkward position actually. Maybe a switch like\n--ignore-command-aliases which would be used by all internal commands\nwhen they expect to find another internal command would resolve it.\nThen aliases of internal commands to control default switches could\nactually be allowed to work, and there would not be the future\ncompatibility trap that there seems to be now.\n\ncheers,\nYves\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"118237","messageId":"4A61F466.3080105@gmail.com","threadId":"20149","inReplyTo":"9b18b3110907180420n67ec7fa1q4a0df2047f37435e@mail.gmail.com","subject":"Re: git silently ignores aliases of existing commands","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-07-18T16:12:22Z","receivedAt":"2009-07-18T16:12:22Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"demerphq wrote:\n> 2009/7/18 Jeff King :\n>> On Sat, Jul 18, 2009 at 12:55:26PM +0200, demerphq wrote:\n>>\n>>>> The silentness makes it harder to diagnose problems, but even with a\n>>>> warning, we can break things by creating new commands. If you have an\n>>>> alias \"foo\" and we ship \"git-foo\" in a newer version of git, your alias\n>>>> will just stop working.\n>>> That was my point. At least if there were warnings about this the risk\n>>> would be mitigated.\n>> I don't see how it's mitigated. You don't get any warning until _after_\n>> things are broken. So yes, it may help you diagnose the breakage, but\n>> presumably the fact that the command is doing something completely\n>> different would also alert you to the breakage.\n>>\n>> The real problem comes from scripted use, where you don't necessarily\n>> have a user reading warnings on stderr, or notice that some totally\n>> bogus code is being run (especially if said code happens not to produce\n>> a non-zero exit code).\n>>\n>> But perhaps that's what you meant, and I'm just nitpicking your\n>> language.\n> \n> I think we are more or less in agreement, except maybe that i think\n> the situation would be marginally better if git detected this.\n> \n> :-)\n> \n> Seems an awkward position actually. Maybe a switch like\n> --ignore-command-aliases which would be used by all internal commands\n> when they expect to find another internal command would resolve it.\n> Then aliases of internal commands to control default switches could\n> actually be allowed to work, and there would not be the future\n> compatibility trap that there seems to be now.\n\nThe real solution is to (re)move the aliases from the git name-space.\n"}]}