Re: [RFC PATCH] Allow aliases that include other aliases

From: Jeff King <peff@peff.net>
Date: Sep 4, 2018, 20:11 UTC
Message-ID: <20180904201115.GD17481@sigill.intra.peff.net>
In-Reply-To: <xmqqsh2p9mg8.fsf@gitster-ct.c.googlers.com>

On Tue, Sep 04, 2018 at 10:55:35AM -0700, Junio C Hamano wrote:

Show 18 quoted lines

> Tim Schumacher <timschumi@gmx.de> writes:
> 
> > I submitted this as RFC because I'm not sure whether disallowing
> > nested aliases was an intentional design choice. The done_alias
> > check implies that disallowing is intended, but the direct
> > recursion check for aliases that call themselves opposes that.
> 
> "direct recursion check for aliases"?  I am not sure what you mean
> by that, but anyway.
> 
> If I recall correctly, it is intended that we disallow run_argv()
> doing handle_alias() twice (or more).  But the ultimate objective is
> to forbid infinite loops, "git foo" expanding to "git bar" which in
> turn expanding back to "git foo", and the current "do not expand
> alias to another" is a simple but too strict implementation.  As
> long as a replacement implementation still forbids infinite loops
> with reasonable cost and complexity, I do not think we would mind
> such an improvement to allow alias expanding to another alias.

I agree that this could be looser, if all we care about is infinite loops. But given the issues we've had with aliases and the startup sequence, I also would not be surprised if there is some weird hidden effect if we call handle_alias() more than once.

That's not a reason not to pursue this, but just one more thing to look out for.

As an aside, you can still do this:

  $ git config alias.foo '!git bar'
  $ git config alias.bar '!git foo'
  $ git foo
  [boy, my CPU fan is really spinning]

I don't know how much effort we actually need to put into people not shooting themselves in the foot, since we can't cover all of the cases anyway (and in a non-infinite configuration, that's another solution for Tim's original problem).

-Peff