Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:
> 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.
--
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