From: Junio C Hamano <junkio@cox.net>
Date: Mon, 28 Nov 2005 10:51:11 GMT
Subject: Re: [PATCH 6/8] ls-tree: work from subdirectory.
Message-ID: <7v3blhvye8.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7v64qdyxxx.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

> So let's cook this for a while and have Porcelain people holler
> if they find something lacking.  I'll put this in the proposed
> updates tonight, and we will plan to push everything in the
> proposed updates branch to the master branch on Wednesday, with
> any fixes and updates necessary.

OK, so I did some tests adjustments (they are in "pu").  Most
differences are easily explained but some are not.

Easy ones:

    - With -r, tree entries are not shown.

    - Unlike /bin/ls arguments, the paths are now filters, so
      no duplicates on the output, nor the output order does not
      depend on command line argument order.

    - "path" shows the tree if path corresponds to a directory;
      say "path/" to get its contents.

However I do not have an easy way to explain how these two work
the way they do.  Taken from t/t3101 test.

The first one has both path0/a/b/c and path0/a in the filter,
and path0/a tree entry itself is not shown because it "recurses
through it".

+# I am not so sure about this one after ls-tree doing pathspec match.
+# Having both path0/a and path0/a/b/c makes path0/a redundant, and
+# it behaves as if path0/a/b/c, path1/b/c, path2 and path3 are specified.
 test_expect_success \
     'ls-tree filter directories' \
     'git-ls-tree $tree path3 path2 path0/a/b/c path1/b/c path0/a >current &&
      cat >expected <<\EOF &&
-040000 tree X	path3
-100644 blob X	path3/1.txt
-100644 blob X	path3/2.txt
-040000 tree X	path2
-100644 blob X	path2/1.txt
 040000 tree X	path0/a/b/c
-100644 blob X	path0/a/b/c/1.txt
 040000 tree X	path1/b/c
-100644 blob X	path1/b/c/1.txt
-040000 tree X	path0/a
-040000 tree X	path0/a/b
+040000 tree X	path2
+040000 tree X	path3
 EOF
      test_output'

The second one is the same; since there is path3/, it recurses
through it and path3 itself is not shown but its contents are.
It is showing both path3/1.txt and path3/2.txt not because
path3/1.txt is specified but path3/ was specified.

+# Again, duplicates are filtered away so this is equivalent to
+# having 1.txt and path3/
 test_expect_success \
     'ls-tree filter odd names' \
     'git-ls-tree $tree 1.txt /1.txt //1.txt path3/1.txt /path3/1.txt //path3//1.txt path3 /path3/ path3// >current &&
      cat >expected <<\EOF &&
 100644 blob X	1.txt
-100644 blob X	1.txt
-100644 blob X	1.txt
-100644 blob X	path3/1.txt
-100644 blob X	path3/1.txt
-100644 blob X	path3/1.txt
-040000 tree X	path3
-100644 blob X	path3/1.txt
-100644 blob X	path3/2.txt
-040000 tree X	path3
-100644 blob X	path3/1.txt
-100644 blob X	path3/2.txt
-040000 tree X	path3
 100644 blob X	path3/1.txt
 100644 blob X	path3/2.txt
 EOF