From: Junio C Hamano <gitster@pobox.com>
Date: Sat, 12 Feb 2011 00:40:04 GMT
Subject: Re: [PATCH v3] fast-import: add 'ls' command
Message-ID: <7vlj1mytjv.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110211224339.GA9973@elie>

Jonathan Nieder <jrnieder@gmail.com> writes:

> From: David Barr <david.barr@cordelta.com>
> 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.