demerphq wrote:
2009/7/18 Jeff King <peff@xxxxxxxx>:
On Sat, Jul 18, 2009 at 12:55:26PM +0200, demerphq wrote:
The silentness makes it harder to diagnose problems, but even with a
warning, we can break things by creating new commands. If you have an
alias "foo" and we ship "git-foo" in a newer version of git, your alias
will just stop working.
That was my point. At least if there were warnings about this the risk
would be mitigated.
I don't see how it's mitigated. You don't get any warning until _after_
things are broken. So yes, it may help you diagnose the breakage, but
presumably the fact that the command is doing something completely
different would also alert you to the breakage.
The real problem comes from scripted use, where you don't necessarily
have a user reading warnings on stderr, or notice that some totally
bogus code is being run (especially if said code happens not to produce
a non-zero exit code).
But perhaps that's what you meant, and I'm just nitpicking your
language.
I think we are more or less in agreement, except maybe that i think
the situation would be marginally better if git detected this.
:-)
Seems an awkward position actually. Maybe a switch like
--ignore-command-aliases which would be used by all internal commands
when they expect to find another internal command would resolve it.
Then aliases of internal commands to control default switches could
actually be allowed to work, and there would not be the future
compatibility trap that there seems to be now.
The real solution is to (re)move the aliases from the git name-space.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html