[I noticed only just now that you only sent this to me. Accidentally
I suppose?]
On Monday 08 February 2010 20:10:40 Junio C Hamano wrote:
>
> This obviously was meant to be used with the full tree recorded by a
> commit and what you are seeing (e.g. cd to "valgrind" that is not even
> tracked, and pretend HEAD:t were the full contents---the full contents of
> the tree limited to the work tree location "valgrind" is shown) is an
> artifact of that.
>
> I think the right solution is along the lines of --full-tree option to
> allow people (i.e. scripts) to ask for the exact tree contents without any
> funny path limiting based on the location in the work tree. They can
> apply whatever path limiting from the command line, e.g. by running
>
> git ls-tree --full-tree HEAD:t valgrind
>
> instead of running
>
> mkdir -p valgrind && cd valgrind && git ls-tree HEAD:t
>
> when they want to apply path limit to the ls-tree output.
I guess in the (very) long run, the scripts should be forced to always
use --full-tree so that we can eventually make it the default?
I'm just not sure how the existing behaviour could ever be useful,
though admittedly 'git ls-tree $(git write-tree)' would change
semantics if you're in a subdirectory.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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