Re: [PATCH v3 1/2] Fix misconversion of gitsubmodule.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Beller <sbeller@xxxxxxxxxx> writes:

> On Thu, Feb 22, 2018 at 12:52 AM, marmot1123 <marmot.motoki@xxxxxxxxx> wrote:
>> In the 2nd and 4th paragraph of DESCRIPTION, there ware misconversions `submodule’s`.
>> It seems non-ASCII apostrophes, so I rewrite ASCII apostrophes.
>>
>> Signed-off-by: Motoki Seki <marmot.motoki@xxxxxxxxx>
>> ---
>>  Documentation/gitsubmodules.txt | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
>> index 46cf120f666df..0d59ab4cdfb1c 100644
>> --- a/Documentation/gitsubmodules.txt
>> +++ b/Documentation/gitsubmodules.txt
>> @@ -24,7 +24,7 @@ On the filesystem, a submodule usually (but not always - see FORMS below)
>>  consists of (i) a Git directory located under the `$GIT_DIR/modules/`
>>  directory of its superproject, (ii) a working directory inside the
>>  superproject's working directory, and a `.git` file at the root of
>> -the submodule’s working directory pointing to (i).
>> +the submodule's working directory pointing to (i).
>>
>>  Assuming the submodule has a Git directory at `$GIT_DIR/modules/foo/`
>>  and a working directory at `path/to/bar/`, the superproject tracks the
>> @@ -33,7 +33,7 @@ in its `.gitmodules` file (see linkgit:gitmodules[5]) of the form
>>  `submodule.foo.path = path/to/bar`.
>>
>>  The `gitlink` entry contains the object name of the commit that the
>> -superproject expects the submodule’s working directory to be at.
>> +superproject expects the submodule's working directory to be at.
>>
>>  The section `submodule.foo.*` in the `.gitmodules` file gives additional
>>  hints to Gits porcelain layer such as where to obtain the submodule via
>>
>> --
>> https://github.com/git/git/pull/459

Forgot to say something of your own?  Perhaps wanted to (1) show a
sample of a better log message, (2) say "Acked-by", (3) re-raise the
point that the same "error" already appears in the same file and it
is better to clean them up all at once, or (4) something else?






[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux