git-ls-files -l

git-ls-files -l

[jidanni]

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

Re: git-ls-files -l

[Jakub Narebski]

jidanni@jidanni.org writes:

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

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.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: git-ls-files -l

[Linus Torvalds]

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.

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

Re: git-ls-files -l

[Jakub Narebski]

On Tue, 30 Dec 2008, Linus Torvalds wrote:
> 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