Thread (5 messages) flat view 5 messages, 2 authors, 2016-06-15

Re: [PATCH] Create a new manpage for the gitignore format, and reference it elsewhere

From: Josh Triplett <hidden>
Date: 2016-06-15 22:43:13

Frank Lichtenheld wrote:
On Fri, Jun 01, 2007 at 03:20:52PM -0700, Josh Triplett wrote:
quoted
Signed-off-by: Josh Triplett <redacted>
Signed-off-by: Josh Triplett <redacted>
:) (Wanted to make some funny remark, but its too late here to be funny
in a foreign language...)
Argh.  git-commit -s --amend signed a second time.  Sorry I missed this.
quoted
 Documentation
 --------------
-Documentation by David Greaves, Junio C Hamano and the git-list [off-list ref].
+Documentation by David Greaves, Junio C Hamano, Josh Triplett, and the git-list [off-list ref].
No offence, but adding your name here for removing content? ;)
I intentionally avoided adding my name to the pages in which I only removed
content, or only added a reference to gitignore(5).  In the case of
git-ls-files, I rewrote some of the material.  However, I don't care that
strongly about the credit.
quoted
+Some git plumbing tools, such as git-ls-files(1) and
+git-read-tree(1), read `gitignore` patterns specified by
+command-line options, or from files specified by command-line
+options.
Missing gitlink:
Ah, good point.
Also I don't like the paragraph. It should probably mention that
these programs actually implement the behaviour described, that
they aren't hardcoded to the mentioned filenames and that
all git porcelain just happens to call them with them.
That seems like an implementation detail, only relevant to users of
git-ls-files and git-read-tree.
quoted
+Patterns have the following format:
+
+ - A blank line matches no files, so it can serve as a separator
+   for readability.
+
+ - A line starting with # 
Is here missing something?
Oops.  Yes, this should have said:

- A line starting with # serves as a comment.
quoted
+ - Otherwise, git treats the pattern as a shell glob suitable
+   for consumption by fnmatch(3) with the FNM_PATHNAME flag: any
+   slash in the pattern must match a slash in the pathname.  For
+   example, "Documentation/\*.html" matches
+   "Documentation/git.html" but not "ppc/ppc.html".  A leading
+   slash matches the beginning of the pathname; for example,
+   "/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c".
I realise this is copy&paste but shouldn't that read:
"Documentation/\*.html" matches "Documentation/git.html"
but not "Documentation/ppc/ppc.html"
?
I don't know.  Neither file seems to exist in current Git.
quoted
+Documentation
+-------------
+Documentation by Josh Triplett.
No offence again, but given the amount of copy&paste, maybe the names from
git-ls-files should also be added here.
Entirely correct; I don't know why I missed that, as I had intended to copy those
names. My apologies.

Expect an updated patch shortly, to fix the issues you pointed out.

- Josh Triplett

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help