From: Jeff King <peff@peff.net>
To: Duy Nguyen <pclouds@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 00/19] Add git-list-files
Date: Tue, 2 Dec 2014 15:18:38 -0500 [thread overview]
Message-ID: <20141202201837.GC23461@peff.net> (raw)
In-Reply-To: <CACsJy8DBkGVhaJnCTs9_E+g6FYYr4V-6S=XB5wrGBFPjHnEu1A@mail.gmail.com>
On Tue, Dec 02, 2014 at 06:45:52PM +0700, Duy Nguyen wrote:
> > As a side note, I wonder if it would be sensible to whitelist some
> > commands as porcelain, and allow aliases to override them (either
> > entirely, or just to add-in some options).
>
> Agreed. Maybe not all porcelain (some like git-branch almost functions
> like plumbing).
Yeah, many things straddle the plumbing/porcelain line (e.g., "commit"
is porcelain, but it's basically the only sane way for scripts to make a
commit, so many use it). So I'd pick just a few things that should be
safe to override.
> We also need away to stop alias (e.g. in scripts).
Do we? I think the point of allowing this only for porcelain is that you
do not have to care about scripts. That is, a script running "git ls"
would get whatever the user's preferences are for "ls" output. A script
parsing the output of "ls" deserves whatever crap it gets.
> In scripts I can specify full path to a command to make sure I won't
> hit an alias. I guess we can't do the same here. The closet to "full
> path" is git-cmd form, as opposed to "git cmd" form) but I think we
> don't want to bring back git-cmd. Maybe just a "git --no-alias cmd"
> and GIT_NO_ALIAS..
Yeah, I think "--no-alias"/GIT_NO_ALIAS would work. But the problem is
one of compatibility. Scripts are not written to specify no-alias, so
you cannot just turn on the override-commands-with-aliases feature
immediately (and likewise, scripts have little incentive to bother
annotating their calls if it the override feature is not enabled).
-Peff
next prev parent reply other threads:[~2014-12-02 20:18 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-30 8:55 [PATCH 00/19] Add git-list-files Nguyễn Thái Ngọc Duy
2014-11-30 8:55 ` [PATCH 01/19] ls_colors.c: add $LS_COLORS parsing code Nguyễn Thái Ngọc Duy
2014-11-30 8:55 ` [PATCH 02/19] ls_colors.c: parse color.ls.* from config file Nguyễn Thái Ngọc Duy
2014-11-30 8:55 ` [PATCH 03/19] ls_colors.c: add a function to color a file name Nguyễn Thái Ngọc Duy
2014-11-30 8:55 ` [PATCH 04/19] ls_colors.c: highlight submodules like directories Nguyễn Thái Ngọc Duy
2014-11-30 8:55 ` [PATCH 05/19] ls-files: buffer full item in strbuf before printing Nguyễn Thái Ngọc Duy
2014-11-30 8:55 ` [PATCH 06/19] ls-files: add --color to highlight file names Nguyễn Thái Ngọc Duy
2014-11-30 8:55 ` [PATCH 07/19] ls-files: add --column Nguyễn Thái Ngọc Duy
2014-11-30 8:55 ` [PATCH 08/19] ls-files: support --max-depth Nguyễn Thái Ngọc Duy
2014-11-30 8:55 ` [PATCH 09/19] Add git-list-files, a user friendly version of ls-files and more Nguyễn Thái Ngọc Duy
2014-12-02 2:50 ` Eric Sunshine
2014-12-02 12:06 ` Duy Nguyen
2014-11-30 8:55 ` [PATCH 10/19] list-files: -u does not imply showing stages Nguyễn Thái Ngọc Duy
2014-11-30 8:55 ` [PATCH 11/19] list-files: add -R/--recursive short for --max-depth=-1 Nguyễn Thái Ngọc Duy
2014-11-30 8:56 ` [PATCH 12/19] list-files: add -1 short for --no-column Nguyễn Thái Ngọc Duy
2014-11-30 8:56 ` [PATCH 13/19] list-files: add -t back Nguyễn Thái Ngọc Duy
2014-11-30 8:56 ` [PATCH 14/19] list-files: sort output and remove duplicates Nguyễn Thái Ngọc Duy
2014-11-30 8:56 ` [PATCH 15/19] list-files: do not show duplicate cached entries Nguyễn Thái Ngọc Duy
2014-11-30 8:56 ` [PATCH 16/19] list-files: show directories as well as files Nguyễn Thái Ngọc Duy
2014-11-30 8:56 ` [PATCH 17/19] list-files: add -F/--classify Nguyễn Thái Ngọc Duy
2014-11-30 8:56 ` [PATCH 18/19] list-files -F: show submodules with the new indicator '&' Nguyễn Thái Ngọc Duy
2014-11-30 8:56 ` [PATCH 19/19] list-files: -M aka diff-cached Nguyễn Thái Ngọc Duy
2014-12-01 20:02 ` [PATCH 00/19] Add git-list-files Junio C Hamano
2014-12-02 11:33 ` Duy Nguyen
2014-12-02 5:42 ` Jeff King
2014-12-02 11:45 ` Duy Nguyen
2014-12-02 20:18 ` Jeff King [this message]
2014-12-02 12:40 ` Michael J Gruber
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141202201837.GC23461@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.