Skip to content

Commit 9d5fbe6

Browse files
committed
Capitalize Git, per @pawamoy
1 parent 29cc38a commit 9d5fbe6

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

source/discussions/downstream-packaging.rst

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -69,16 +69,16 @@ source distributions may include:
6969

7070
- having a consistent build process across all Python packages
7171

72-
While it is usually possible to build packages from a git repository, there are
72+
While it is usually possible to build packages from a Git repository, there are
7373
a few important reasons to provide a static archive file instead:
7474

7575
- Fetching a single file is often more efficient, more reliable and better
76-
supported than e.g. using a git clone. This can help users with poor
76+
supported than e.g. using a Git clone. This can help users with poor
7777
Internet connectivity.
7878

7979
- Downstreams often use hashes to verify the authenticity of source files
8080
on subsequent builds, which require that they remain bitwise identical over
81-
time. For example, automatically generated git archives do not guarantee
81+
time. For example, automatically generated Git archives do not guarantee
8282
this, as the compressed data may change if gzip is upgraded on the server.
8383

8484
- Archive files can be mirrored, reducing both upstream and downstream
@@ -88,7 +88,7 @@ a few important reasons to provide a static archive file instead:
8888

8989
- Explicitly publishing archive files can ensure that any dependencies on version control
9090
system metadata are resolved when creating the source archive. For example, automatically
91-
generated git archives omit all of the commit tag information, potentially resulting in
91+
generated Git archives omit all of the commit tag information, potentially resulting in
9292
incorrect version details in the resulting builds.
9393

9494
How?
@@ -108,7 +108,7 @@ separate archives.
108108

109109
A good idea is to **use your source distribution in the release workflow**.
110110
That is, build it first, then unpack it and perform all the remaining steps
111-
using the unpacked distribution rather than the git repostiry — run tests,
111+
using the unpacked distribution rather than the Git repostiry — run tests,
112112
build documentation, build wheels. This ensures that it is well-tested,
113113
and reduces the risk that some users would hit build failures or install
114114
an incomplete package.

0 commit comments

Comments
 (0)