{"thread":{"id":"16915","subject":"git-ls-files -l","startedAt":"2008-12-29T17:07:24Z","lastAt":"2008-12-30T21:47:39Z","messageCount":4,"participants":["jidanni@jidanni.org","Jakub Narebski","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"98908","messageId":"87abae6hbn.fsf@jidanni.org","threadId":"16915","inReplyTo":null,"subject":"git-ls-files -l","fromName":"","fromEmail":"jidanni@jidanni.org","sentAt":"2008-12-29T17:07:24Z","receivedAt":"2008-12-29T17:07:24Z","isPatch":false,"sender":{"key":"jidanni@jidanni.org","avatar":"https://gravatar.com/avatar/36568d4af4c8d3e71627ef3b8c8d00e39065b12f29676cccd38ced75e68fa2a6?d=mp&s=160"},"body":"Beginners, finding git-ls-files acts like ls,\nare baffled as to why they can't go on to ls -l.\n\nThe git-ls-files man page should reveal the secret of how also to see\nfile sizes. Perhaps the closest one can get is\n$ git-ls-tree -l --abbrev ...\n"},{"id":"98959","messageId":"m3wsdiaptg.fsf@localhost.localdomain","threadId":"16915","inReplyTo":"87abae6hbn.fsf@jidanni.org","subject":"Re: git-ls-files -l","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-12-30T11:01:06Z","receivedAt":"2008-12-30T11:01:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"jidanni@jidanni.org writes:\n\n> Beginners, finding git-ls-files acts like ls,\n> are baffled as to why they can't go on to ls -l.\n> \n> The git-ls-files man page should reveal the secret of how also to see\n> file sizes. Perhaps the closest one can get is\n> $ git-ls-tree -l --abbrev ...\n\ngit-ls-tree has the '-l' option mimicking (somewhat) \"ls -l\" behaviour\nonly because it was thought to be useful for gitweb (to have file\nsizes in 'tree' view, like cgit has it), although gitweb doesn't use\nit yet.\n\nI think it would be easy to add '-l' also to git-ls-files. Please\nremember to provide size only for blobs, as provoding size for trees\nwould make it harder to change to future packv4, where tree objects\nwould be stored deconstructed.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"98990","messageId":"alpine.LFD.2.00.0812301226110.3082@localhost.localdomain","threadId":"16915","inReplyTo":"m3wsdiaptg.fsf@localhost.localdomain","subject":"Re: git-ls-files -l","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-12-30T20:32:20Z","receivedAt":"2008-12-30T20:32:20Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 30 Dec 2008, Jakub Narebski wrote:\n> \n> I think it would be easy to add '-l' also to git-ls-files. Please\n> remember to provide size only for blobs, as provoding size for trees\n> would make it harder to change to future packv4, where tree objects\n> would be stored deconstructed.\n\nPersonally, more than \"git ls-files -l\", I've occasionally wanted a real \n\"git ls\" that really looks more like \"ls\". That includes:\n\n - turning a list of files in a subdirectory into a \"directory\" entry \n   (which is not very natural for \"git ls-files\" as an index operation, \n   since the index is fundamentally flat).\n\n - yes, adding \"-l\" as an option, but really showing the stat information. \n   Right now, you can do \"git ls-files --stage\", and it will show a kind \n   of extended information, but while it shows the mode, it doesn't show \n   the owner/timestamp/etc parts of the index, and those are sometimes \n   interesting.\n\nBtw, the \"ls-tree -l\" format is not nice. Don't use it as a basis \nto pattern \"ls -l\" (or if you want to just extend ls-tree, whatever).\n\n\t\t\tLinus\n"},{"id":"98998","messageId":"200812302247.40872.jnareb@gmail.com","threadId":"16915","inReplyTo":"alpine.LFD.2.00.0812301226110.3082@localhost.localdomain","subject":"Re: git-ls-files -l","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-12-30T21:47:39Z","receivedAt":"2008-12-30T21:47:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 30 Dec 2008, Linus Torvalds wrote:\n> On Tue, 30 Dec 2008, Jakub Narebski wrote:\n> > \n> > I think it would be easy to add '-l' also to git-ls-files. Please\n> > remember to provide size only for blobs, as provoding size for trees\n> > would make it harder to change to future packv4, where tree objects\n> > would be stored deconstructed.\n> \n> Personally, more than \"git ls-files -l\", I've occasionally wanted a real \n> \"git ls\" that really looks more like \"ls\". That includes:\n> \n>  - turning a list of files in a subdirectory into a \"directory\" entry \n>    (which is not very natural for \"git ls-files\" as an index operation, \n>    since the index is fundamentally flat).\n> \n>  - yes, adding \"-l\" as an option, but really showing the stat information. \n>    Right now, you can do \"git ls-files --stage\", and it will show a kind \n>    of extended information, but while it shows the mode, it doesn't show \n>    the owner/timestamp/etc parts of the index, and those are sometimes \n>    interesting.\n\nGood idea.\n\nI guess we could put shortened sha-1 of object in place of owner and\ngroup info which is not present in index, and perhaps stage number\ninstead of number of hard links. I wonder a bit about formatting\ntimestamps, if to follow \"ls -l\" format there...\n\n> Btw, the \"ls-tree -l\" format is not nice. Don't use it as a basis \n> to pattern \"ls -l\" (or if you want to just extend ls-tree, whatever).\n\nWell, \"ls-tree -l\" is just \"ls-tree\" with size added. You would\nprobably want to use \"git ls-tree -l --abbrev\" instead for human\nconsumption.\n\n-- \nJakub Narebski\nPoland\n"}]}