Re: [PATCH 00/19] Add git-list-files

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Dec 2, 2014, 12:40 UTC
Message-ID: <547DB325.6030500@drmicha.warpmail.net>
In-Reply-To: <20141202054226.GA1948@peff.net>

Jeff King schrieb am 02.12.2014 um 06:42:

Show 34 quoted lines

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

I'd like to second all that ("+1", "like").

User friendly listing of files in the git repo is dearly needed, and following names and default behaviour of mv/cp/ls is a way to follow the principle of least surprise.

While "ls" might be an alias for many, I'm sure "stage" was for quite a few people, too. We should be able to take any new name for new command, regardless of aliases people may be using.

Allowing to alias at least porcelain commands, at least to the extent of adding default options, is something we've talked about before and which would have prevented us from the increasing bloat by the default changing config knobs. "git -c ..." somehow took us down the other road.

I'm still dreaming of a git future where either "git foo --bar=baz" is equivalent to "git -c foo.bar=baz foo" (i.e. unify the naming), or we are simply able to alias "foo" to "foo --bar=baz" if that is what we like as default (i.e. get rid of many of the special config knobs).

Right now, we have two "sets of options" with often differing names.

Also, we could ship a few commonly used aliases (such as co=checkout, ci=commit, st=status) which could be overriden easily.

Michael