git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Tim Schumacher <timschumi@gmx.de>, git@vger.kernel.org
Subject: Re: [RFC PATCH] Allow aliases that include other aliases
Date: Tue, 4 Sep 2018 16:11:16 -0400	[thread overview]
Message-ID: <20180904201115.GD17481@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqsh2p9mg8.fsf@gitster-ct.c.googlers.com>

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

> 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

      reply	other threads:[~2018-09-04 20:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-04 17:39 [RFC PATCH] Allow aliases that include other aliases Tim Schumacher
2018-09-04 17:55 ` Junio C Hamano
2018-09-04 20:11   ` Jeff King [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180904201115.GD17481@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=timschumi@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).