-
Notifications
You must be signed in to change notification settings - Fork 25.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tried to make slash-rules more readable #590
Conversation
(relative to the toplevel of the work tree if not from a | ||
`.gitignore` file). | ||
- If the pattern contains a slash '/' other then a trailing slash, | ||
it is always considered from the root. In other words, `foo/bar` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also suspect that "root" maybe a confused location. In Linux/*nix, root is a special place, while on Windows (Git-for-) root either doesn't exist (MS view), or could be anywhere (each bash has its own) depending on view point.
I think it actually means the location of the .gitignore file (and we can have many, repeated at many levels).
The whole .gitignore doc has a long history of confusion...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is true. Would you think its better to write "[...] is always considered from the location of the .gitignore
file"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'It' is certainly worth suggesting. Though maybe "the pattern is always considered from the .gitignore
file location".
Also note that Git PRs, by them selves, are ignored. Once the checks are OK, one can send them upstream by either send-email, or via gitgitgadget.
I believe the documentation failure maybe that there has bee an update of the toolset. see https://public-inbox.org/git/20190329123520.27549-6-szeder.dev@gmail.com/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your help. Does it mean I have to create a fork at https://github.com/gitgitgadget/gitgitgadget, and create a PR with the same content as in this PR? And about the documentation error, does it mean I simply have to wait till it gets fixed?
If you are able, you can do the (documentation) checks yourself by using the SDK to have a local build system and directly check that the output formats well in both man view and pdf/html view. If the SDK then direct submission via format-patch/send-email may be quickest. (do you already have the SDK?) I don't see that there is much to worry about for the CI failure in this case. Interacting with the upstream is probably more important. |
Hi @iwasherefirst2, The SDK (Software Development Kit) for https://gitforwindows.org/ is linked from the "Contribute" button on that page, should you wish to try that route. The FAQ link takes you to the wiki pages (user editable content) with more details. But go with what works for you. |
I guess that this PR is now abandoned in favor of https://public-inbox.org/git/20190602090415.5889-1-admin@in-ici.net/#r. Correct, @iwasherefirst2? |
Yes. I thought it doesn't matter if this is closed or not because of
|
True, true, but it does run the Azure Pipeline now, and I actually started looking at these PRs ;-) So I'd like only truly active PRs to be open. Thanks for closing this! |
As discussed in the mailing list, I hope this make the edited paragraphs more readable and clear.
Here are some posts that show what kind of problems people had to understand this part of the docs:
git/git-scm.com#1332
https://stackoverflow.com/a/41761521/2311074
https://stackoverflow.com/questions/50028104/claryfing-gitignore-documentation