Re: git-ls-files -l

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 30, 2008, 21:47 UTC
Message-ID: <200812302247.40872.jnareb@gmail.com>
In-Reply-To: <alpine.LFD.2.00.0812301226110.3082@localhost.localdomain>

On Tue, 30 Dec 2008, Linus Torvalds wrote:

Show 19 quoted lines

> On Tue, 30 Dec 2008, Jakub Narebski wrote:
> > 
> > I think it would be easy to add '-l' also to git-ls-files. Please
> > remember to provide size only for blobs, as provoding size for trees
> > would make it harder to change to future packv4, where tree objects
> > would be stored deconstructed.
> 
> Personally, more than "git ls-files -l", I've occasionally wanted a real 
> "git ls" that really looks more like "ls". That includes:
> 
>  - turning a list of files in a subdirectory into a "directory" entry 
>    (which is not very natural for "git ls-files" as an index operation, 
>    since the index is fundamentally flat).
> 
>  - yes, adding "-l" as an option, but really showing the stat information. 
>    Right now, you can do "git ls-files --stage", and it will show a kind 
>    of extended information, but while it shows the mode, it doesn't show 
>    the owner/timestamp/etc parts of the index, and those are sometimes 
>    interesting.

Good idea.

I guess we could put shortened sha-1 of object in place of owner and group info which is not present in index, and perhaps stage number instead of number of hard links. I wonder a bit about formatting timestamps, if to follow "ls -l" format there...

> Btw, the "ls-tree -l" format is not nice. Don't use it as a basis 
> to pattern "ls -l" (or if you want to just extend ls-tree, whatever).

Well, "ls-tree -l" is just "ls-tree" with size added. You would probably want to use "git ls-tree -l --abbrev" instead for human consumption.

-- 
Jakub Narebski
Poland