* [PATCH v2 00/15] User manual updates
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <7vzjzexv8l.fsf@alter.siamese.dyndns.org>
From: "W. Trevor King" <wking@tremily.us>
This combines my ealier patches:
* user-manual: Rewrite git-gc section for automatic packing
* user-manual: Update for receive.denyCurrentBranch=refuse
With a number of additional fixups. Changes since v1:
* user-manual: Rewrite git-gc section for automatic packing:
- Reworded following suggestions from Junio. This removed the
phrase containing the 'comression' typo pointed out by Javier.
* user-manual: Update for receive.denyCurrentBranch=refuse
- No changes.
Most of the patches are well-focused, with the exception of
"Standardize backtick quoting". I can break this up into smaller
chunks (e.g. "Standardize backtick quoting in Chapter 1", "Standardize
backtick quoting in Chapter 2", …) if this is too much to bite off in
one patch.
I may add additional patches onto the end of this series as I make new
fixes and the series cooks on the list.
W. Trevor King (15):
user-manual: Rewrite git-gc section for automatic packing
user-manual: Update for receive.denyCurrentBranch=refuse
user-manual: Use 'remote add' to setup push URLs
user-manual: Use git branch --merged
user-manual: Add a few references to 'git rebase -i'
user-manual: Give 'git push -f' as an alternative to +master
user-manual: Mention 'git remote add' for remote branch config
user-manual: Standardize backtick quoting
user-manual: Use 'git config --global user.*' for setup
user-manual: Fix 'both: so' -> 'both; so' typo
user-manual: Fix 'http' -> 'HTTP' typos
user-manual: Use request-pull to generate "please pull" text
user-manual: Fix 'you - Git' -> 'you--Git' typo
user-manual: Flesh out uncommitted changes and submodule updates
user-manual: Use --format=tar.gz to create a gzipped tarball
Documentation/user-manual.txt | 436 +++++++++++++++++++++++-------------------
1 file changed, 243 insertions(+), 193 deletions(-)
--
1.8.1.336.g94702dd
^ permalink raw reply
* [PATCH v2 15/15] user-manual: Use --format=tar.gz to create a gzipped tarball
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
This functionality was introduced by 0e804e09 (archive: provide
builtin .tar.gz filter, 2011-07-21) for v1.7.7.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 8024758..c04ea51 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -931,12 +931,19 @@ The linkgit:git-archive[1] command can create a tar or zip archive from
any version of a project; for example:
-------------------------------------------------
-$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
+$ git archive --format=tar.gz --prefix=project/ HEAD >latest.tar.gz
-------------------------------------------------
will use HEAD to produce a tar archive in which each filename is
preceded by `project/`.
+Versions of Git older than 1.7.7 don't know about the 'tar.gz' format,
+you'll need to use gzip explicitly:
+
+-------------------------------------------------
+$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
+-------------------------------------------------
+
If you're releasing a new version of a software project, you may want
to simultaneously make a changelog to include in the release
announcement.
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 05/15] user-manual: Add a few references to 'git rebase -i'
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
I think this interface is much more convenient than extended cherry
picking or using 'git format-patch'. Inserting a number of references
should raise awareness among new users. The previously discussed
methods (cherry picking and format-patch-ing) are still useful,
because all of these approaches have the same effect, which may help
demystify the process for newbies.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index a8f792d..5d80b40 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2532,6 +2532,13 @@ return mywork to the state it had before you started the rebase:
$ git rebase --abort
-------------------------------------------------
+If you need to reorder or edit a number of commits in a branch, it may
+be easier to use `git rebase -i`, which allows you to reorder and
+squash commits, as well as marking them for individual editing during
+the rebase. See linkgit:git-rebase[1] for details, and
+<<reordering-patch-series>> for alternatives.
+
+
[[rewriting-one-commit]]
Rewriting a single commit
-------------------------
@@ -2546,10 +2553,10 @@ $ git commit --amend
which will replace the old commit by a new commit incorporating your
changes, giving you a chance to edit the old commit message first.
-You can also use a combination of this and linkgit:git-rebase[1] to
-replace a commit further back in your history and recreate the
-intervening changes on top of it. First, tag the problematic commit
-with
+You can also use a combination of `commit --amend` and
+linkgit:git-rebase[1] (see <<using-git-rebase>>) to replace a commit
+further back in your history and recreate the intervening changes on
+top of it. First, tag the problematic commit with
-------------------------------------------------
$ git tag bad mywork~5
@@ -2584,6 +2591,12 @@ new commits having new object names.
Reordering or selecting from a patch series
-------------------------------------------
+There are a number of ways you can go about editing an existing patch
+series. The easiest way is probably by using `git rebase -i`,
+mentioned in <<using-git-rebase>>, but whether you use
+linkgit:git-rebase[1] or one of the methods discussed below, the
+effect is the same. Pick whichever approach you like best.
+
Given one existing commit, the linkgit:git-cherry-pick[1] command
allows you to apply the change introduced by that commit and create a
new commit that records it. So, for example, if "mywork" points to a
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 07/15] user-manual: Mention 'git remote add' for remote branch config
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
I hardly ever setup remote.<name>.url using 'git config'. While it
may be instructive to do so, we should also point out 'git remote
add'.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index a68d6b9..424cdd6 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2909,8 +2909,23 @@ Also note that all of the above configuration can be performed by
directly editing the file .git/config instead of using
linkgit:git-config[1].
+You can produce a similar configuration with:
+
+-------------------------------------------------
+$ git remote add example git://example.com/proj.git
+-------------------------------------------------
+
+which adds the following stanza to `.git/config`:
+
+-------------------------------------------------
+[remote "example"]
+ url = git://example.com/proj.git
+ fetch = +refs/heads/*:refs/remotes/example/*
+-------------------------------------------------
+
See linkgit:git-config[1] for more details on the configuration
-options mentioned above.
+options mentioned above and linkgit:git-fetch[1] for more details on
+the refspec syntax.
[[git-concepts]]
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 02/15] user-manual: Update for receive.denyCurrentBranch=refuse
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
acd2a45 (Refuse updating the current branch in a non-bare repository
via push, 2009-02-11) changed the default to refuse such a push, but
it forgot to update the docs.
7d182f5 (Documentation: receive.denyCurrentBranch defaults to
'refuse', 2010-03-17) updated Documentation/config.txt, but forgot to
update the user manual.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 222545b..8524c08 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1988,8 +1988,10 @@ handling this case.
Note that the target of a "push" is normally a
<<def_bare_repository,bare>> repository. You can also push to a
repository that has a checked-out working tree, but the working tree
-will not be updated by the push. This may lead to unexpected results if
-the branch you push to is the currently checked-out branch!
+will not be updated by the push. To protect against this, pushes to
+the currently checked-out branch of a repository are denied by
+default. See the description of the receive.denyCurrentBranch option
+in linkgit:git-config[1] for details.
As with `git fetch`, you may also set up configuration options to
save typing; so, for example, after
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 08/15] user-manual: Standardize backtick quoting
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
I tried to always use backticks for:
* Paths and filenames (e.g. `.git/config`)
* Compound refs (e.g. `origin/HEAD`)
* Git commands (e.g. `git log`)
* Command arguments (e.g. `--pretty`)
* URLs (e.g. `git://`), as a subset of command arguments
* Special characters (e.g. `+` in diffs).
* Config options (e.g. `branch.<name>.remote`)
Branch and tag names are sometimes set off with double quotes,
sometimes set off with backticks, and sometimes left bare. I tried to
judge when the intention was introducing new terms or conventions
(double quotes), to reference a recently used command argument
(backticks), or to reference the abstract branch/commit (left bare).
Obviously these are not particularly crisp definitions, so my
decisions are fairly arbitrary ;). When a reference had already been
introduced, I changed further double-quoted instances to backticked
instances.
When new backticks increased the length of a line beyond others in
that block, I re-wrapped blocks to 72 columns.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 300 +++++++++++++++++++++---------------------
1 file changed, 151 insertions(+), 149 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 424cdd6..8bf37b3 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -19,7 +19,7 @@ Further chapters cover more specialized topics.
Comprehensive reference documentation is available through the man
pages, or linkgit:git-help[1] command. For example, for the command
-"git clone <repo>", you can either use:
+`git clone <repo>`, you can either use:
------------------------------------------------
$ man git-clone
@@ -66,11 +66,11 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
The initial clone may be time-consuming for a large project, but you
will only need to clone once.
-The clone command creates a new directory named after the project ("git"
-or "linux-2.6" in the examples above). After you cd into this
+The clone command creates a new directory named after the project (`git`
+or `linux-2.6` in the examples above). After you cd into this
directory, you will see that it contains a copy of the project files,
called the <<def_working_tree,working tree>>, together with a special
-top-level directory named ".git", which contains all the information
+top-level directory named `.git`, which contains all the information
about the history of the project.
[[how-to-check-out]]
@@ -188,7 +188,7 @@ As you can see, a commit shows who made the latest change, what they
did, and why.
Every commit has a 40-hexdigit id, sometimes called the "object name" or the
-"SHA-1 id", shown on the first line of the "git show" output. You can usually
+"SHA-1 id", shown on the first line of the `git show` output. You can usually
refer to a commit by a shorter name, such as a tag or a branch name, but this
longer name can also be useful. Most importantly, it is a globally unique
name for this commit: so if you tell somebody else the object name (for
@@ -268,35 +268,35 @@ Manipulating branches
Creating, deleting, and modifying branches is quick and easy; here's
a summary of the commands:
-git branch::
+`git branch`::
list all branches
-git branch <branch>::
- create a new branch named <branch>, referencing the same
+`git branch <branch>`::
+ create a new branch named `<branch>`, referencing the same
point in history as the current branch
-git branch <branch> <start-point>::
- create a new branch named <branch>, referencing
- <start-point>, which may be specified any way you like,
+`git branch <branch> <start-point>`::
+ create a new branch named `<branch>`, referencing
+ `<start-point>`, which may be specified any way you like,
including using a branch name or a tag name
-git branch -d <branch>::
- delete the branch <branch>; if the branch you are deleting
+`git branch -d <branch>`::
+ delete the branch `<branch>`; if the branch you are deleting
points to a commit which is not reachable from the current
branch, this command will fail with a warning.
-git branch -D <branch>::
+`git branch -D <branch>`::
even if the branch points to a commit not reachable
from the current branch, you may know that that commit
is still reachable from some other branch or tag. In that
case it is safe to use this command to force Git to delete
the branch.
-git checkout <branch>::
- make the current branch <branch>, updating the working
- directory to reflect the version referenced by <branch>
-git checkout -b <new> <start-point>::
- create a new branch <new> referencing <start-point>, and
+`git checkout <branch>`::
+ make the current branch `<branch>`, updating the working
+ directory to reflect the version referenced by `<branch>`
+`git checkout -b <new> <start-point>`::
+ create a new branch `<new>` referencing `<start-point>`, and
check it out.
The special symbol "HEAD" can always be used to refer to the current
-branch. In fact, Git uses a file named "HEAD" in the .git directory to
-remember which branch is current:
+branch. In fact, Git uses a file named `HEAD` in the `.git` directory
+to remember which branch is current:
------------------------------------------------
$ cat .git/HEAD
@@ -346,7 +346,7 @@ of the HEAD in the repository that you cloned from. That repository
may also have had other branches, though, and your local repository
keeps branches which track each of those remote branches, called
remote-tracking branches, which you
-can view using the "-r" option to linkgit:git-branch[1]:
+can view using the `-r` option to linkgit:git-branch[1]:
------------------------------------------------
$ git branch -r
@@ -364,7 +364,7 @@ In this example, "origin" is called a remote repository, or "remote"
for short. The branches of this repository are called "remote
branches" from our point of view. The remote-tracking branches listed
above were created based on the remote branches at clone time and will
-be updated by "git fetch" (hence "git pull") and "git push". See
+be updated by `git fetch` (hence `git pull`) and `git push`. See
<<Updating-a-repository-With-git-fetch>> for details.
You might want to build on one of these remote-tracking branches
@@ -374,7 +374,7 @@ on a branch of your own, just as you would for a tag:
$ git checkout -b my-todo-copy origin/todo
------------------------------------------------
-You can also check out "origin/todo" directly to examine it or
+You can also check out `origin/todo` directly to examine it or
write a one-off patch. See <<detached-head,detached head>>.
Note that the name "origin" is just the name that Git uses by default
@@ -386,17 +386,17 @@ Naming branches, tags, and other references
Branches, remote-tracking branches, and tags are all references to
commits. All references are named with a slash-separated path name
-starting with "refs"; the names we've been using so far are actually
+starting with `refs`; the names we've been using so far are actually
shorthand:
- - The branch "test" is short for "refs/heads/test".
- - The tag "v2.6.18" is short for "refs/tags/v2.6.18".
- - "origin/master" is short for "refs/remotes/origin/master".
+ - The branch `test` is short for `refs/heads/test`.
+ - The tag `v2.6.18` is short for `refs/tags/v2.6.18`.
+ - `origin/master` is short for `refs/remotes/origin/master`.
The full name is occasionally useful if, for example, there ever
exists a tag and a branch with the same name.
-(Newly created refs are actually stored in the .git/refs directory,
+(Newly created refs are actually stored in the `.git/refs` directory,
under the path given by their name. However, for efficiency reasons
they may also be packed together in a single file; see
linkgit:git-pack-refs[1]).
@@ -418,7 +418,7 @@ Eventually the developer cloned from will do additional work in her
repository, creating new commits and advancing the branches to point
at the new commits.
-The command "git fetch", with no arguments, will update all of the
+The command `git fetch`, with no arguments, will update all of the
remote-tracking branches to the latest version found in her
repository. It will not touch any of your own branches--not even the
"master" branch that was created for you on clone.
@@ -438,7 +438,7 @@ $ git fetch linux-nfs
-------------------------------------------------
New remote-tracking branches will be stored under the shorthand name
-that you gave "git remote add", in this case linux-nfs:
+that you gave `git remote add`, in this case `linux-nfs`:
-------------------------------------------------
$ git branch -r
@@ -446,10 +446,10 @@ linux-nfs/master
origin/master
-------------------------------------------------
-If you run "git fetch <remote>" later, the remote-tracking branches for the
-named <remote> will be updated.
+If you run `git fetch <remote>` later, the remote-tracking branches
+for the named `<remote>` will be updated.
-If you examine the file .git/config, you will see that Git has added
+If you examine the file `.git/config`, you will see that Git has added
a new stanza:
-------------------------------------------------
@@ -462,7 +462,7 @@ $ cat .git/config
-------------------------------------------------
This is what causes Git to track the remote's branches; you may modify
-or delete these configuration options by editing .git/config with a
+or delete these configuration options by editing `.git/config` with a
text editor. (See the "CONFIGURATION FILE" section of
linkgit:git-config[1] for details.)
@@ -499,7 +499,7 @@ Bisecting: 3537 revisions left to test after this
[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]
-------------------------------------------------
-If you run "git branch" at this point, you'll see that Git has
+If you run `git branch` at this point, you'll see that Git has
temporarily moved you in "(no branch)". HEAD is now detached from any
branch and points directly to a commit (with commit id 65934...) that
is reachable from "master" but not from v2.6.18. Compile and test it,
@@ -545,11 +545,11 @@ id, and check it out with:
$ git reset --hard fb47ddb2db...
-------------------------------------------------
-then test, run "bisect good" or "bisect bad" as appropriate, and
+then test, run `bisect good` or `bisect bad` as appropriate, and
continue.
-Instead of "git bisect visualize" and then "git reset --hard
-fb47ddb2db...", you might just want to tell Git that you want to skip
+Instead of `git bisect visualize` and then `git reset --hard
+fb47ddb2db...`, you might just want to tell Git that you want to skip
the current commit:
-------------------------------------------------
@@ -561,8 +561,8 @@ bad one between some first skipped commits and a later bad commit.
There are also ways to automate the bisecting process if you have a
test script that can tell a good from a bad commit. See
-linkgit:git-bisect[1] for more information about this and other "git
-bisect" features.
+linkgit:git-bisect[1] for more information about this and other `git
+bisect` features.
[[naming-commits]]
Naming commits
@@ -591,7 +591,7 @@ $ git show HEAD~4 # the great-great-grandparent
-------------------------------------------------
Recall that merge commits may have more than one parent; by default,
-^ and ~ follow the first parent listed in the commit, but you can
+`^` and `~` follow the first parent listed in the commit, but you can
also choose:
-------------------------------------------------
@@ -640,7 +640,7 @@ running
$ git tag stable-1 1b2e1d63ff
-------------------------------------------------
-You can use stable-1 to refer to the commit 1b2e1d63ff.
+You can use `stable-1` to refer to the commit 1b2e1d63ff.
This creates a "lightweight" tag. If you would also like to include a
comment with the tag, and possibly sign it cryptographically, then you
@@ -669,7 +669,7 @@ $ git log -S'foo()' # commits which add or remove any file data
-------------------------------------------------
And of course you can combine all of these; the following finds
-commits since v2.5 which touch the Makefile or any file under fs:
+commits since v2.5 which touch the `Makefile` or any file under `fs`:
-------------------------------------------------
$ git log v2.5.. Makefile fs/
@@ -681,7 +681,7 @@ You can also ask git log to show patches:
$ git log -p
-------------------------------------------------
-See the "--pretty" option in the linkgit:git-log[1] man page for more
+See the `--pretty` option in the linkgit:git-log[1] man page for more
display options.
Note that git log starts with the most recent commit and works
@@ -742,8 +742,8 @@ Examples
Counting the number of commits on a branch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Suppose you want to know how many commits you've made on "mybranch"
-since it diverged from "origin":
+Suppose you want to know how many commits you've made on `mybranch`
+since it diverged from `origin`:
-------------------------------------------------
$ git log --pretty=oneline origin..mybranch | wc -l
@@ -780,7 +780,7 @@ $ git rev-list master
e05db0fd4f31dde7005f075a84f96b360d05984b
-------------------------------------------------
-Or you could recall that the ... operator selects all commits
+Or you could recall that the `...` operator selects all commits
contained reachable from either one reference or the other but not
both: so
@@ -880,7 +880,7 @@ Showing commits unique to a given branch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suppose you would like to see all the commits reachable from the branch
-head named "master" but not from any other head in your repository.
+head named `master` but not from any other head in your repository.
We can list all the heads in this repository with
linkgit:git-show-ref[1]:
@@ -894,7 +894,7 @@ a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master
1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes
-------------------------------------------------
-We can get just the branch-head names, and remove "master", with
+We can get just the branch-head names, and remove `master`, with
the help of the standard utilities cut and grep:
-------------------------------------------------
@@ -935,7 +935,7 @@ $ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
-------------------------------------------------
will use HEAD to produce a tar archive in which each filename is
-preceded by "project/".
+preceded by `project/`.
If you're releasing a new version of a software project, you may want
to simultaneously make a changelog to include in the release
@@ -993,7 +993,7 @@ Telling Git your name
Before creating any commits, you should introduce yourself to Git. The
easiest way to do so is to make sure the following lines appear in a
-file named .gitconfig in your home directory:
+file named `.gitconfig` in your home directory:
------------------------------------------------
[user]
@@ -1045,7 +1045,7 @@ at step 3, Git maintains a snapshot of the tree's contents in a
special staging area called "the index."
At the beginning, the content of the index will be identical to
-that of the HEAD. The command "git diff --cached", which shows
+that of the HEAD. The command `git diff --cached`, which shows
the difference between the HEAD and the index, should therefore
produce no output at that point.
@@ -1084,7 +1084,7 @@ $ git diff
shows the difference between the working tree and the index file.
-Note that "git add" always adds just the current contents of a file
+Note that `git add` always adds just the current contents of a file
to the index; further changes to the same file will be ignored unless
you run `git add` on the file again.
@@ -1155,8 +1155,9 @@ annoying to have these untracked files lying around; e.g. they make
`git add .` practically useless, and they keep showing up in the output of
`git status`.
-You can tell Git to ignore certain files by creating a file called .gitignore
-in the top level of your working directory, with contents such as:
+You can tell Git to ignore certain files by creating a file called
+`.gitignore` in the top level of your working directory, with contents
+such as:
-------------------------------------------------
# Lines starting with '#' are considered comments.
@@ -1180,10 +1181,10 @@ for other users who clone your repository.
If you wish the exclude patterns to affect only certain repositories
(instead of every repository for a given project), you may instead put
-them in a file in your repository named .git/info/exclude, or in any file
-specified by the `core.excludesfile` configuration variable. Some Git
-commands can also take exclude patterns directly on the command line.
-See linkgit:gitignore[5] for the details.
+them in a file in your repository named `.git/info/exclude`, or in any
+file specified by the `core.excludesfile` configuration variable.
+Some Git commands can also take exclude patterns directly on the
+command line. See linkgit:gitignore[5] for the details.
[[how-to-merge]]
How to merge
@@ -1196,10 +1197,10 @@ linkgit:git-merge[1]:
$ git merge branchname
-------------------------------------------------
-merges the development in the branch "branchname" into the current
+merges the development in the branch `branchname` into the current
branch.
-A merge is made by combining the changes made in "branchname" and the
+A merge is made by combining the changes made in `branchname` and the
changes made up to the latest commit in your current branch since
their histories forked. The work tree is overwritten by the result of
the merge when this combining is done cleanly, or overwritten by a
@@ -1321,7 +1322,7 @@ that part is not conflicting and is not shown. Same for stage 3).
The diff above shows the differences between the working-tree version of
file.txt and the stage 2 and stage 3 versions. So instead of preceding
-each line by a single "+" or "-", it now uses two columns: the first
+each line by a single `+` or `-`, it now uses two columns: the first
column is used for differences between the first parent and the working
directory copy, and the second for differences between the second parent
and the working directory copy. (See the "COMBINED DIFF FORMAT" section
@@ -1596,7 +1597,7 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
You will see informational messages on dangling objects. They are objects
that still exist in the repository but are no longer referenced by any of
-your branches, and can (and will) be removed after a while with "gc".
+your branches, and can (and will) be removed after a while with `gc`.
You can run `git fsck --no-dangling` to suppress these messages, and still
view real errors.
@@ -1608,9 +1609,9 @@ Recovering lost changes
Reflogs
^^^^^^^
-Say you modify a branch with +linkgit:git-reset[1] \--hard+, and then
-realize that the branch was the only reference you had to that point in
-history.
+Say you modify a branch with <<fixing-mistakes,`git reset --hard`>>,
+and then realize that the branch was the only reference you had to
+that point in history.
Fortunately, Git also keeps a log, called a "reflog", of all the
previous values of each branch. So in this case you can still find the
@@ -1621,8 +1622,8 @@ $ git log master@{1}
-------------------------------------------------
This lists the commits reachable from the previous version of the
-"master" branch head. This syntax can be used with any Git command
-that accepts a commit, not just with git log. Some other examples:
+`master` branch head. This syntax can be used with any Git command
+that accepts a commit, not just with `git log`. Some other examples:
-------------------------------------------------
$ git show master@{2} # See where the branch pointed 2,
@@ -1726,8 +1727,8 @@ one step:
$ git pull origin master
-------------------------------------------------
-In fact, if you have "master" checked out, then this branch has been
-configured by "git clone" to get changes from the HEAD branch of the
+In fact, if you have `master` checked out, then this branch has been
+configured by `git clone` to get changes from the HEAD branch of the
origin repository. So often you can
accomplish the above with just a simple
@@ -1742,11 +1743,11 @@ the current branch.
More generally, a branch that is created from a remote-tracking branch
will pull
by default from that branch. See the descriptions of the
-branch.<name>.remote and branch.<name>.merge options in
+`branch.<name>.remote` and `branch.<name>.merge` options in
linkgit:git-config[1], and the discussion of the `--track` option in
linkgit:git-checkout[1], to learn how to control these defaults.
-In addition to saving you keystrokes, "git pull" also helps you by
+In addition to saving you keystrokes, `git pull` also helps you by
producing a default commit message documenting the branch and
repository that you pulled from.
@@ -1754,7 +1755,7 @@ repository that you pulled from.
<<fast-forwards,fast-forward>>; instead, your branch will just be
updated to point to the latest commit from the upstream branch.)
-The `git pull` command can also be given "." as the "remote" repository,
+The `git pull` command can also be given `.` as the "remote" repository,
in which case it just merges in a branch from the current repository; so
the commands
@@ -1779,7 +1780,7 @@ $ git format-patch origin
-------------------------------------------------
will produce a numbered series of files in the current directory, one
-for each patch in the current branch but not in origin/HEAD.
+for each patch in the current branch but not in `origin/HEAD`.
`git format-patch` can include an initial "cover letter". You can insert
commentary on individual patches after the three dash line which
@@ -1801,7 +1802,7 @@ Importing patches to a project
Git also provides a tool called linkgit:git-am[1] (am stands for
"apply mailbox"), for importing such an emailed series of patches.
Just save all of the patch-containing messages, in order, into a
-single mailbox file, say "patches.mbox", then run
+single mailbox file, say `patches.mbox`, then run
-------------------------------------------------
$ git am -3 patches.mbox
@@ -1809,7 +1810,7 @@ $ git am -3 patches.mbox
Git will apply each patch in order; if any conflicts are found, it
will stop, and you can fix the conflicts as described in
-"<<resolving-a-merge,Resolving a merge>>". (The "-3" option tells
+"<<resolving-a-merge,Resolving a merge>>". (The `-3` option tells
Git to perform a merge; if you would prefer it just to abort and
leave your tree and index untouched, you may omit that option.)
@@ -1885,7 +1886,7 @@ We explain how to do this in the following sections.
Setting up a public repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Assume your personal repository is in the directory ~/proj. We
+Assume your personal repository is in the directory `~/proj`. We
first create a new clone of the repository and tell `git daemon` that it
is meant to be public:
@@ -1895,10 +1896,10 @@ $ touch proj.git/git-daemon-export-ok
-------------------------------------------------
The resulting directory proj.git contains a "bare" git repository--it is
-just the contents of the ".git" directory, without any files checked out
+just the contents of the `.git` directory, without any files checked out
around it.
-Next, copy proj.git to the server where you plan to host the
+Next, copy `proj.git` to the server where you plan to host the
public repository. You can use scp, rsync, or whatever is most
convenient.
@@ -1909,8 +1910,8 @@ Exporting a Git repository via the Git protocol
This is the preferred method.
If someone else administers the server, they should tell you what
-directory to put the repository in, and what git:// URL it will appear
-at. You can then skip to the section
+directory to put the repository in, and what `git://` URL it will
+appear at. You can then skip to the section
"<<pushing-changes-to-a-public-repository,Pushing changes to a public
repository>>", below.
@@ -1945,7 +1946,7 @@ $ mv hooks/post-update.sample hooks/post-update
(For an explanation of the last two lines, see
linkgit:git-update-server-info[1] and linkgit:githooks[5].)
-Advertise the URL of proj.git. Anybody else should then be able to
+Advertise the URL of `proj.git`. Anybody else should then be able to
clone or pull from that URL, for example with a command line like:
-------------------------------------------------
@@ -1968,8 +1969,8 @@ access, which you will need to update the public repository with the
latest changes created in your private repository.
The simplest way to do this is using linkgit:git-push[1] and ssh; to
-update the remote branch named "master" with the latest state of your
-branch named "master", run
+update the remote branch named `master` with the latest state of your
+branch named `master`, run
-------------------------------------------------
$ git push ssh://yourserver.com/~you/proj.git master:master
@@ -1985,7 +1986,7 @@ As with `git fetch`, `git push` will complain if this does not result in a
<<fast-forwards,fast-forward>>; see the following section for details on
handling this case.
-Note that the target of a "push" is normally a
+Note that the target of a `push` is normally a
<<def_bare_repository,bare>> repository. You can also push to a
repository that has a checked-out working tree, but the working tree
will not be updated by the push. To protect against this, pushes to
@@ -2012,9 +2013,9 @@ you should be able to perform the above push with just
$ git push public-repo master
-------------------------------------------------
-See the explanations of the remote.<name>.url, branch.<name>.remote,
-and remote.<name>.push options in linkgit:git-config[1] for
-details.
+See the explanations of the `remote.<name>.url`,
+`branch.<name>.remote`, and `remote.<name>.push` options in
+linkgit:git-config[1] for details.
[[forcing-push]]
What to do when a push fails
@@ -2149,7 +2150,7 @@ linkgit:git-fetch[1] to keep them up-to-date; see
Now create the branches in which you are going to work; these start out
at the current tip of origin/master branch, and should be set up (using
-the --track option to linkgit:git-branch[1]) to merge changes in from
+the `--track` option to linkgit:git-branch[1]) to merge changes in from
Linus by default.
-------------------------------------------------
@@ -2168,7 +2169,7 @@ Important note! If you have any local changes in these branches, then
this merge will create a commit object in the history (with no local
changes Git will simply do a "fast-forward" merge). Many people dislike
the "noise" that this creates in the Linux history, so you should avoid
-doing this capriciously in the "release" branch, as these noisy commits
+doing this capriciously in the `release` branch, as these noisy commits
will become part of the permanent history when you ask Linus to pull
from the release branch.
@@ -2210,7 +2211,7 @@ patches), and create a new branch from a recent stable tag of
Linus's branch. Picking a stable base for your branch will:
1) help you: by avoiding inclusion of unrelated and perhaps lightly
tested changes
-2) help future bug hunters that use "git bisect" to find problems
+2) help future bug hunters that use `git bisect` to find problems
-------------------------------------------------
$ git checkout -b speed-up-spinlocks v2.6.35
@@ -2235,9 +2236,9 @@ It is unlikely that you would have any conflicts here ... but you might if you
spent a while on this step and had also pulled new versions from upstream.
Some time later when enough time has passed and testing done, you can pull the
-same branch into the "release" tree ready to go upstream. This is where you
+same branch into the `release` tree ready to go upstream. This is where you
see the value of keeping each patch (or patch series) in its own branch. It
-means that the patches can be moved into the "release" tree in any order.
+means that the patches can be moved into the `release` tree in any order.
-------------------------------------------------
$ git checkout release && git pull . speed-up-spinlocks
@@ -2270,7 +2271,7 @@ If it has been merged, then there will be no output.)
Once a patch completes the great cycle (moving from test to release,
then pulled by Linus, and finally coming back into your local
-"origin/master" branch), the branch for this change is no longer needed.
+`origin/master` branch), the branch for this change is no longer needed.
You detect this when the output from:
-------------------------------------------------
@@ -2285,8 +2286,8 @@ $ git branch -d branchname
Some changes are so trivial that it is not necessary to create a separate
branch and then merge into each of the test and release branches. For
-these changes, just apply directly to the "release" branch, and then
-merge that into the "test" branch.
+these changes, just apply directly to the `release` branch, and then
+merge that into the `test` branch.
To create diffstat and shortlog summaries of changes to include in a "please
pull" request to Linus you can use:
@@ -2461,8 +2462,8 @@ you are rewriting history.
Keeping a patch series up to date using git rebase
--------------------------------------------------
-Suppose that you create a branch "mywork" on a remote-tracking branch
-"origin", and create some commits on top of it:
+Suppose that you create a branch `mywork` on a remote-tracking branch
+`origin`, and create some commits on top of it:
-------------------------------------------------
$ git checkout -b mywork origin
@@ -2474,7 +2475,7 @@ $ git commit
-------------------------------------------------
You have performed no merges into mywork, so it is just a simple linear
-sequence of patches on top of "origin":
+sequence of patches on top of `origin`:
................................................
o--o--O <-- origin
@@ -2483,7 +2484,7 @@ sequence of patches on top of "origin":
................................................
Some more interesting work has been done in the upstream project, and
-"origin" has advanced:
+`origin` has advanced:
................................................
o--o--O--o--o--o <-- origin
@@ -2491,7 +2492,7 @@ Some more interesting work has been done in the upstream project, and
a--b--c <-- mywork
................................................
-At this point, you could use "pull" to merge your changes back in;
+At this point, you could use `pull` to merge your changes back in;
the result would create a new merge commit, like this:
................................................
@@ -2510,7 +2511,7 @@ $ git rebase origin
-------------------------------------------------
This will remove each of your commits from mywork, temporarily saving
-them as patches (in a directory named ".git/rebase-apply"), update mywork to
+them as patches (in a directory named `.git/rebase-apply`), update mywork to
point at the latest version of origin, then apply each of the saved
patches to the new mywork. The result will look like:
@@ -2606,8 +2607,8 @@ effect is the same. Pick whichever approach you like best.
Given one existing commit, the linkgit:git-cherry-pick[1] command
allows you to apply the change introduced by that commit and create a
-new commit that records it. So, for example, if "mywork" points to a
-series of patches on top of "origin", you might do something like:
+new commit that records it. So, for example, if `mywork` points to a
+series of patches on top of `origin`, you might do something like:
-------------------------------------------------
$ git checkout -b mywork-new origin
@@ -2771,10 +2772,10 @@ arbitrary name:
$ git fetch origin todo:my-todo-work
-------------------------------------------------
-The first argument, "origin", just tells Git to fetch from the
+The first argument, `origin`, just tells Git to fetch from the
repository you originally cloned from. The second argument tells Git
-to fetch the branch named "todo" from the remote repository, and to
-store it locally under the name refs/heads/my-todo-work.
+to fetch the branch named `todo` from the remote repository, and to
+store it locally under the name `refs/heads/my-todo-work`.
You can also fetch branches from other repositories; so
@@ -2782,8 +2783,8 @@ You can also fetch branches from other repositories; so
$ git fetch git://example.com/proj.git master:example-master
-------------------------------------------------
-will create a new branch named "example-master" and store in it the
-branch named "master" from the repository at the given URL. If you
+will create a new branch named `example-master` and store in it the
+branch named `master` from the repository at the given URL. If you
already have a branch named example-master, it will attempt to
<<fast-forwards,fast-forward>> to the commit given by example.com's
master branch. In more detail:
@@ -2792,7 +2793,7 @@ master branch. In more detail:
git fetch and fast-forwards
---------------------------
-In the previous example, when updating an existing branch, "git fetch"
+In the previous example, when updating an existing branch, `git fetch`
checks to make sure that the most recent commit on the remote
branch is a descendant of the most recent commit on your copy of the
branch before updating your copy of the branch to point at the new
@@ -2818,11 +2819,11 @@ resulting in a situation like:
o--o--o <-- new head of the branch
................................................
-In this case, "git fetch" will fail, and print out a warning.
+In this case, `git fetch` will fail, and print out a warning.
In that case, you can still force Git to update to the new head, as
described in the following section. However, note that in the
-situation above this may mean losing the commits labeled "a" and "b",
+situation above this may mean losing the commits labeled `a` and `b`,
unless you've already created a reference of your own pointing to
them.
@@ -2837,7 +2838,7 @@ descendant of the old head, you may force the update with:
$ git fetch git://example.com/proj.git +master:refs/remotes/example/master
-------------------------------------------------
-Note the addition of the "+" sign. Alternatively, you can use the "-f"
+Note the addition of the `+` sign. Alternatively, you can use the `-f`
flag to force updates of all the fetched branches, as in:
-------------------------------------------------
@@ -2851,7 +2852,7 @@ may be lost, as we saw in the previous section.
Configuring remote-tracking branches
------------------------------------
-We saw above that "origin" is just a shortcut to refer to the
+We saw above that `origin` is just a shortcut to refer to the
repository that you originally cloned from. This information is
stored in Git configuration variables, which you can see using
linkgit:git-config[1]:
@@ -2896,17 +2897,17 @@ $ git fetch example master:refs/remotes/example/master
$ git fetch example
-------------------------------------------------
-You can also add a "+" to force the update each time:
+You can also add a `+` to force the update each time:
-------------------------------------------------
$ git config remote.example.fetch +master:refs/remotes/example/master
-------------------------------------------------
-Don't do this unless you're sure you won't mind "git fetch" possibly
-throwing away commits on 'example/master'.
+Don't do this unless you're sure you won't mind `git fetch` possibly
+throwing away commits on `example/master`.
Also note that all of the above configuration can be performed by
-directly editing the file .git/config instead of using
+directly editing the file `.git/config` instead of using
linkgit:git-config[1].
You can produce a similar configuration with:
@@ -2989,7 +2990,7 @@ Commit Object
~~~~~~~~~~~~~
The "commit" object links a physical state of a tree with a description
-of how we got there and why. Use the --pretty=raw option to
+of how we got there and why. Use the `--pretty=raw` option to
linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite
commit:
@@ -3031,7 +3032,7 @@ of the tree referred to by this commit with the trees associated with
its parents. In particular, Git does not attempt to record file renames
explicitly, though it can identify cases where the existence of the same
file data at changing paths suggests a rename. (See, for example, the
--M option to linkgit:git-diff[1]).
+`-M` option to linkgit:git-diff[1]).
A commit is usually created by linkgit:git-commit[1], which creates a
commit whose parent is normally the current HEAD, and whose tree is
@@ -3082,7 +3083,7 @@ Blob Object
~~~~~~~~~~~
You can use linkgit:git-show[1] to examine the contents of a blob; take,
-for example, the blob in the entry for "COPYING" from the tree above:
+for example, the blob in the entry for `COPYING` from the tree above:
------------------------------------------------
$ git show 6ff87c4664
@@ -3165,14 +3166,14 @@ nLE/L9aUXdWeTFPron96DLA=
See the linkgit:git-tag[1] command to learn how to create and verify tag
objects. (Note that linkgit:git-tag[1] can also be used to create
"lightweight tags", which are not tag objects at all, but just simple
-references whose names begin with "refs/tags/").
+references whose names begin with `refs/tags/`).
[[pack-files]]
How Git stores objects efficiently: pack files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Newly created objects are initially created in a file named after the
-object's SHA-1 hash (stored in .git/objects).
+object's SHA-1 hash (stored in `.git/objects`).
Unfortunately this system becomes inefficient once a project has a
lot of objects. Try this on an old project:
@@ -3213,9 +3214,9 @@ $ git prune
to remove any of the "loose" objects that are now contained in the
pack. This will also remove any unreferenced objects (which may be
-created when, for example, you use "git reset" to remove a commit).
+created when, for example, you use `git reset` to remove a commit).
You can verify that the loose objects are gone by looking at the
-.git/objects directory or by running
+`.git/objects` directory or by running
------------------------------------------------
$ git count-objects
@@ -3242,7 +3243,7 @@ branch still exists, as does everything it pointed to. The branch
pointer itself just doesn't, since you replaced it with another one.
There are also other situations that cause dangling objects. For
-example, a "dangling blob" may arise because you did a "git add" of a
+example, a "dangling blob" may arise because you did a `git add` of a
file, but then, before you actually committed it and made it part of the
bigger picture, you changed something else in that file and committed
that *updated* thing--the old state that you added originally ends up
@@ -3285,14 +3286,14 @@ $ git show <dangling-blob/tree-sha-goes-here>
------------------------------------------------
to show what the contents of the blob were (or, for a tree, basically
-what the "ls" for that directory was), and that may give you some idea
+what the `ls` for that directory was), and that may give you some idea
of what the operation was that left that dangling object.
Usually, dangling blobs and trees aren't very interesting. They're
almost always the result of either being a half-way mergebase (the blob
will often even have the conflict markers from a merge in it, if you
have had conflicting merges that you fixed up by hand), or simply
-because you interrupted a "git fetch" with ^C or something like that,
+because you interrupted a `git fetch` with ^C or something like that,
leaving _some_ of the new objects in the object database, but just
dangling and useless.
@@ -3303,16 +3304,16 @@ state, you can just prune all unreachable objects:
$ git prune
------------------------------------------------
-and they'll be gone. But you should only run "git prune" on a quiescent
+and they'll be gone. But you should only run `git prune` on a quiescent
repository--it's kind of like doing a filesystem fsck recovery: you
don't want to do that while the filesystem is mounted.
-(The same is true of "git fsck" itself, btw, but since
+(The same is true of `git fsck` itself, btw, but since
`git fsck` never actually *changes* the repository, it just reports
on what it found, `git fsck` itself is never 'dangerous' to run.
Running it while somebody is actually changing the repository can cause
confusing and scary messages, but it won't actually do anything bad. In
-contrast, running "git prune" while somebody is actively changing the
+contrast, running `git prune` while somebody is actively changing the
repository is a *BAD* idea).
[[recovering-from-repository-corruption]]
@@ -3350,7 +3351,7 @@ missing blob 4b9458b3786228369c63936db65827de3cc06200
Now you know that blob 4b9458b3 is missing, and that the tree 2d9263c6
points to it. If you could find just one copy of that missing blob
object, possibly in some other repository, you could move it into
-.git/objects/4b/9458b3... and be done. Suppose you can't. You can
+`.git/objects/4b/9458b3...` and be done. Suppose you can't. You can
still examine the tree that pointed to it with linkgit:git-ls-tree[1],
which might output something like:
@@ -3365,10 +3366,10 @@ $ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
------------------------------------------------
So now you know that the missing blob was the data for a file named
-"myfile". And chances are you can also identify the directory--let's
-say it's in "somedirectory". If you're lucky the missing copy might be
+`myfile`. And chances are you can also identify the directory--let's
+say it's in `somedirectory`. If you're lucky the missing copy might be
the same as the copy you have checked out in your working tree at
-"somedirectory/myfile"; you can test whether that's right with
+`somedirectory/myfile`; you can test whether that's right with
linkgit:git-hash-object[1]:
------------------------------------------------
@@ -3423,7 +3424,7 @@ $ git hash-object -w <recreated-file>
and your repository is good again!
-(Btw, you could have ignored the fsck, and started with doing a
+(Btw, you could have ignored the `fsck`, and started with doing a
------------------------------------------------
$ git log --raw --all
@@ -3437,7 +3438,7 @@ just missing one particular blob version.
The index
-----------
-The index is a binary file (generally kept in .git/index) containing a
+The index is a binary file (generally kept in `.git/index`) containing a
sorted list of path names, each with permissions and the SHA-1 of a blob
object; linkgit:git-ls-files[1] can show you the contents of the index:
@@ -3577,7 +3578,7 @@ $ ls -a
The `git submodule add <repo> <path>` command does a couple of things:
-- It clones the submodule from <repo> to the given <path> under the
+- It clones the submodule from `<repo>` to the given `<path>` under the
current directory and by default checks out the master branch.
- It adds the submodule's clone path to the linkgit:gitmodules[5] file and
adds this file to the index, ready to be committed.
@@ -3705,11 +3706,11 @@ Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path
In older Git versions it could be easily forgotten to commit new or modified
files in a submodule, which silently leads to similar problems as not pushing
-the submodule changes. Starting with Git 1.7.0 both "git status" and "git diff"
+the submodule changes. Starting with Git 1.7.0 both `git status` and `git diff`
in the superproject show submodules as modified when they contain new or
-modified files to protect against accidentally committing such a state. "git
-diff" will also add a "-dirty" to the work tree side when generating patch
-output or used with the --submodule option:
+modified files to protect against accidentally committing such a state. `git
+diff` will also add a `-dirty` to the work tree side when generating patch
+output or used with the `--submodule` option:
-------------------------------------------------
$ git diff
@@ -3883,7 +3884,7 @@ or, if you want to check out all of the index, use `-a`.
NOTE! `git checkout-index` normally refuses to overwrite old files, so
if you have an old version of the tree already checked out, you will
-need to use the "-f" flag ('before' the "-a" flag or the filename) to
+need to use the `-f` flag ('before' the `-a` flag or the filename) to
'force' the checkout.
@@ -3894,7 +3895,7 @@ from one representation to the other:
Tying it all together
~~~~~~~~~~~~~~~~~~~~~
-To commit a tree you have instantiated with "git write-tree", you'd
+To commit a tree you have instantiated with `git write-tree`, you'd
create a "commit" object that refers to that tree and the history
behind it--most notably the "parent" commits that preceded it in
history.
@@ -4155,8 +4156,9 @@ As a result, the general consistency of an object can always be tested
independently of the contents or the type of the object: all objects can
be validated by verifying that (a) their hashes match the content of the
file and (b) the object successfully inflates to a stream of bytes that
-forms a sequence of <ascii type without space> {plus} <space> {plus} <ascii decimal
-size> {plus} <byte\0> {plus} <binary object data>.
+forms a sequence of
+`<ascii type without space> {plus} <space> {plus} <ascii decimal size>
+{plus} <byte\0> {plus} <binary object data>`.
The structured objects can further have their structure and
connectivity to other objects verified. This is generally done with
@@ -4635,10 +4637,10 @@ Think about how to create a clear chapter dependency graph that will
allow people to get to important topics without necessarily reading
everything in between.
-Scan Documentation/ for other stuff left out; in particular:
+Scan `Documentation/` for other stuff left out; in particular:
- howto's
-- some of technical/?
+- some of `technical/`?
- hooks
- list of commands in linkgit:git[1]
--
1.8.1.336.g94702dd
^ permalink raw reply related
* Re: [PATCH v2 08/15] user-manual: Standardize backtick quoting
From: W. Trevor King @ 2013-02-10 15:22 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano
In-Reply-To: <d520dd4ff6774ef8d858a2438008c686d58db9b7.1360508415.git.wking@tremily.us>
[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]
On Sun, Feb 10, 2013 at 10:10:34AM -0500, W. Trevor King wrote:
> @@ -4155,8 +4156,9 @@ As a result, the general consistency of an object can always be tested
> independently of the contents or the type of the object: all objects can
> be validated by verifying that (a) their hashes match the content of the
> file and (b) the object successfully inflates to a stream of bytes that
> -forms a sequence of <ascii type without space> {plus} <space> {plus} <ascii decimal
> -size> {plus} <byte\0> {plus} <binary object data>.
> +forms a sequence of
> +`<ascii type without space> {plus} <space> {plus} <ascii decimal size>
> +{plus} <byte\0> {plus} <binary object data>`.
>
> The structured objects can further have their structure and
> connectivity to other objects verified. This is generally done with
Reading through the user-manual history, it looks like I goofed here.
6cf378f0 (docs: stop using asciidoc no-inline-literal, 2012-04-26)
points out that `{plus}` is no longer interpreted inside backticks.
In v3, I'll use `+` instead of `{plus}`.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Duy Nguyen @ 2013-02-10 15:35 UTC (permalink / raw)
To: demerphq; +Cc: Ramkumar Ramachandra, Robert Zeh, Junio C Hamano, Git List,
finnag
In-Reply-To: <CANgJU+WYSD8RHb19EP0M89=Y_XskfjDtFWf51qjg4ur+rDb3ug@mail.gmail.com>
On Sun, Feb 10, 2013 at 8:26 PM, demerphq <demerphq@gmail.com> wrote:
> On 10 February 2013 12:17, Duy Nguyen <pclouds@gmail.com> wrote:
>> Bear in mind though this is Linux, where lstat is fast. On systems
>> with slow lstat, these timings could look very different due to the
>> large number of lstat calls compared to open+getdents. I really like
>> to see similar numbers on Windows.
>
> Is windows stat really so slow?
I can't say. I haven't used Windows for months (and git on Windows for years)..
> I encountered this perception in
> windows Perl in the past, and I know that on windows Perl stat
> *appears* slow compared to *nix, because in order to satisfy the full
> *nix stat interface, specifically the nlink field, it must open and
> close the file*. As of 5.10 this can be disabled by setting a magic
> var ${^WIN32_SLOPPY_STAT} to a true value, which makes a significant
> improvement to the performance of the Perl level stat implementation.
> I would not be surprised if the cygwin implementation of stat() has
> the same issue as Perl did, and that stat appears much slower than it
> actually need be if you don't care about the nlink field.
The native port of git uses get_file_attr (in
compat/mingw.c:do_lstat()) to simulate lstat and always sets nlink to
1. I assume this means git does not care about nlink field. I don't
know about cygwin though.
> Yves
> * http://perl5.git.perl.org/perl.git/blob/HEAD:/win32/win32.c#l1492
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH] Introduce branch.<name>.pushremote
From: Ramkumar Ramachandra @ 2013-02-10 15:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Jonathan Nieder, Jeff King
In-Reply-To: <7vhallw946.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> struct bp { const char *branch; const char *remotename; };
>
> static int pushremote(const char *var, const char *val, void *cb)
> {
> struct bp *bp = cb;
> const char *name, *key;
> int namelen;
>
> if (!parse_config_key(var, "branch", &name, &namelen, &key) &&
> namelen == strlen(bp->branch) &&
> !memcmp(name, bp->branch, name, namelen) &&
> !strcmp(key, "remotepush")) {
> git_config_string(&bp->remotename, var, val);
> }
> return 0;
> }
>
> char *find_pushremote(void) {
> struct bp bp;
>
> bp.branch = get_current_branch();
> bp.remotename = NULL;
> git_config(pushremote, &bp);
> return bp.remotename;
> }
I don't get the point of your illustration. First, we never deal with
a char * branch anywhere: handle_config() immediately calls
make_branch() as soon as it parses the name from the config. Second,
remote_name is already bundled with the branch struct: why do you need
a new bp struct? This is how I would do it without relying on a
global:
static int handle_config(const char *key, const char *value, void *cb) {
/* parse branch name here */
/* ... */
branch = make_branch(name);
if (!strcmp(subkey, ".pushremote"))
branch->pushremote_name = xstrdup(value);
}
struct remote *pushremote_get(struct branch *this_branch)
{
if (this_branch == get_current_branch())
name = this_branch->pushremote_name;
/* ... */
return make_remote(name);
}
Essentially, I need to know for which branch we're trying to get the
pushremote: hence the parameter this_branch to pushremote_get().
> But there is no reason for anybody to want to know the value for the
> variables branch.$name.pushremote for all defined $name's at the
> same time, exactly because this matters only for the current branch,
> no?
Ah, yes. You are right. There's no harm in having globals because
there can really be only one current branch, and only one pushremote
corresponding to that. It's just that globals tend to confuse me in
general, because I have to keep track of a maze of functions that are
getting/ setting them.
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Ramkumar Ramachandra @ 2013-02-10 16:45 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Robert Zeh, Junio C Hamano, Git List, finnag
In-Reply-To: <20130210111732.GA24377@lanh>
On Sun, Feb 10, 2013 at 4:47 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Feb 10, 2013 at 12:24:58PM +0700, Duy Nguyen wrote:
>> On Sun, Feb 10, 2013 at 12:10 AM, Ramkumar Ramachandra
>> <artagnon@gmail.com> wrote:
>> > Finn notes in the commit message that it offers no speedup, because
>> > .gitignore files in every directory still have to be read. I think
>> > this is silly: we really should be caching .gitignore, and touching it
>> > only when lstat() reports that the file has changed.
>> >
>> > ...
>> >
>> > Really, the elephant in the room right now seems to be .gitignore.
>> > Until that is fixed, there is really no use of writing this inotify
>> > daemon, no? Can someone enlighten me on how exactly .gitignore files
>> > are processed?
>>
>> .gitignore is a different issue. I think it's mainly used with
>> read_directory/fill_directory to collect ignored files (or not-ignored
>> files). And it's not always used (well, status and add does, but diff
>> should not). I think wee need to measure how much mass lstat
>> elimination gains us (especially on big repos) and how much
>> .gitignore/.gitattributes caching does.
>
> OK let's count. I start with a "standard" repository, linux-2.6. This
> is the number from strace -T on "git status" (*). The first column is
> accumulated time, the second the number of syscalls.
>
> top syscalls sorted top syscalls sorted
> by acc. time by number
> ----------------------------------------------
> 0.401906 40950 lstat 0.401906 40950 lstat
> 0.190484 5343 getdents 0.150055 5374 open
> 0.150055 5374 open 0.190484 5343 getdents
> 0.074843 2806 close 0.074843 2806 close
> 0.003216 157 read 0.003216 157 read
>
> The following patch pretends every entry is uptodate without
> lstat. With the patch, we can see refresh code is the cause of mass
> lstat, as lstat disappears:
>
> 0.185347 5343 getdents 0.144173 5374 open
> 0.144173 5374 open 0.185347 5343 getdents
> 0.071844 2806 close 0.071844 2806 close
> 0.004918 135 brk 0.003378 157 read
> 0.003378 157 read 0.004918 135 brk
Okay, we're saving 40k lstat() calls.
> -- 8< --
> diff --git a/read-cache.c b/read-cache.c
> index 827ae55..94d8ed8 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1018,6 +1018,10 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
> if (ce_uptodate(ce))
> return ce;
>
> +#if 1
> + ce_mark_uptodate(ce);
> + return ce;
> +#endif
> /*
> * CE_VALID or CE_SKIP_WORKTREE means the user promised us
> * that the change to the work tree does not matter and told
> -- 8< --
So you're skipping the rest of refresh_cache_ent(), which contains our
lstat() and returning immediately. Instead of marking paths with the
"assume unchanged" bit, as core.ignoreStat does, you're directly
attacking the function that refreshes the index and bypassing the
lstat() call. How are they different? read-cache.c:1030 checks
ce->flags & CE_VALID (which is set in read-cache.c:88 if
assume_unchanged) and bypasses the lstat() call anyway. So why didn't
you just set core.ignoreStat for your test?
> The following patch eliminates untracked search code. As we can see,
> open+getdents also disappears with this patch:
>
> 0.462909 40950 lstat 0.462909 40950 lstat
> 0.003417 129 brk 0.003417 129 brk
> 0.000762 53 read 0.000762 53 read
> 0.000720 36 open 0.000720 36 open
> 0.000544 12 munmap 0.000454 33 close
Okay, 5k open and 5k getdents calls are gone, but what does this mean?
Pulling the patch from your next email to figure this out:
> -- 8< --
> diff --git a/dir.c b/dir.c
> index 57394e4..1963c6f 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1439,8 +1439,10 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const char
> return dir->nr;
>
> simplify = create_simplify(pathspec);
> +#if 0
> if (!len || treat_leading_path(dir, path, len, simplify))
> read_directory_recursive(dir, path, len, 0, simplify);
> +#endif
> free_simplify(simplify);
> qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
> qsort(dir->ignored, dir->ignored_nr, sizeof(struct dir_entry *), cmp_name);
> -- 8< --
Ah, read_directory(), from the .gitignore/ exclude angle. Yes,
read_directory() seems to be the main culprit there, from my reading
of Documentation/technical/api-directory-listing.txt.
So, what did you do? You short-circuited the function into never
executing read_directory_recursive(), so the opendir() and readdir()
are gone. I'm confused about what this means: will new directories
fail to appear as "untracked" now? Either way, I understand that
you've factored out the .gitignore/ excludes. Let's look at the
timings now.
> So from syscalls point of view, we know what code issues most of
> them. Let's see how much time we gain be these patches, which is an
> approximate of the gain by inotify support. This time I measure on
> gentoo-x86.git [1] because this one has really big worktree (100k
> files)
>
> unmodified read-cache.c dir.c both
> real 0m0.550s 0m0.479s 0m0.287s 0m0.213s
> user 0m0.305s 0m0.315s 0m0.201s 0m0.182s
> sys 0m0.240s 0m0.157s 0m0.084s 0m0.030s
So, the .gitignore/ exclude does seem to be the elephant in the room,
after all! There are only minor gains from not updating the index.
> and the syscall picture on gentoo-x86.git:
>
> 1.106615 101942 lstat 1.106615 101942 lstat
> 0.667235 47083 getdents 0.641604 47114 open
> 0.641604 47114 open 0.667235 47083 getdents
> 0.286711 23573 close 0.286711 23573 close
> 0.005842 350 brk 0.005842 350 brk
The lstat to getdents/ open is higher than in linux-2.6.git here, but
the profit in eliminating lstat is still very small.
> We can see that shortcuting untracked code gives bigger gain than
> index refresh code. So I have to agree that .gitignore may be the big
> elephant in this particular case.
Yes :)
> Bear in mind though this is Linux, where lstat is fast. On systems
> with slow lstat, these timings could look very different due to the
> large number of lstat calls compared to open+getdents. I really like
> to see similar numbers on Windows.
I see.
> read_directory/fill_directory code is mostly used by "git add" (not
> with -u) and "git status", while refresh code is executed in add,
> checkout, commit/status, diff, merge. So while smaller gain, reducing
> lstat calls could benefit in more cases.
Good point, although my major complaint with big repositories is
status and diff. Checkout isn't too bad if the branches don't diverge
much, add is fast enough, but diff is a big problem.
> A relatively slow "git add" is acceptable. "git status" should be
> fast. Although in my workflow, I do "git diff [--stat] [--cached]"
> much more often than "git status" so relatively slow "git status" does
> not hurt me much. But people may do it differently.
Hm.
> On speeding up read_directory with inotify support. I haven't thought
> it through, but I think we could save (or get it via socket) a list of
> untracked files in .git, regardless ignore status, with the help from
> inotify. When this list is verified valid, read_directory could be
> modified to traverse the tree using this list (plus the index) instead
> of opendir+readdir. Not sure how the change might look though.
We could even tell if .gitignore has changed with inotify support, and
tell exactly when we need to update our path treatment. And yes, we
can have inotify to tell us about new files and directories directly,
so we can traverse them. I think we should go ahead with the
system-wide inotify daemon for now: its design needs to be discussed,
so that it's generic enough for all our usecases. I'm thinking there
should be atleast two distinct calls to:
1. Report all changed paths, for use with read-cache.c.
2. Report only new paths, for use with dir.c.
Or can we figure out which of the changed paths are new ourselves?
Kudos to your great work on getting getting these numbers, Duy!
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Erik Faye-Lund @ 2013-02-10 16:58 UTC (permalink / raw)
To: Duy Nguyen
Cc: Ramkumar Ramachandra, Robert Zeh, Junio C Hamano, Git List,
finnag
In-Reply-To: <20130210111732.GA24377@lanh>
On Sun, Feb 10, 2013 at 12:17 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Feb 10, 2013 at 12:24:58PM +0700, Duy Nguyen wrote:
>> On Sun, Feb 10, 2013 at 12:10 AM, Ramkumar Ramachandra
>> <artagnon@gmail.com> wrote:
>> > Finn notes in the commit message that it offers no speedup, because
>> > .gitignore files in every directory still have to be read. I think
>> > this is silly: we really should be caching .gitignore, and touching it
>> > only when lstat() reports that the file has changed.
>> >
>> > ...
>> >
>> > Really, the elephant in the room right now seems to be .gitignore.
>> > Until that is fixed, there is really no use of writing this inotify
>> > daemon, no? Can someone enlighten me on how exactly .gitignore files
>> > are processed?
>>
>> .gitignore is a different issue. I think it's mainly used with
>> read_directory/fill_directory to collect ignored files (or not-ignored
>> files). And it's not always used (well, status and add does, but diff
>> should not). I think wee need to measure how much mass lstat
>> elimination gains us (especially on big repos) and how much
>> .gitignore/.gitattributes caching does.
>
> OK let's count. I start with a "standard" repository, linux-2.6. This
> is the number from strace -T on "git status" (*). The first column is
> accumulated time, the second the number of syscalls.
>
> top syscalls sorted top syscalls sorted
> by acc. time by number
> ----------------------------------------------
> 0.401906 40950 lstat 0.401906 40950 lstat
> 0.190484 5343 getdents 0.150055 5374 open
> 0.150055 5374 open 0.190484 5343 getdents
> 0.074843 2806 close 0.074843 2806 close
> 0.003216 157 read 0.003216 157 read
>
> The following patch pretends every entry is uptodate without
> lstat. With the patch, we can see refresh code is the cause of mass
> lstat, as lstat disappears:
>
> 0.185347 5343 getdents 0.144173 5374 open
> 0.144173 5374 open 0.185347 5343 getdents
> 0.071844 2806 close 0.071844 2806 close
> 0.004918 135 brk 0.003378 157 read
> 0.003378 157 read 0.004918 135 brk
>
> -- 8< --
> diff --git a/read-cache.c b/read-cache.c
> index 827ae55..94d8ed8 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1018,6 +1018,10 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
> if (ce_uptodate(ce))
> return ce;
>
> +#if 1
> + ce_mark_uptodate(ce);
> + return ce;
> +#endif
> /*
> * CE_VALID or CE_SKIP_WORKTREE means the user promised us
> * that the change to the work tree does not matter and told
> -- 8< --
>
> The following patch eliminates untracked search code. As we can see,
> open+getdents also disappears with this patch:
>
> 0.462909 40950 lstat 0.462909 40950 lstat
> 0.003417 129 brk 0.003417 129 brk
> 0.000762 53 read 0.000762 53 read
> 0.000720 36 open 0.000720 36 open
> 0.000544 12 munmap 0.000454 33 close
>
> So from syscalls point of view, we know what code issues most of
> them. Let's see how much time we gain be these patches, which is an
> approximate of the gain by inotify support. This time I measure on
> gentoo-x86.git [1] because this one has really big worktree (100k
> files)
>
> unmodified read-cache.c dir.c both
> real 0m0.550s 0m0.479s 0m0.287s 0m0.213s
> user 0m0.305s 0m0.315s 0m0.201s 0m0.182s
> sys 0m0.240s 0m0.157s 0m0.084s 0m0.030s
>
> and the syscall picture on gentoo-x86.git:
>
> 1.106615 101942 lstat 1.106615 101942 lstat
> 0.667235 47083 getdents 0.641604 47114 open
> 0.641604 47114 open 0.667235 47083 getdents
> 0.286711 23573 close 0.286711 23573 close
> 0.005842 350 brk 0.005842 350 brk
>
> We can see that shortcuting untracked code gives bigger gain than
> index refresh code. So I have to agree that .gitignore may be the big
> elephant in this particular case.
>
> Bear in mind though this is Linux, where lstat is fast. On systems
> with slow lstat, these timings could look very different due to the
> large number of lstat calls compared to open+getdents. I really like
> to see similar numbers on Windows.
Karsten Blees has done something similar-ish on Windows, and he posted
the results here:
https://groups.google.com/forum/#!topic/msysgit/fL_jykUmUNE/discussion
I also seem to remember he doing a ReadDirectoryChangesW version, but
I don't remember what happened with that.
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Robert Zeh @ 2013-02-10 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramkumar Ramachandra, Git List, Duy Nguyen
In-Reply-To: <7vliaxwa9p.fsf@alter.siamese.dyndns.org>
On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> This is much better than Junio's suggestion to study possible
>> implementations on all platforms and designing a generic daemon/
>> communication channel. That's no weekend project.
>
> It appears that you misunderstood what I wrote. That was not "here
> is a design; I want it in my system. Go implemment it".
>
> It was "If somebody wants to discuss it but does not know where to
> begin, doing a small experiment like this and reporting how well it
> worked here may be one way to do so.", nothing more.
What if instead of communicating over a socket, the daemon
dumped a file containing all of the lstat information after git
wrote a file? By definition the daemon should know about file writes.
There would be no network communication, which I think would make
things more secure. It would simplify the rendezvous by insisting on
well known locations in $GIT_DIR.
Robert Zeh
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Martin Fick @ 2013-02-10 19:26 UTC (permalink / raw)
To: Robert Zeh; +Cc: Junio C Hamano, Ramkumar Ramachandra, Git List, Duy Nguyen
In-Reply-To: <CAKXa9=qQwJqxZLxhAS35QeF1+dwH+ukod0NfFggVCuUZHz-USg@mail.gmail.com>
On Sunday, February 10, 2013 12:03:00 pm Robert Zeh wrote:
> On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano
<gitster@pobox.com> wrote:
> > Ramkumar Ramachandra <artagnon@gmail.com> writes:
> >> This is much better than Junio's suggestion to study
> >> possible implementations on all platforms and
> >> designing a generic daemon/ communication channel.
> >> That's no weekend project.
> >
> > It appears that you misunderstood what I wrote. That
> > was not "here is a design; I want it in my system. Go
> > implemment it".
> >
> > It was "If somebody wants to discuss it but does not
> > know where to begin, doing a small experiment like
> > this and reporting how well it worked here may be one
> > way to do so.", nothing more.
>
> What if instead of communicating over a socket, the
> daemon dumped a file containing all of the lstat
> information after git wrote a file? By definition the
> daemon should know about file writes.
But git doesn't, how will it know when the file is written?
Will it use inotify, or poll (kind of defeats the point)?
-Martin
^ permalink raw reply
* Re: [PATCH] fixup! graph: output padding for merge subsequent parents
From: Junio C Hamano @ 2013-02-10 19:30 UTC (permalink / raw)
To: John Keeping; +Cc: git, Matthieu Moy, Michał Kiedrowicz
In-Reply-To: <20130210131647.GA2270@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> Can you squash this into the first commit before you do?
>
> Matthieu is correct that the graph_is_commit_finished() check isn't
> needed in the loop now that we've pulled it out to be checked first -
> the value returned can't change during the loop. I've left the early
> return out.
>
> graph.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/graph.c b/graph.c
> index 2a3fc5c..56f970f 100644
> --- a/graph.c
> +++ b/graph.c
> @@ -1237,7 +1237,7 @@ void graph_show_commit(struct git_graph *graph)
> shown_commit_line = 1;
> }
>
> - while (!shown_commit_line && !graph_is_commit_finished(graph)) {
> + while (!shown_commit_line) {
> shown_commit_line = graph_next_line(graph, &msgbuf);
> fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
> if (!shown_commit_line)
Is it correct to say that this essentially re-does 656197ad3805
(graph.c: infinite loop in git whatchanged --graph -m, 2009-07-25)
in a slightly different way, in that Michał's original fix also
protected against the case where graph->state is flipped to
GRAPH_PADDING by graph_next_line() that returns false, but with your
fixup, the code knows it never happens (i.e. when graph_next_line()
returns false, graph->state is always in the GRAPH_PADDING state),
and the only thing we need to be careful about is when graph->state
is already in the PADDING state upon entry to this function?
Sorry for an overlong single sentence question ;-)
Thanks.
^ permalink raw reply
* Re: `git checkout --orpan` leaves a dirty worktree
From: Jens Lehmann @ 2013-02-10 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ramkumar Ramachandra, Jonathan Nieder, Git List
In-Reply-To: <7vvca2zhkb.fsf@alter.siamese.dyndns.org>
Am 08.02.2013 21:17, schrieb Junio C Hamano:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> BTW, Is there a better way to clean out the worktree than `git rm -rf
>> .`, since that fails for submodules? The impulsive `reset --hard`
>> obviously fails because there is no HEAD.
>
> I _think_ the "git rm" is one of the things on Jens's roadmap.
Hmm, "git rm" does remove submodules since 1.8.1 (but they have to be
cloned with Git 1.7.8 or newer). Or is there something special about
the orphan checkout I'm missing here?
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Junio C Hamano @ 2013-02-10 20:16 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Ramkumar Ramachandra, Robert Zeh, Git List, finnag
In-Reply-To: <20130210112205.GA28434@lanh>
Duy Nguyen <pclouds@gmail.com> writes:
> On Sun, Feb 10, 2013 at 06:17:32PM +0700, Duy Nguyen wrote:
>> The following patch eliminates untracked search code. As we can see,
>> open+getdents also disappears with this patch:
>>
>> 0.462909 40950 lstat 0.462909 40950 lstat
>> 0.003417 129 brk 0.003417 129 brk
>> 0.000762 53 read 0.000762 53 read
>> 0.000720 36 open 0.000720 36 open
>> 0.000544 12 munmap 0.000454 33 close
>
> .. and the patch is missing:
>
> -- 8< --
> diff --git a/dir.c b/dir.c
> index 57394e4..1963c6f 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1439,8 +1439,10 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const char
> return dir->nr;
>
> simplify = create_simplify(pathspec);
> +#if 0
> if (!len || treat_leading_path(dir, path, len, simplify))
> read_directory_recursive(dir, path, len, 0, simplify);
> +#endif
The other "lstat()" experiment was a very interesting one, but this
is not yet an interesting experiment to see where in the "ignore"
codepath we are spending times.
We know that we can tell wt_status_collect_untracked() not to bother
with the untracked or ignored files with !s->show_untracked_files
already, but I think the more interesting question is if we can show
the untracked files with less overhead.
If we want to show untrackedd files, it is a given that we need to
read directories to see what paths there are on the filesystem. Is
the opendir/readdir cost dominating in the process? Are we spending
a lot of time sifting the result of opendir/readdir via the ignore
mechanism? Is reading the "ignore" files costing us much to prime
the ignore mechanism?
If readdir cost is dominant, then that makes "cache gitignore" a
nonsense proposition, I think. If you really want to "cache"
something, you need to have somebody (i.e. a daemon) who constantly
keeps an eye on the filesystem changes and can respond with the up
to date result directly to fill_directory(). I somehow doubt that
it is a direction we would want to go in, though.
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Robert Zeh @ 2013-02-10 20:18 UTC (permalink / raw)
To: Martin Fick; +Cc: Junio C Hamano, Ramkumar Ramachandra, Git List, Duy Nguyen
In-Reply-To: <201302101226.12646.mfick@codeaurora.org>
On Feb 10, 2013, at 1:26 PM, Martin Fick <mfick@codeaurora.org> wrote:
> On Sunday, February 10, 2013 12:03:00 pm Robert Zeh wrote:
>> On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano
> <gitster@pobox.com> wrote:
>>> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>>>> This is much better than Junio's suggestion to study
>>>> possible implementations on all platforms and
>>>> designing a generic daemon/ communication channel.
>>>> That's no weekend project.
>>>
>>> It appears that you misunderstood what I wrote. That
>>> was not "here is a design; I want it in my system. Go
>>> implemment it".
>>>
>>> It was "If somebody wants to discuss it but does not
>>> know where to begin, doing a small experiment like
>>> this and reporting how well it worked here may be one
>>> way to do so.", nothing more.
>>
>> What if instead of communicating over a socket, the
>> daemon dumped a file containing all of the lstat
>> information after git wrote a file? By definition the
>> daemon should know about file writes.
>
> But git doesn't, how will it know when the file is written?
> Will it use inotify, or poll (kind of defeats the point)?
>
> -Martin
I was thinking it would loop on calls to stat for the file with a timeout; this is no different than what we would want to do over a socket in that we would need timeouts for network reads. But we would only be calling stat on one file, instead of the entire repo.
I think we can set things up so the file read is atomic, which means we can ignore the case of a daemon crashing midway through a conversation.
Robert
^ permalink raw reply
* Pushing a git repository to a new server
From: Ethan Reesor @ 2013-02-10 21:00 UTC (permalink / raw)
To: git
I'm looking to make a command to push a git repo to a new server. The
way I just did it is as follows:
localhost> git clone --bare /path/to/MyRepo /path/to/tmpdir/MyRepo.git
localhost> tar xz /path/to/tmpdir/MyRepo.git | ssh myuser@remotehost
tar cz \~/ # If I don't escape '~', my local machine expands it
localhost> ssh myuser@remotehost
remotehost> sudo chown -R git:git MyRepo.git
The reason I had to use my user is the git user's shell is git-prompt
and ~git/git-shell-commands is empty. I have repos set up using
'git@remotehost:MyOtherRepo.git' as the remote and everything works.
How do I make a git command that can talk to the server using
git-prompt like the other commands do?
--
Ethan Reesor
^ permalink raw reply
* Re: [PATCH] fixup! graph: output padding for merge subsequent parents
From: John Keeping @ 2013-02-10 21:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthieu Moy, Michał Kiedrowicz
In-Reply-To: <7vliawt19c.fsf@alter.siamese.dyndns.org>
On Sun, Feb 10, 2013 at 11:30:39AM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>
> > Can you squash this into the first commit before you do?
> >
> > Matthieu is correct that the graph_is_commit_finished() check isn't
> > needed in the loop now that we've pulled it out to be checked first -
> > the value returned can't change during the loop. I've left the early
> > return out.
> >
> > graph.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/graph.c b/graph.c
> > index 2a3fc5c..56f970f 100644
> > --- a/graph.c
> > +++ b/graph.c
> > @@ -1237,7 +1237,7 @@ void graph_show_commit(struct git_graph *graph)
> > shown_commit_line = 1;
> > }
> >
> > - while (!shown_commit_line && !graph_is_commit_finished(graph)) {
> > + while (!shown_commit_line) {
> > shown_commit_line = graph_next_line(graph, &msgbuf);
> > fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
> > if (!shown_commit_line)
>
> Is it correct to say that this essentially re-does 656197ad3805
> (graph.c: infinite loop in git whatchanged --graph -m, 2009-07-25)
> in a slightly different way, in that Michał's original fix also
> protected against the case where graph->state is flipped to
> GRAPH_PADDING by graph_next_line() that returns false, but with your
> fixup, the code knows it never happens (i.e. when graph_next_line()
> returns false, graph->state is always in the GRAPH_PADDING state),
> and the only thing we need to be careful about is when graph->state
> is already in the PADDING state upon entry to this function?
Yes, although I wonder if we can end up in POST_MERGE or COLLAPSING
state here as well. The check in the loop guards against that because
those will eventually end up as PADDING.
As far as I can see, this is okay because we have called
graph_show_remainder() at the end of outputting a commit, even when we
end up outputting the same (merge) commit more than once. But someone
more familiar with the graph code might want to comment here.
John
^ permalink raw reply
* Git prompt
From: Ethan Reesor @ 2013-02-10 21:05 UTC (permalink / raw)
To: git
I have a git user set up on my server. It's prompt is set to
git-prompt and it's git-shell-commands is empty. The server works as a
git remote using ssh and the git user. When I `ssh git@server` I get a
prompt where I can do nothing. When you ssh to github.com, you recieve
this message: "Hi username! You've successfully authenticated, but
GitHub does not provide shell access."
How do I make the git user work like github where, upon attempting to
get a prompt, the connection is closed?
--
Ethan Reesor
^ permalink raw reply
* Re: [PATCH v2 02/15] user-manual: Update for receive.denyCurrentBranch=refuse
From: Junio C Hamano @ 2013-02-10 21:24 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <ba62167be6df7a6ba666373913bfd235bcc29c9d.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> acd2a45 (Refuse updating the current branch in a non-bare repository
> via push, 2009-02-11) changed the default to refuse such a push, but
> it forgot to update the docs.
>
> 7d182f5 (Documentation: receive.denyCurrentBranch defaults to
> 'refuse', 2010-03-17) updated Documentation/config.txt, but forgot to
> update the user manual.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/user-manual.txt | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 222545b..8524c08 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1988,8 +1988,10 @@ handling this case.
> Note that the target of a "push" is normally a
> <<def_bare_repository,bare>> repository. You can also push to a
> repository that has a checked-out working tree, but the working tree
> -will not be updated by the push. This may lead to unexpected results if
> -the branch you push to is the currently checked-out branch!
> +will not be updated by the push. To protect against this, pushes to
> +the currently checked-out branch of a repository are denied by
> +default. See the description of the receive.denyCurrentBranch option
> +in linkgit:git-config[1] for details.
Nobody else felt the same logic gap between "will not be updated"
and "to protect against this" I sensed while reading this?
I would not be surprised if some readers felt as if "then why not
update it instead of rejecting?" were a valid question, without a
bit more explanation.
You can also push to a repository that has a working tree,
but a push to the currently checked out branch is denied for
two reasons:
(1) if the push were allowed to update the working tree to
match the pushed commit, it will overwrite and lose the
work in progress in the working tree;
(2) the push does _not_ update the working tree for the
above reason, but then if the push were allowed to
update the tip of the branch, the next commit made based
on the work done in the working tree will be based on
the state of the tree _before_ the push but will be
recorded as a descendant of the pushed commit, reverting
changes to the contents made by the pushed commit.
If you want to handle the above two risks yourself (e.g. you
can promise that you will never make changes to the files in
the working tree or make commit from the working tree, and
install a post-push hook that does "git reset --hard" to
match the working tree state to the commit that was pushed),
you can override this by setting receive.denyCurrentBranch.
It almost makes me wonder if it also makes sense to supersede the
denyCurrentBranch setting with a new receive.currentBranch variable
(setting it to "deny" is equivalent to setting denyCurrentBranch to
true), and make "receive.currentBranch = reset" to allow a push and
always run "git reset --hard" afterwards.
If we were to do so, I would strongly be against adding "checkout"
mode that does "git reset --keep" instead of "--hard". Those who can
accept the unconditional ovewriting with "reset --hard" are the only
ones that are safe if "push" updated the tip of the branch and the
working tree. Updating the working tree with a "reset --keep" may
appear safe because it will catch the case where a file that needs
updating by "push" is modified, but that is an incorrect assumption.
It does not mean nobody has the contents in the editor buffer with
changes yet to be written out. An automated update to the working
tree condition has to be allowed only to a repository with nobody
sitting at the keyboard editing files in there.
^ permalink raw reply
* Re: Git prompt
From: Jonathan Nieder @ 2013-02-10 21:25 UTC (permalink / raw)
To: Ethan Reesor; +Cc: git, Ramkumar Ramachandra, Greg Brockman
In-Reply-To: <CAE_TNikk-9sYVRQRwRecNpp3otQ+oc=uV9SPu+7pAkCUNbcUoQ@mail.gmail.com>
Ethan Reesor wrote:
> I have a git user set up on my server. It's prompt is set to
> git-prompt and it's git-shell-commands is empty.
[...]
> How do I make the git user work like github where, upon attempting to
> get a prompt, the connection is closed?
I assume you mean that the user's login shell is git-shell.
You can disable interactive logins by removing the
~/git-shell-commands/ directory. Unfortunately that doesn't let you
customize the message. Perhaps it would make sense to teach shell.c
to look for a
[shell]
greeting = 'Hi %(username)! You've successfully authenticated, but I do not provide interactive shell access.'
setting in git's config file. What do you think?
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH v2 03/15] user-manual: Use 'remote add' to setup push URLs
From: Junio C Hamano @ 2013-02-10 21:33 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <44d89e81a8465d3bbf50b106a8a844c9d90ac384.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> There is no need to use here documents to setup this configuration.
> It is easier, less confusing, and more robust to use Git's
> configuration tools directly.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/user-manual.txt | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 8524c08..53f73c3 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1994,14 +1994,17 @@ default. See the description of the receive.denyCurrentBranch option
> in linkgit:git-config[1] for details.
>
> As with `git fetch`, you may also set up configuration options to
> -save typing; so, for example, after
> +save typing; so, for example, after either
>
> --------------------------------------------------
> -$ cat >>.git/config <<EOF
> -[remote "public-repo"]
> - url = ssh://yourserver.com/~you/proj.git
> -EOF
> --------------------------------------------------
> +------------------------------------------------
> +$ git remote add public-repo ssh://yourserver.com/~you/proj.git
> +------------------------------------------------
> +
> +or, more explicitly,
> +
> +------------------------------------------------
> +$ git config remote.public-repo.url ssh://yourserver.com/~you/proj.git
> +------------------------------------------------
Look at how "Fetching branches from other repositories" is done. It
shows the use of "remote add" and then shows the result by running
"cat" to show the contents.
I think that organization is much nicer than completely hiding how
the result looks like behind another "git config --set" call, like
the latter half of this patch does. The resulting text may read
like so:
...
save typing; so for example:
------------
$ git remote add public-repo yourserver.com:proj.git
------------
will add this to your configuration:
------------
$ cat .git/config
...
[remote "public-repo"]
url = yourserver.com:proj.git
...
------------
which lets you do the same push with just
------------
$ git push public-repo master
------------
^ permalink raw reply
* Re: [PATCH v2 04/15] user-manual: Use git branch --merged
From: Junio C Hamano @ 2013-02-10 21:37 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <c8abf7a75a59302e6bdc66eee13eb2ec53b26b46.1360508415.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> Use 'git branch --merged origin'. This feature was introduced by
> 049716b (branch --merged/--no-merged: allow specifying arbitrary
> commit, 2008-07-08), after the documentation that's being replaced
> moved into the manual with 9e2163ea (user-manual: move
> howto/using-topic-branches into manual, 2007-05-13).
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> Documentation/user-manual.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 53f73c3..a8f792d 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -2267,10 +2267,10 @@ then pulled by Linus, and finally coming back into your local
> You detect this when the output from:
>
> -------------------------------------------------
> -$ git log origin..branchname
> +$ git branch --merged origin
> -------------------------------------------------
>
> -is empty. At this point the branch can be deleted:
> +lists the branch. At this point the branch can be deleted:
This is making things much less useful. "branch --merged origin"
will show 47 different branches that you are *not* interested in the
flow of examples in this part of the tutorial.
Also, log origin..branchname allows you to notice a situation where
some but not all of the branch was merged, too.
^ permalink raw reply
* Re: [PATCH v2 02/15] user-manual: Update for receive.denyCurrentBranch=refuse
From: W. Trevor King @ 2013-02-10 21:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7vd2w7uajk.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
On Sun, Feb 10, 2013 at 01:24:47PM -0800, Junio C Hamano wrote:
> I would not be surprised if some readers felt as if "then why not
> update it instead of rejecting?" were a valid question, without a
> bit more explanation.
>
> You can also push to a repository that has a working tree,
> …
Looks good to me :). Shall I just drop this patch from v3 and leave
it to you?
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox