Re: [RFC PATCH] ls-tree: dump full tree if it was named as such

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 15, 2010, 01:47 UTC
Message-ID: <7vy6iv46e3.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201002141733.53137.trast@student.ethz.ch>

Thomas Rast <trast@student.ethz.ch> writes:

Show 6 quoted lines

> 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.

Hysterical raisins. I am reasonably sure that it behaves for end-user convenience and consistency while running these from the command line:

    $ cd t
    $ git ls-files
    $ git ls-tree HEAD

The --full-tree option came as an afterthought much later to help Porcelain scripts, that had to cd-up-to-top to get to the full tree contents.

The order of events and historical backstory does not matter.

The Porcelain scripts have learned to either (1) going to top before running, or (2) giving --full-tree when they want to see a full tree output, but at the same time they also learned that (3) running the command without --full-tree will give them the contents of the tree that corresponds to where the current directory is in the work tree.

All three are documented plumbing interfaces---not just the first two points. I haven't seen any good excuse to break the third promise with Porcelain scripts. I didn't find one myself when I did d4789c6 (ls-tree: add --full-tree option, 2008-12-25) long time ago.

So even in "(very) long run" nothing will happen. I was about to write "except documenting them better, perhaps", but after re-reading the introductory paragraphs of the manual page, I don't think anything more needs to be said there.