git-ls-files -l

Beginners, finding git-ls-files acts like ls, are baffled as to why they can't go on to ls -l.

The git-ls-files man page should reveal the secret of how also to see file sizes. Perhaps the closest one can get is $ git-ls-tree -l --abbrev ...

jidanni@jidanni.org writes:

git-ls-tree has the '-l' option mimicking (somewhat) "ls -l" behaviour only because it was thought to be useful for gitweb (to have file sizes in 'tree' view, like cgit has it), although gitweb doesn't use it yet.

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.

On Tue, 30 Dec 2008, Jakub Narebski wrote:

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.

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

			Linus

On Tue, 30 Dec 2008, Linus Torvalds wrote:

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

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.