Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > From: David Barr <david.barr@xxxxxxxxxxxx> > Date: Thu, 2 Dec 2010 21:40:20 +1100 > > Introduce an "ls" command to read directory entries from the active > commit or a named commit. This allows printing a blob from the active > commit or copying a blob or tree from a previous commit for use in the > current one. > > There are two forms of the 'ls' command: the two-argument form prints > the entry at <path> for the tree underlying the tree, commit, or tag > named by <dataref>: > > 'ls' SP <dataref> SP <path> LF > > The one-argument form prints the entry at <path> in fast-import's > active commit. > > 'ls' SP <path> LF Is this really "ls"? Obviously, an extended SHA-1 that is accepted by the normal git does not have a notion of "marks", but modulo that, the first one looks to me very similar to "rev-parse <ref>:<path>" in spirit, which suggests that "the path in the current one" might be better spelled as "rev-parse :<path>" to make the syntax and the concept more consistent across parts of the system. If it makes sense to allow arbitary <committish> (or <treeish> for that matter) for the <dataref> part of the parameter, this observation becomes even more true, no? Having said that, I do not deeply care about the token "ls" itself. I just reacted to "<dataref> SP <path>" part. > Dirty hack: for now, git fast-import will treat missing paths as empty > subtrees and print them as > > 040000 tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 path/to/nowhere > > to avoid confusing frontends that inserted such a path before. Sorry, but I am not quite sure what this paragraph is trying to say. -- 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