Junio C Hamano <junkio@xxxxxxx> wrote: > Output from ls-tree and ls-files -s are primarily for script > consumption. diff-raw output which already has abbrev is also > primarily for scripts, but we have an excuse there that human > eyes can spot differences easier in abbreviated form and two > values on the same row being different is the only information > we are conveying in "git whatchanged" default output, and not > abbreviating the object names makes pathnames pushed to far > right of the display which will be chopped by "less -S". > > So I am not quite sure if I should take this, and a subsequent > one you would probably send for ls-files ;-). I've never used ls-files with -s, but it's a simple patch on its way :> > Care to point out a use case I might have missed that this is > useful? I've never done ls-tree to be read by _me_ (not by > script) unless I am debugging ls-tree itself. I'm a weirdo and I use vim as a repository browser: (ref: http://www.gelato.unsw.edu.au/archives/git/0511/13088.html , I've since renamed my 'git-show' script to 'git-cat-any'). My usual buffer width is 80 columns. So when I want to see a file from a certain tree that's not checked out: I'll run git-ls-tree -r <tree> and output it to my vim buffer, find the corresponding sha1 for the file, and hit my ',G' macro with my cursor over the blob sha1 to display its contents. Abbreviating the sha1 is very useful for seeing longer file paths on an 80 column buffer. -- Eric Wong - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html