# git-ls-files -l 4 messages from 2008-12-29 to 2008-12-30. Participants: jidanni@jidanni.org, Jakub Narebski, Linus Torvalds. Thread: https://gitlist.dev/t/16915 ## jidanni@jidanni.org, 2008-12-29 17:07 Subject: git-ls-files -l Message-ID: <87abae6hbn.fsf@jidanni.org> URL: https://gitlist.dev/e/87abae6hbn.fsf%40jidanni.org ``` 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 ... ``` ## Jakub Narebski, 2008-12-30 11:01 Subject: Re: git-ls-files -l Message-ID: URL: https://gitlist.dev/e/m3wsdiaptg.fsf%40localhost.localdomain In-Reply-To: <87abae6hbn.fsf@jidanni.org> ``` 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 ``` ## Linus Torvalds, 2008-12-30 20:32 Subject: Re: git-ls-files -l Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.0812301226110.3082%40localhost.localdomain In-Reply-To: ``` 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 ``` ## Jakub Narebski, 2008-12-30 21:47 Subject: Re: git-ls-files -l Message-ID: <200812302247.40872.jnareb@gmail.com> URL: https://gitlist.dev/e/200812302247.40872.jnareb%40gmail.com In-Reply-To: ``` 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 ```