Docfix.
* mr/doc-can-not-to-cannot:
doc: typo: s/can not/cannot/ and s/is does/does/
instead be left unreferenced in the repository.
+
Due to the non-quarantine nature of the `fetch.fsckObjects`
-implementation it can not be relied upon to leave the object store
+implementation it cannot be relied upon to leave the object store
clean like `receive.fsckObjects` can.
+
As objects are unpacked they're written to the object store, so there
'git-cvsserver' write access to the database file without granting
them write access to the directory, too.
-The database can not be reliably regenerated in a
+The database cannot be reliably regenerated in a
consistent form after the branch it is tracking has changed.
Example: For merged branches, 'git-cvsserver' only tracks
one branch of development, and after a 'git merge' an
the local repository by fetching from the branches (respectively)
`pu` and `maint` from the remote repository.
+
-The `pu` branch will be updated even if it is does not fast-forward,
+The `pu` branch will be updated even if it does not fast-forward,
because it is prefixed with a plus sign; `tmp` will not be.
* Peek at a remote's branch, without configuring the remote in your local
----
Using --recurse-submodules can only fetch new commits in already checked
out submodules right now. When e.g. upstream added a new submodule in the
-just fetched commits of the superproject the submodule itself can not be
+just fetched commits of the superproject the submodule itself cannot be
fetched, making it impossible to check out that submodule later without
having to do a fetch again. This is expected to be fixed in a future Git
version.
----
Using --recurse-submodules can only fetch new commits in already checked
out submodules right now. When e.g. upstream added a new submodule in the
-just fetched commits of the superproject the submodule itself can not be
+just fetched commits of the superproject the submodule itself cannot be
fetched, making it impossible to check out that submodule later without
having to do a fetch again. This is expected to be fixed in a future Git
version.
[[def_object]]object::
The unit of storage in Git. It is uniquely identified by the
<<def_SHA1,SHA-1>> of its contents. Consequently, an
- object can not be changed.
+ object cannot be changed.
[[def_object_database]]object database::
Stores a set of "objects", and an individual <<def_object,object>> is
do not do this you will get an error for each ref that it does not point
to a valid object.
-Note: As a side-effect of this you can not safely assume that all
+Note: As a side-effect of this you cannot safely assume that all
objects you lookup are available in superproject. All submodule objects
will be available the same way as the superprojects objects.