From: Thomas Rast <trast@student.ethz.ch>
Date: Sun, 14 Feb 2010 16:33:52 GMT
Subject: Re: [RFC PATCH] ls-tree: dump full tree if it was named as such
Message-ID: <201002141733.53137.trast@student.ethz.ch>
In-Reply-To: <7vpr4fo85r.fsf@alter.siamese.dyndns.org>

[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