| Message ID | 82e5e05288ded6394e562408507e3269c26e688a.1712366536.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | docs: recommend using contrib/contacts/git-contacts | expand |
"Linus Arver via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Linus Arver <linusa@google.com> > > Avoid splitting up the command over two lines. This way, a command like > > $ git grep git.contacts Documentation > > will return a positive hit for this location. > > Signed-off-by: Linus Arver <linusa@google.com> > --- > Documentation/SubmittingPatches | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches > index e734a3f0f17..a33fe7e11f6 100644 > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -494,8 +494,8 @@ mentioned below, but should instead be sent privately to the Git > Security mailing list{security-ml-ref}. > > Send your patch with "To:" set to the mailing list, with "cc:" listing > -people who are involved in the area you are touching (the `git > -contacts` command in `contrib/contacts/` can help to > +people who are involved in the area you are touching (the `git contacts` > +command in `contrib/contacts/` can help to > identify them), to solicit comments and reviews. Also, when you made > trial merges of your topic to `next` and `seen`, you may have noticed > work by others conflicting with your changes. There is a good possibility Sure. But I think a general rule to avoid writing documentation pages that require a fix-up like this patch would be more valuable in the longer term. Or investing in a better "grep" command ;-) In any case, this is an improvement, so let's queue it as-is.
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index e734a3f0f17..a33fe7e11f6 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -494,8 +494,8 @@ mentioned below, but should instead be sent privately to the Git Security mailing list{security-ml-ref}. Send your patch with "To:" set to the mailing list, with "cc:" listing -people who are involved in the area you are touching (the `git -contacts` command in `contrib/contacts/` can help to +people who are involved in the area you are touching (the `git contacts` +command in `contrib/contacts/` can help to identify them), to solicit comments and reviews. Also, when you made trial merges of your topic to `next` and `seen`, you may have noticed work by others conflicting with your changes. There is a good possibility