From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Jun 2013, #07; Thu, 20)
Date: Sat, 22 Jun 2013 11:47:41 +0530 [thread overview]
Message-ID: <CALkWK0=FaC9CqiTLE=UJA+Xg04=ZS45XddQ-RmPe_HSej2s5bA@mail.gmail.com> (raw)
In-Reply-To: <7vvc57kxxt.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Because the implementation is too ugly.
I know :) The only reason I sent it with code is because I didn't get
any responses to an email without code. If you agree that it is a
useful feature, we have to figure out a beautiful implementation.
> I would however can imagine an alternative implementation which
> might be more palatable. It may go like this:
>
> [alias "lgF"]
> command = "log --oneline --boundary --first-parent"
> help = "show the first parent chain, one line per commit"
I'm not sure what value this adds. If I ever forget what my alias is
called, I `git rp --help` to get the expansion and then look up the
manpage. It would be ideal if I could `man git lgF` though: I'm sick
of having to type out `man git for-each-ref` everytime I need the
manpage for fer (obviously an unscripted `man` won't work: `git help`
will do the translation).
> completion = log
Again, unsure what value it adds. I already have plenty of aliases
that complete fine. The completion only fails if I have an !-command;
in that case, this solution is a hack: we should work towards not
requiring an !-command in the first place.
> so that not just alias.c code can take notice of alias.lgF.command
> to expand it,
How? Fundamentally, alias_lookup_cb() is a fired off by the
config-parsing infrastructure which calls a tolower() on everything:
alias.c has control over nothing, unless we re-implement the entire
config-parsing infrastructure specifically for aliases (Bad idea). I
don't see how changing from alias.<name> to alias.<name>.command helps
anything, especially when the other alias.<name>.* keys aren't even
useful.
> but we can later extend it to help "git help lgF"
Yeah, this is a good idea.
> and
> bash/zsh completion (i.e. they would learn "lgF parameter would
> complete in a way similar to 'log'" from alias.lgF.completion).
Solved problem: see __git_aliased_command() in git-completion.bash.
next prev parent reply other threads:[~2013-06-22 6:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-21 4:56 What's cooking in git.git (Jun 2013, #07; Thu, 20) Junio C Hamano
2013-06-21 11:05 ` Ramkumar Ramachandra
2013-06-21 15:51 ` Junio C Hamano
2013-06-21 16:07 ` Ramkumar Ramachandra
2013-06-21 17:07 ` Junio C Hamano
2013-06-21 17:13 ` Ramkumar Ramachandra
2013-06-21 17:32 ` Antoine Pelisse
2013-06-21 18:26 ` Junio C Hamano
2013-06-21 18:49 ` Ramkumar Ramachandra
2013-06-21 20:31 ` Junio C Hamano
2013-06-22 6:17 ` Ramkumar Ramachandra [this message]
2013-06-23 17:21 ` Thomas Rast
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='CALkWK0=FaC9CqiTLE=UJA+Xg04=ZS45XddQ-RmPe_HSej2s5bA@mail.gmail.com' \
--to=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).