All should be clear enough, except perhaps committish / commitish.
I just kept the more-used one within the current docs.
[jc: with rephrasing of check-ref-format description later discussed
on the list]
Signed-off-by: Francis Daly <francis@daoine.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
http.sslVerify::
Whether to verify the SSL certificate when fetching or pushing
http.sslVerify::
Whether to verify the SSL certificate when fetching or pushing
- over HTTPS. Can be overriden by the 'GIT_SSL_NO_VERIFY' environment
+ over HTTPS. Can be overridden by the 'GIT_SSL_NO_VERIFY' environment
variable.
http.sslCert::
File containing the SSL certificate when fetching or pushing
variable.
http.sslCert::
File containing the SSL certificate when fetching or pushing
- over HTTPS. Can be overriden by the 'GIT_SSL_CERT' environment
+ over HTTPS. Can be overridden by the 'GIT_SSL_CERT' environment
http.sslCAPath::
Path containing files with the CA certificates to verify the peer
http.sslCAPath::
Path containing files with the CA certificates to verify the peer
- with when fetching or pushing over HTTPS. Can be overriden
+ with when fetching or pushing over HTTPS. Can be overridden
by the 'GIT_SSL_CAPATH' environment variable.
http.maxRequests::
by the 'GIT_SSL_CAPATH' environment variable.
http.maxRequests::
they create are writable and searchable by other group members.
Suppose this repository is now set up in /pub/repo.git on the host
they create are writable and searchable by other group members.
Suppose this repository is now set up in /pub/repo.git on the host
-foo.com. Then as an individual commiter you can clone the shared
+foo.com. Then as an individual committer you can clone the shared
repository:
------------------------------------------------
repository:
------------------------------------------------
* gitlink:git-fsck-objects[1] to validate the repository.
* gitlink:git-fsck-objects[1] to validate the repository.
- * gitlink:git-prune[1] to garbage collect crufts in the
+ * gitlink:git-prune[1] to garbage collect cruft in the
repository.
* gitlink:git-repack[1] to pack loose objects for efficiency.
repository.
* gitlink:git-repack[1] to pack loose objects for efficiency.
a tag is stored under `$GIT_DIR/refs/tags` directory. git
imposes the following rules on how refs are named:
a tag is stored under `$GIT_DIR/refs/tags` directory. git
imposes the following rules on how refs are named:
-. It could be named hierarchically (i.e. separated with slash
- `/`), but each of its component cannot begin with a dot `.`;
+. It can include slash `/` for hierarchical (directory)
+ grouping, but no slash-separated component can begin with a
+ dot `.`;
. It cannot have two consecutive dots `..` anywhere;
. It cannot have two consecutive dots `..` anywhere;
OPTIONS
-------
<committish>::
OPTIONS
-------
<committish>::
- The object name of the comittish.
+ The object name of the committish.
--all::
Instead of using only the annotated tags, use any ref
--all::
Instead of using only the annotated tags, use any ref
-'git-name-rev' [--tags] ( --all | --stdin | <commitish>... )
+'git-name-rev' [--tags] ( --all | --stdin | <committish>... )
Perforce number, eg. git show p4/327.
The tag associated with the HEAD commit is also how `git-p4import`
Perforce number, eg. git show p4/327.
The tag associated with the HEAD commit is also how `git-p4import`
-determines if their are new changes to incrementally import from the
+determines if there are new changes to incrementally import from the
Perforce repository.
If you import from a repository with many thousands of changes
Perforce repository.
If you import from a repository with many thousands of changes
This is done to prevent you from losing your work-in-progress
changes, and mixing your random changes in an unrelated merge
commit. To illustrate, suppose you start from what has been
This is done to prevent you from losing your work-in-progress
changes, and mixing your random changes in an unrelated merge
commit. To illustrate, suppose you start from what has been
-commited last to your repository:
+committed last to your repository:
----------------
$ JC=`git-rev-parse --verify "HEAD^0"`
----------------
$ JC=`git-rev-parse --verify "HEAD^0"`
This hook is invoked by `git-receive-pack` on the remote repository,
which is happens when a `git push` is done on a local repository.
Just before updating the ref on the remote repository, the update hook
This hook is invoked by `git-receive-pack` on the remote repository,
which is happens when a `git push` is done on a local repository.
Just before updating the ref on the remote repository, the update hook
-is invoked. It's exit status determines the success or failure of
+is invoked. Its exit status determines the success or failure of
the ref update.
The hook executes once for each ref to be updated, and takes
the ref update.
The hook executes once for each ref to be updated, and takes
$ git branch stable v2.5 # start a new branch named "stable" based
# at v2.5
$ git reset --hard HEAD^ # reset your current branch and working
$ git branch stable v2.5 # start a new branch named "stable" based
# at v2.5
$ git reset --hard HEAD^ # reset your current branch and working
- # directory its state at HEAD^
+ # directory to its state at HEAD^
-------------------------------------
Be careful with that last command: in addition to losing any changes
-------------------------------------
Be careful with that last command: in addition to losing any changes