{"thread":{"id":"63962","subject":"why can't one alias `git stash`?","startedAt":"2025-08-15T01:09:21Z","lastAt":"2025-08-19T21:48:18Z","messageCount":12,"participants":["Christoph Anton Mitterer","Junio C Hamano","Elijah Newren","rsbecker@nexbridge.com","Matthias Aßhauer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"524202","messageId":"a24d0d237b9f57535c768da4c00d72bad68cf411.camel@scientia.org","threadId":"63962","inReplyTo":null,"subject":"why can't one alias `git stash`?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2025-08-15T00:33:20Z","receivedAt":"2025-08-15T01:09:21Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"Hey.\n\nPersonally, I've always disliked that `git stash` already does the\n`push` and would have much more preferred it, if it did a `stash list`.\n\nSo I tried to solve this via an alias like:\n[alias]\n        stash = \"!c(){ if [ \\\"$#\\\" -eq 0 ]; then git stash list; else git stash \\\"$@\\\"; fi; }; c\"\n\nwhich seems however to be ignored when the alias name is \"stash\" (it\nworks as it should when I use e.g. foo = ...).\n\n\nAny idea why that doesn't work?\n\n\nAlso when using such shell functions seems to be not extensively\ndocumented (or I didn't find it)... the example in git-config gives the\n\"!c()...\" syntax but doesn't seem to tell what the ! is for?\n\nAre these functions executed in a separate shell execution environment\n(or could I accidentally override a function from some git shell\nscript)?\n\nIs there any sanitisation of the environment that the shell gets (or\ndoes it simply get whatever the user has)?\nI mean a badly set IFS or similar could easily cause troubles.\n\n\nThanks,\nChris.\n"},{"id":"524222","messageId":"xmqq7bz5v0mq.fsf@gitster.g","threadId":"63962","inReplyTo":"a24d0d237b9f57535c768da4c00d72bad68cf411.camel@scientia.org","subject":"Re: why can't one alias `git stash`?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-08-15T01:23:25Z","receivedAt":"2025-08-15T01:23:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christoph Anton Mitterer <calestyo@scientia.org> writes:\n\n> So I tried to solve this via an alias like:\n> [alias]\n>         stash = \"!c(){ if [ \\\"$#\\\" -eq 0 ]; then git stash list; else git stash \\\"$@\\\"; fi; }; c\"\n>\n> which seems however to be ignored when the alias name is \"stash\" (it\n> works as it should when I use e.g. foo = ...).\n\nLook for \"alias.*\" in \"git help config\".\n\n        To avoid\n\tconfusion and troubles with script usage, aliases that\n\thide existing Git commands are ignored. \n\n> Also when using such shell functions seems to be not extensively\n> documented (or I didn't find it)... the example in git-config gives the\n> \"!c()...\" syntax but doesn't seem to tell what the ! is for?\n\n\tIf the alias expansion is prefixed with an exclamation\n        point, it will be treated as a shell command.\n\n"},{"id":"524223","messageId":"16220ca65f1ae9883a2fa103e842cf0ffff43236.camel@scientia.org","threadId":"63962","inReplyTo":"xmqq7bz5v0mq.fsf@gitster.g","subject":"Re: why can't one alias `git stash`?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2025-08-15T02:02:04Z","receivedAt":"2025-08-15T02:11:07Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"Hey.\n\nOn Thu, 2025-08-14 at 18:23 -0700, Junio C Hamano wrote:\n> Look for \"alias.*\" in \"git help config\".\n> \n>         To avoid\n> \tconfusion and troubles with script usage, aliases that\n> \thide existing Git commands are ignored. \n\nCan't one add some kind of override for this? Cause AFAIU, my command\nfrom below would not hide the other commands, or would it?\n\n\n> \tIf the alias expansion is prefixed with an exclamation\n>         point, it will be treated as a shell command.\n\nWell I kinda thought that... still wouldn't though if it was detailed\nwhat exactly happens :-)\n\nThanks,\nChris.\n"},{"id":"524225","messageId":"CABPp-BHt80YD9bzWeC+r5qxJ0Vp+zRsJZsKDU_GA39CXmuYe5A@mail.gmail.com","threadId":"63962","inReplyTo":"16220ca65f1ae9883a2fa103e842cf0ffff43236.camel@scientia.org","subject":"Re: why can't one alias `git stash`?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2025-08-15T04:04:03Z","receivedAt":"2025-08-15T04:04:15Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, Aug 14, 2025 at 7:15 PM Christoph Anton Mitterer\n<calestyo@scientia.org> wrote:\n>\n> Hey.\n>\n> On Thu, 2025-08-14 at 18:23 -0700, Junio C Hamano wrote:\n> > Look for \"alias.*\" in \"git help config\".\n> >\n> >         To avoid\n> >       confusion and troubles with script usage, aliases that\n> >       hide existing Git commands are ignored.\n>\n> Can't one add some kind of override for this?\n\nNo.  And there won't be one in the future either; see e.g.\nhttps://lore.kernel.org/git/alpine.DEB.1.00.0903070407480.10279@pacific.mpi-cbg.de/\n\n> Cause AFAIU, my command\n> from below would not hide the other commands, or would it?\n\nThe documentation you are responding to didn't talk about \"other\"\ncommands, it talked about \"existing\" commands.  Your alias, meant to\ninvoke `git stash` with different arguments, would hide the existing\n`git stash` command.\n\nIt might also be an infinite loop of sorts, since your `git stash`\nalias invokes `git stash ...` which is...itself.\n\nAnd it'd mean that other folks who use git commands in their scripts\nnow can't rely on any git commands doing what their documentation\nclaims.\n\n> >       If the alias expansion is prefixed with an exclamation\n> >         point, it will be treated as a shell command.\n>\n> Well I kinda thought that... still wouldn't though if it was detailed\n> what exactly happens :-)\n\nDoesn't it detail what happens already?\n\n           If the alias expansion is prefixed with an exclamation\npoint, it will be treated as a shell command. For example, defining\nalias.new = !gitk --all --not\n           ORIG_HEAD, the invocation git new is equivalent to running\nthe shell command gitk --all --not ORIG_HEAD. Note that shell commands\nwill be executed from the\n           top-level directory of a repository, which may not\nnecessarily be the current directory.  GIT_PREFIX is set as returned\nby running git rev-parse --show-prefix\n           from the original current directory. See git-rev-parse(1).\n\nWhat is missing from this explanation?\n"},{"id":"524240","messageId":"00ec01dc0dd6$f4e31f00$dea95d00$@nexbridge.com","threadId":"63962","inReplyTo":"CABPp-BHt80YD9bzWeC+r5qxJ0Vp+zRsJZsKDU_GA39CXmuYe5A@mail.gmail.com","subject":"RE: why can't one alias `git stash`?","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-08-15T11:22:53Z","receivedAt":"2025-08-15T11:25:32Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On August 15, 2025 12:04 AM, Elijah Newren wrote:\n>On Thu, Aug 14, 2025 at 7:15 PM Christoph Anton Mitterer\n><calestyo@scientia.org> wrote:\n>>\n>> Hey.\n>>\n>> On Thu, 2025-08-14 at 18:23 -0700, Junio C Hamano wrote:\n>> > Look for \"alias.*\" in \"git help config\".\n>> >\n>> >         To avoid\n>> >       confusion and troubles with script usage, aliases that\n>> >       hide existing Git commands are ignored.\n>>\n>> Can't one add some kind of override for this?\n>\n>No.  And there won't be one in the future either; see e.g.\n>https://lore.kernel.org/git/alpine.DEB.1.00.0903070407480.10279@pacific.mpi-\n>cbg.de/\n>\n>> Cause AFAIU, my command\n>> from below would not hide the other commands, or would it?\n>\n>The documentation you are responding to didn't talk about \"other\"\n>commands, it talked about \"existing\" commands.  Your alias, meant to invoke `git\n>stash` with different arguments, would hide the existing `git stash` command.\n>\n>It might also be an infinite loop of sorts, since your `git stash` alias invokes `git stash\n>...` which is...itself.\n>\n>And it'd mean that other folks who use git commands in their scripts now can't rely\n>on any git commands doing what their documentation claims.\n>\n>> >       If the alias expansion is prefixed with an exclamation\n>> >         point, it will be treated as a shell command.\n>>\n>> Well I kinda thought that... still wouldn't though if it was detailed\n>> what exactly happens :-)\n>\n>Doesn't it detail what happens already?\n>\n>           If the alias expansion is prefixed with an exclamation point, it will be treated as\n>a shell command. For example, defining alias.new = !gitk --all --not\n>           ORIG_HEAD, the invocation git new is equivalent to running the shell\n>command gitk --all --not ORIG_HEAD. Note that shell commands will be executed\n>from the\n>           top-level directory of a repository, which may not necessarily be the current\n>directory.  GIT_PREFIX is set as returned by running git rev-parse --show-prefix\n>           from the original current directory. See git-rev-parse(1).\n>\n>What is missing from this explanation?\n\nAside from the above, hiding an existing command would potentially allow a\nman-in-the-middle attack. Imagine changing git clone to be something else,\nlike cloning a hostile repository. Hiding existing commands could result in a\nHIGH severity CVE in git - I would consider it as such. Please ensure that no\nfix/enhancement is done to support this request.\n\n--Radall\n\n"},{"id":"524245","messageId":"xmqqjz34txjg.fsf@gitster.g","threadId":"63962","inReplyTo":"CABPp-BHt80YD9bzWeC+r5qxJ0Vp+zRsJZsKDU_GA39CXmuYe5A@mail.gmail.com","subject":"Re: why can't one alias `git stash`?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-08-15T15:27:47Z","receivedAt":"2025-08-15T15:27:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren <newren@gmail.com> writes:\n\n> The documentation you are responding to didn't talk about \"other\"\n> commands, it talked about \"existing\" commands.  Your alias, meant to\n> invoke `git stash` with different arguments, would hide the existing\n> `git stash` command.\n\nCorrect.\n\n> It might also be an infinite loop of sorts, since your `git stash`\n> alias invokes `git stash ...` which is...itself.\n\nTrue.  But we do not do a very good job preventing this to happen.\n\n    $ git -c alias.loop='loop foo' loop foo\n    fatal: recursive alias: loop\n    $ git -c alias.loop='!git loop foo' alias foo ;# does not come back\n    ^C\n\nTo be honest, I do not offhand see a foolproof way to \"fix\" the\nlatter.\n\n> And it'd mean that other folks who use git commands in their scripts\n> now can't rely on any git commands doing what their documentation\n> claims.\n\nIt is true that it would break common expectations for script\nwriters (to help other Git users) and those who help other Git users\nat their keyboards if we allowed to alias the basic command away and\nto change its behaviour radically.  But with so many configuration\nvariable to alter behaviour for Porcelain commands, I am not sure\nhow much it is helping the latter helpers these days.  For the\nformer helpers, those who write their scripts with Porcelain\ncommands are beyond salvation X-<.\n\nThanks.\n"},{"id":"524285","messageId":"fdb7d4da229dc41302d1c17871674cb41d3956ce.camel@scientia.org","threadId":"63962","inReplyTo":"CABPp-BHt80YD9bzWeC+r5qxJ0Vp+zRsJZsKDU_GA39CXmuYe5A@mail.gmail.com","subject":"Re: why can't one alias `git stash`?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2025-08-16T01:35:47Z","receivedAt":"2025-08-16T01:43:56Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Thu, 2025-08-14 at 21:04 -0700, Elijah Newren wrote:\n> No.  And there won't be one in the future either; see e.g.\n> https://lore.kernel.org/git/alpine.DEB.1.00.0903070407480.10279@pacific.mpi-cbg.de/\n\nAt least the \"it makes it hard for users to understand\" argument seems\na bit weak.\n\nI mean isn't that's also the case with shell aliases and the whole\npoint of them is to customise the behaviour for the user (which is btw\nalso done by many git-config options, which another user that uses my\nsettings may not be familiar with).\n\n\n\n> And it'd mean that other folks who use git commands in their scripts\n> now can't rely on any git commands doing what their documentation\n> claims.\n\nTBH, I wasn't even aware that git aliases are applied from scripts.\n\nIsn't that anyway a pretty dangerous game?\nI mean I could define an alias that works right now, as it doesn't hid\nan actual command... my script relies on that alias working.\nAnd the next git version introduces a command of the same name (and my\nscript breaks).\n\nThere's good reason that shell aliasing is per default not active in\nnon-interactive shells.\n\n> Doesn't it detail what happens already?\n> \n>            If the alias expansion is prefixed with an exclamation\n> point, it will be treated as a shell command. For example, defining\n> alias.new = !gitk --all --not\n>            ORIG_HEAD, the invocation git new is equivalent to running\n> the shell command gitk --all --not ORIG_HEAD. Note that shell\n> commands\n> will be executed from the\n>            top-level directory of a repository, which may not\n> necessarily be the current directory.  GIT_PREFIX is set as returned\n> by running git rev-parse --show-prefix\n>            from the original current directory. See git-rev-parse(1).\n> \n> What is missing from this explanation?\n\nWell, what I've said in my initial post.\nIs the shell execution environment in any way sanitised (like which\nIFS, PATH, whatever are set) or does it even share the env from some\ngit shell script that may execute the alias shell command (as in dot\nsourcing).\nPerhaps also *which* shell is used? Is it always /bin/sh or whatever\nshell the user has configured as login shell?\nWill e.g. profile/rc files be loaded or not.\n\nAdmittedly some information might be overkill, but at least I'd wanna\nknow if using the wrong function/var names in my alias command, could\ncause troubles for git.\n\n\nCheers,\nChris.\n"},{"id":"524286","messageId":"46840dddbb8a1647539e1b2cd3838167600fcb14.camel@scientia.org","threadId":"63962","inReplyTo":"00ec01dc0dd6$f4e31f00$dea95d00$@nexbridge.com","subject":"Re: why can't one alias `git stash`?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2025-08-16T02:03:56Z","receivedAt":"2025-08-16T02:04:07Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Fri, 2025-08-15 at 07:22 -0400, rsbecker@nexbridge.com wrote:\n> > \n> Aside from the above, hiding an existing command would potentially\n> allow a\n> man-in-the-middle attack. Imagine changing git clone to be something\n> else,\n> like cloning a hostile repository. Hiding existing commands could\n> result in a\n> HIGH severity CVE in git - I would consider it as such. Please ensure\n> that no\n> fix/enhancement is done to support this request.\n\nThis I don't understand.\n\nI mean I hopefully never get a remote git config file e.g. just by\ncloning some remote repo[0].\n\nSo - if git aliases were to be only applied when called from\ninteractive shells - how exactly could there be a MitM without the\nattacker having already compromised at least one’s user account?\n\n\nCheers,\nChris.\n\n\n[0] Perhaps a bit off topic (my apologies for that) but I had wanted to\nask this for a long time - or maybe I've had even brought it up back\nthen, but there was no outcome):\n\nI vaguely remember the CVE that cause the introduction of\nsafe.bareRepository, which AFAICS was CVE-2022-24765.\n\nI'm not an expert but even back then I had already some doubts whether\nthis really *fully* fixed the issue (for all niche cases), did it?\n\nI mean when I do a plain\n  git clone http://hackerz.com/rogue/repo.git\nthen the resulting repo/.git/config cannot contain any configs from an\nattacker (e.g. rogue alises).\n\n\nWhat if repo.git itself contained e.g. a ./x/.git subdir with configs?\nMy understanding was, that with safe.bareRepository = explicit, such\nsubrepo .git would never get cloned, so that would be safe.\nRight?\n\n\nBut what if I untar such rogue repo... or perhaps more likely, stumble\nover it on some network mount?\nTo many users it may not be obvious, that this is a risk. And I guess\nit might even be exploitable by just cd-ing into the wrong directory\n(if e.g. git prompt is used).\n\nIt's also not really clear to me whether any 3rd party git utils/libs\n(libgit2, etc. pp.) may fall for such attack?\n\nAnd IMO that is different from downloading some untrusted binary and\nexecuting it, as e.g. already a cd could cause troubles.\n\n\nIs that the situation as assumed? Are there any plans about doing\nsomething against it?\n\nOne could e.g. keep a central list of pathname of directories that are\nactually considered repositories... and things like aliases/etc. would\nonly get executed if they belong to these.\nA git clone could automatically add the new repo to that list (but e.g.\nun-taring some repo wouldn't cause it to be used as that).\n\nOr, in order to allow moving the repo to another pathname without\nhaving to re-register it, any \"allowed/trusted\" repo could get some\nmagic cookie in it's .git dir, which is signed by some key from the\nuser.\nCould even allow more than one such cookie, so that multiple users\ncould work on a shared repo.\n\nOf course this would only fully protect, if all other interfaces/libs\nto git would also adhere to that.\n\nAnd of course, one could make it configurable, i.e. safe.ignore-\nuntrusted-repos ... for all those who think the whole thing is annoying\nand rubbish.\n"},{"id":"524287","messageId":"d8b279098a41949eef06f26d3f09c3950486380b.camel@scientia.org","threadId":"63962","inReplyTo":"xmqqjz34txjg.fsf@gitster.g","subject":"Re: why can't one alias `git stash`?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2025-08-16T02:11:20Z","receivedAt":"2025-08-16T02:21:07Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Fri, 2025-08-15 at 08:27 -0700, Junio C Hamano wrote:\n>     $ git -c alias.loop='!git loop foo' alias foo ;# does not come\n> back\n>     ^C\n> \n> To be honest, I do not offhand see a foolproof way to \"fix\" the\n> latter.\n\nI assume every aliasing step causes a new invocation of git - or are\naliases resolved in one process?\n\nIf the former, what about:\nFor every aliasing you append to some special env var the name of the\nalias, and if the same is encountered again (or some maximum env var\nsize has been reached) you bail out with an error?\n\nIt's of course still not 100% foolproof, e.g. if users manually clear\nthe var or somehow else uses it.\nAnd it requires that at least one char (that can be held by an env var)\nis not allowed as an alias name, to be used as separator.\n\n\n> It is true that it would break common expectations for script\n> writers (to help other Git users) and those who help other Git users\n> at their keyboards if we allowed to alias the basic command away and\n> to change its behaviour radically.\n\nAs mentioned in the other thread, IMO it sounds rather brittle if\naliases are considered at all in scripting.\n\n\n> But with so many configuration\n> variable to alter behaviour for Porcelain commands, I am not sure\n> how much it is helping the latter helpers these days.  For the\n> former helpers, those who write their scripts with Porcelain\n> commands are beyond salvation X-<.\n\nWell I'd also be happy with a special porcelain option that allows be\nto override the default of git stash O:-)\n\n\nThanks,\nChris.\n"},{"id":"524290","messageId":"DB9P250MB06920D87A02A7FE81F88C034A537A@DB9P250MB0692.EURP250.PROD.OUTLOOK.COM","threadId":"63962","inReplyTo":"d8b279098a41949eef06f26d3f09c3950486380b.camel@scientia.org","subject":"Re: why can't one alias `git stash`?","fromName":"Matthias Aßhauer","fromEmail":"mha1993@live.de","sentAt":"2025-08-16T09:15:17Z","receivedAt":"2025-08-16T09:15:27Z","isPatch":false,"sender":{"key":"mha1993@live.de","avatar":"https://avatars.githubusercontent.com/u/6178234?v=4"},"body":"\n\nOn Sat, 16 Aug 2025, Christoph Anton Mitterer wrote:\n\n> As mentioned in the other thread, IMO it sounds rather brittle if\n> aliases are considered at all in scripting.\n\nHow would they not be considered? There is no --ignore-aliases option \n(because it would currently do nothing usefull), so git doesn't know if \nits called from a script. And if we where to add such an option, existing \nscripts wouldn't use it.\n\nBest regards\n\nMatthias\n"},{"id":"524381","messageId":"xmqqh5y4gm4v.fsf@gitster.g","threadId":"63962","inReplyTo":"d8b279098a41949eef06f26d3f09c3950486380b.camel@scientia.org","subject":"Re: why can't one alias `git stash`?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-08-19T01:01:36Z","receivedAt":"2025-08-19T01:01:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christoph Anton Mitterer <calestyo@scientia.org> writes:\n\n> As mentioned in the other thread, IMO it sounds rather brittle if\n> aliases are considered at all in scripting.\n\nAs a program, how would you tell when you are run by a script?\n\nIf you are a shell, you go into \"interactive\" mode when you are\ntaking your command stream from a tty, and otherwise assume you are\nnot interactive.  The same trick would not work at all for programs\nstarted by a shell, would it?\n\nAsking script writers to pass \"--no-alias\" option to all of their\n\"git\" invocation will probably not be a viable way forward, either.\n"},{"id":"524494","messageId":"67090cec91d92af5616651de29950ecb3e8810f6.camel@scientia.org","threadId":"63962","inReplyTo":"xmqqh5y4gm4v.fsf@gitster.g","subject":"Re: why can't one alias `git stash`?","fromName":"Christoph Anton Mitterer","fromEmail":"calestyo@scientia.org","sentAt":"2025-08-19T21:38:35Z","receivedAt":"2025-08-19T21:48:18Z","isPatch":false,"sender":{"key":"calestyo@scientia.org","avatar":"https://gravatar.com/avatar/2dd3cd5191e4ec4a5e1e0a0861a64378636270f4007bab080a27b27a607bb267?d=mp&s=160"},"body":"On Mon, 2025-08-18 at 18:01 -0700, Junio C Hamano wrote:\n> As a program, how would you tell when you are run by a script?\n> \n> If you are a shell, you go into \"interactive\" mode when you are\n> taking your command stream from a tty, and otherwise assume you are\n> not interactive.  The same trick would not work at all for programs\n> started by a shell, would it?\n\nNot for all, but it might still give enough \"teaching\" to prevent\npeople from using aliases in scripts.\n\nChecking whether the parent process is a well known shell would\nprobably not help, as it would also be for the interactive case, where\naliasing is wanted.\n\n\n> Asking script writers to pass \"--no-alias\" option to all of their\n> \"git\" invocation will probably not be a viable way forward, either.\n\nAgain at least not a safe one. And doing the opposite, i.e. requring --\nenable-aliasing (which people would then have to set as shell alias),\nwould probably end up in generating quite a few annoyed people. ;-)\n\nIt could be made optional. E.g. some gitconf option that per default\nenables aliasing always but allows to require a --aliasing option\n(which then again is intended to be set via a shell alias) in order for\ngit aliasing to be enabled.\n\nWhether it's worth the effort is of course another question.\n\n\nCheers,\nChris.\n"}]}