Clemens Buchacher <drizzd@xxxxxx> writes:
> Signed-off-by: Clemens Buchacher <drizzd@xxxxxx>
> ---
> On Sun, Jul 31, 2011 at 05:01:22PM -0700, Junio C Hamano wrote:
>>
>> Sounds sane; tests?
>
> Certainly. I'm not testing partial commit since it uses the same
> codepath as ls-files --error-unmatch anyways.
>
> t/t3005-ls-files-relative.sh | 74 ++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 74 insertions(+), 0 deletions(-)
> create mode 100755 t/t3005-ls-files-relative.sh
Thanks. This should be a part of the primary patch, not a standalone patch.
> +test_expect_success 'prepare' '
> + : >never-mind-me &&
> + git add never-mind-me &&
> + mkdir top &&
> + (
> + cd top &&
> + mkdir sub &&
> + x="x xa xbc xdef xghij xklmno" &&
> + y=$(echo "$x" | tr x y) &&
> + touch $x &&
> + touch $y &&
These are not meant to be quoted; good.
> + cd sub &&
> + git add ../x*
> + )
> +'
> +
> +test_expect_success 'ls-files with mixed levels' '
> + (
> + cd top/sub &&
> + f=$(cat <<-EOF
> + ../../never-mind-me
> + ../x
> + EOF
> + ) &&
> + echo "$f" >expect &&
> + git ls-files $f >actual &&
This is a funny way to do this; why not cat the here-document into expect
and feed $(cat expect) to ls-files? I suspect that it would become easier
to read and certainly less confusing without need on the readers' side to
scratch their heads wondering "does this $f need to be quoted?" and such.
> +test_expect_success 'ls-files -c' '
> + (
> + cd top/sub &&
> + for f in ../y*
> + do
> + echo "error: pathspec ${sq}${f}${sq} did not match any file(s) known to git."
Why not $sq$f$sq? The above looks harder to read with the braces.
> + set ../x* &&
> + IFS="$new_line" && echo "$*" >>expect && unset IFS &&
That's a funny way to say "ls ../x*" isn't it?
--
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