git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 00/19] Add git-list-files
Date: Tue, 2 Dec 2014 00:42:26 -0500	[thread overview]
Message-ID: <20141202054226.GA1948@peff.net> (raw)
In-Reply-To: <1417337767-4505-1-git-send-email-pclouds@gmail.com>

On Sun, Nov 30, 2014 at 03:55:48PM +0700, Nguyễn Thái Ngọc Duy wrote:

> This is something else that's been sitting in my tree for a while now.
> It adds "git list-files", intended to be aliased as "ls" with your
> favourite display options.

When I read the subject, I thought "why isn't this called git-ls?". Then
when I read this paragraph, I thought "if the point is for everybody to
make their own ls alias, why do we need list-files at all, instead of
just adding options to ls-files"?

I'll let you decide which (if any) you'd like to answer. :)

My guesses:

  1. If it were "git-ls", it would stomp on existing aliases people have
     constructed.

  2. If it is a wrapper around ls-files, then the options may be
     constrained; ls-files already squats on useful options like "-d"
     (which, if we are matching traditional ls, is more like our "-t").

I somewhat feel like (1) can be mitigated by the fact that your command
is what people were probably trying to approximate with their aliases,
and that as porcelain it should be very configurable (so they should be
able to accomplish the same things as their aliases). But I dunno. I do
not have an "ls" alias, so I am biased. :)

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).

-Peff

  parent reply	other threads:[~2014-12-02  5:42 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 [this message]
2014-12-02 11:45   ` Duy Nguyen
2014-12-02 20:18     ` Jeff King
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=20141202054226.GA1948@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 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 NNTP newsgroup(s).