summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 17cf250)
raw | patch | inline | side by side (parent: 17cf250)
author | Francis Daly <francis@daoine.org> | |
Wed, 7 Jun 2006 12:56:45 +0000 (13:56 +0100) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Wed, 7 Jun 2006 18:49:35 +0000 (11:49 -0700) |
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>
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>
index c861c6ce17f79e78e5b0fb6f61a5419d143fd369..4ce78679fed2f617ff3dd808ede061f5a94efff9 100644 (file)
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
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
- over HTTPS. Can be overriden by the 'GIT_SSL_CERT' environment
+ over HTTPS. Can be overridden by the 'GIT_SSL_CERT' environment
variable.
http.sslKey::
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::
index 826d0897e2fd2ad2f63677b477c9e1e0f62337ae..1fbca83141e20599e4d6edd880b1cabbf0cd9913 100644 (file)
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:
------------------------------------------------
index 6745ab5fc5a1f1262edb9e2563627831b4b7f4bd..b935c180881571a964356e63a2e718c2721b5e6b 100644 (file)
* 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.
index 3ea720dd005f7a9b4a66a419cf5438a3a7d0fa8b..13a5f43049c25e1df3bcbcbbed482acce0cebc8b 100644 (file)
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;
index 7a253eaf284ab8effc7138f91ba6236a4f05dfdd..2700f35bdb6ec7aae9520eca0d21bcf5089bc750 100644 (file)
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
index ffaa00468f0c16f19ab632aac20aaa74db52b325..39a1434a0e6be3c07852dc0919536bc63551a3dd 100644 (file)
SYNOPSIS
--------
-'git-name-rev' [--tags] ( --all | --stdin | <commitish>... )
+'git-name-rev' [--tags] ( --all | --stdin | <committish>... )
DESCRIPTION
-----------
index b8ff1e9bdebf04132a5b7dc85305ce0a20e95e09..c198ff2502d95be4dc1baadd6479b687acb0caa1 100644 (file)
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
index 02c7e99fe6f6e49a5a0e03da7444bc559502585c..d894f537ba2634ed2719ee746b170a22f0173f56 100644 (file)
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"`
index e3dde39190d7f69b2ca2482763a643d33f772b07..898b4aaf80aabe8caa9675c4371918a61312f1cb 100644 (file)
--- a/Documentation/hooks.txt
+++ b/Documentation/hooks.txt
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
index db563127b236757de62be50a4e04439eddf2729e..554ee0af912368cb842d93c025e742daaf47f5f2 100644 (file)
$ 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