gitignore: ignore comments on the same line as a pattern

[cbzehner]

Why make this change?

Add the ability to use # to put comments after ignore patterns. This is
useful for documenting the reason for particular ignore patterns inclusion
and structure.

Right now a common convention in .gitignore files is to group patterns
by similarity using new lines beginning with one or more # characters
as headings.

When leaving comments about a particular pattern it can be difficult to
distinguish comments about a single patterns from comments used for file
organization.

Comments left after a pattern are unambiguously related to that line, and
that line only.

What should this change do?

Any part of a string after a non-escaped #, including the #, is removed
from the pattern.

Why make the change this way?

I don't normally write C, so I probably overlooked more idiomatic ways
to do this. This is done similarly to the way trim_trailing_spaces removes
extraneous spaces from patterns.

How can we test this change works?

That's one area I'd like help with, please.

Test cases:

/pattern/to/match
# Existing comment
/pattern/with/comment # This comment is ignored
/pattern/with/\#octothorpe # \#octothorpe is ignored

I wasn't sure where the correct place to add these would be, I didn't see (and
potentially overlooked) any tests in /t/* that cover this functionality. Would
someone be willing to provide a pointer to the correct place to add these tests?

Signed-off-by: Chris Zehner cbzehner@gmail.com

[dscho]

Thank you for your contribution!

Please make sure that your commit message focuses on answering the question "why?" more than on "how?", and that it wraps at <= 76 columns per line.

Finally send the patch to the mailing list for review. You can use GitGitGadget, submitGit or send it manually.

[cbzehner]

Thanks for the feedback @dscho! I'll submit this next week, but if you have any further feedback in the meantime I'd appreciate it!

[giuscri]

This function is very similar to trim_trailing_spaces(). l don't think logic should be put at all costs in one single function, but it's worth thinking if they can be merged somehow.

[dscho]

@cbzehner gentle ping?

[cbzehner]

Thanks for the reminder @dscho. I'll get this updated and out this week.

[cbzehner]

Updated onto the latest master branch and opened a PR on GitGitGadget gitgitgadget#370

Should I leave this PR open in the meantime or close this and continue my submission via gitgitgadget#370?

[dscho]

Should I leave this PR open in the meantime or close this and continue my submission via gitgitgadget#370?

My personal preference would be to close it here, as I am trying to reduce the number of PRs in https://github.com/git/git/pulls (so I regularly look through many open PRs here).

[cbzehner]

Sounds good. Thank you for your guidance!