Hi, On 12/15/06, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
Hi, On Fri, 15 Dec 2006, Nguyen Thai Ngoc Duy wrote: > On 12/14/06, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > > - have you seen the patch for git-show today, which would include this > > > > functionality? > > > > > > I didn't. From the patch, it seems git-show can show the index via > > > ::file syntax. If so, I'd like withdraw my opinion. '::file' syntax is > > > not intuitive though. Perhaps you should mention that it can show > > > index (and how) in the git-show document > > > > Well, you can reference blobs that way, but not trees. > > Oh, yeah. Isn't this a good oppotunity to add --index option to git-show? > git-show --index will show the index. git-show --index file will show > the file content. This makes git-show a little unconsistent though as > it may or may not require argument <object>. > > Another option is treat '::' alone specially -- call git-ls-files. Hmm. I don't know... It would make the code rather messy. And are you really interested in the content stored in the index? In all cases I can think of, you are better off with a diff vs. working directory or ref.
When I worked with index the first time, I had difficulty knowing what was in index. Index is, unlike working directory, intangible. I could use git-diff (and actually did), but it was still better if I could have seen what exactly was in index. To me, index and object database are (to some extent) the same: both are used to store files. If I can examine git object database, why not index? About adding index support to git-show, yes it's really messy. index doesn't have tree objects. If a user wants to list a subdirectory in index, git-show will have to do more work, I think. Perhaps we should forget this for now. -- Duy - To unsubscribe from this list: 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