Junio C Hamano <gits...@pobox.com> wrote:
 |Steffen Nurpmeso <stef...@sdaoden.eu> writes:
 |Sorry, but I did not notice that there was an attached patch when I
 |was reading your response for the first time.  Risk of using an
 |attachment to e-mail ;-)
 |I think this issue does not need a separate bullet point.  The
 |existing text says:
 |and what caused your surprise is already covered by the first bullet
 |point, if the reader knows what "patterns to match" means in Git's
 |command line tools; it just needs to be extended to be more
 |meaningful to those who don't, I think.
 |How about rewriting the first bullet point like so instead:
 |  - the behaviour is different from that of "/bin/ls" in that the
 |    '<path>' are actually patterns to match, e.g. so specifying
 |    directory name (without `-r`) will behave differently, the order
 |    of the arguments does not matter, and a '<path>' argument that
 |    does not match any path is not an error (i.e. if there is no
 |    path that matches any pattern, nothing is shown in the output).

Not an error would have been an enlightenment to me.

But now i'm even getting nervous to read about patterns.
We have patterns for tags/remotes/branches, author/committer/grep
patterns, (most of those, maybe all today, with fixed string,
extended or basic regex), the git-grep patterns ("leading paths
match and glob(7) patterns are supported").  Is that all?
I would assume glob-style for ls-tree:

  ?0[steffen@wales ]$ git ls-tree HEAD `ls mime*`
  100644 blob ee47419c209da789b606ab6d979c22f4ae632712    mime.c
  100644 blob 0cfe3766bd5f035eac06b728a4f63224455e13ca    mime.types
  100644 blob 7d890df7553522691ed09f266ea7f9effb6a2f4e    mime_enc.c
  100644 blob 430e300d9a8887c5cd48d1cc63034168e47e9721    mime_param.c
  100644 blob 0338a46d3247ea00b5bcedb2d82ff30fe5d18d48    mime_parse.c
  100644 blob d62fa8defae27240a5ce81ad2239dd7f94b6c5c5    mime_types.c
  ?0[steffen@wales ]$ git ls-tree HEAD 'mime*'
  ?0[steffen@wales ]$ git ls-tree HEAD 'mime.*'

No, ls-tree is not part of what i use every day, "Git's command
line tools" is (too) wide afield, in that sense.

Thank you (also in general, for git), and ciao from a country with
a pretty real autumn,


Reply via email to