* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Jeff King @ 2013-02-01 8:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201073352.GB970@sigill.intra.peff.net>
On Fri, Feb 01, 2013 at 02:33:52AM -0500, Jeff King wrote:
> I am starting to think it has grown in an unnecessarily complex
> direction, and we would be much happier just calling all of the
> "concept" documentation "git-".
>
> The steps I see are:
I am still undecided on whether it is a good idea (in some ways, I like
that "gitrevisions" signals to the user that it is not a command; but I
also recognize that it is more complex for users, and gitremote-helpers
looks silly to me). But here is what the patch looks like, for
reference. The first one is a cleanup we might want to take anyway, and
the second one is the meat.
[1/2]: Documentation/Makefile: clean up MAN*_TXT lists
[2/2]: docs: convert "concept" manpages to git-*
-Peff
^ permalink raw reply
* [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists
From: Jeff King @ 2013-02-01 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201082538.GA25674@sigill.intra.peff.net>
We keep a list of the various files that end up as man1,
man5, etc. Let's break these single-line lists into sorted
multi-line lists, which makes diffs that touch them much
easier to read.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/Makefile | 33 ++++++++++++++++++++++++---------
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 971977b..8e7939f 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt
-MAN1_TXT= \
- $(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
- $(wildcard git-*.txt)) \
- gitk.txt gitweb.txt git.txt
-MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
- gitrepository-layout.txt gitweb.conf.txt
-MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
- gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
- gitdiffcore.txt gitnamespaces.txt gitrevisions.txt gitworkflows.txt
+MAN1_TXT += $(filter-out \
+ $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
+ $(wildcard git-*.txt))
+MAN1_TXT += git.txt
+MAN1_TXT += gitk.txt
+MAN1_TXT += gitweb.txt
+
+MAN5_TXT += gitattributes.txt
+MAN5_TXT += githooks.txt
+MAN5_TXT += gitignore.txt
+MAN5_TXT += gitmodules.txt
+MAN5_TXT += gitrepository-layout.txt
+MAN5_TXT += gitweb.conf.txt
+
+MAN7_TXT += gitcli.txt
+MAN7_TXT += gitcore-tutorial.txt
MAN7_TXT += gitcredentials.txt
+MAN7_TXT += gitcvs-migration.txt
+MAN7_TXT += gitdiffcore.txt
+MAN7_TXT += gitglossary.txt
+MAN7_TXT += gitnamespaces.txt
+MAN7_TXT += gitrevisions.txt
+MAN7_TXT += gittutorial-2.txt
+MAN7_TXT += gittutorial.txt
+MAN7_TXT += gitworkflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
--
1.8.1.2.11.g1a2f572
^ permalink raw reply related
* [PATCH 2/2] docs: convert "concept" manpages to git-*
From: Jeff King @ 2013-02-01 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201082538.GA25674@sigill.intra.peff.net>
The manpages for commands have always been spelled
"git-cmd". But "concept" manpages, like "gitrevisions" were
spelled without the dash. This is complex, and does not
actually buy anything. You might think it creates a separate
namespace for concepts and commands, but "git help foo" will
prefer the command form, meaning we must avoid such
conflicts anyway.
Let's just call everything git-*, which is simpler. This
patch renames the documentation files, updates the Makefile
to find them, and updates internal linkgit references to the
pages. It updates builtin/help.c so that users of "git help
foo" will not even notice the difference.
Users of external html links, or users who have trained
their fingers to type "man gitfoo" will notice the missing
pages. This patch does not install a "this page has moved"
placeholder, but that can easily be done on top.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/Makefile | 27 +++++++++--------
Documentation/config.txt | 8 ++---
Documentation/diff-options.txt | 4 +--
Documentation/git-cat-file.txt | 2 +-
Documentation/git-check-ref-format.txt | 2 +-
Documentation/git-cherry-pick.txt | 2 +-
Documentation/{gitcli.txt => git-cli.txt} | 8 ++---
Documentation/git-commit.txt | 4 +--
...{gitcore-tutorial.txt => git-core-tutorial.txt} | 20 ++++++-------
Documentation/git-credential-cache.txt | 2 +-
Documentation/git-credential-store.txt | 4 +--
.../{gitcredentials.txt => git-credentials.txt} | 6 ++--
...{gitcvs-migration.txt => git-cvs-migration.txt} | 22 +++++++-------
Documentation/git-cvsimport.txt | 2 +-
Documentation/git-cvsserver.txt | 2 +-
Documentation/git-diff.txt | 6 ++--
.../{gitdiffcore.txt => git-diffcore.txt} | 6 ++--
Documentation/git-fast-import.txt | 2 +-
Documentation/git-format-patch.txt | 2 +-
Documentation/git-gc.txt | 2 +-
.../{gitglossary.txt => git-glossary.txt} | 12 ++++----
Documentation/{githooks.txt => git-hooks.txt} | 6 ++--
Documentation/git-http-backend.txt | 2 +-
Documentation/git-log.txt | 2 +-
.../{gitnamespaces.txt => git-namespaces.txt} | 6 ++--
Documentation/git-push.txt | 2 +-
Documentation/git-rebase.txt | 4 +--
Documentation/git-receive-pack.txt | 2 +-
Documentation/git-reflog.txt | 2 +-
...sitory-layout.txt => git-repository-layout.txt} | 10 +++----
Documentation/git-rev-parse.txt | 2 +-
Documentation/git-revert.txt | 2 +-
.../{gitrevisions.txt => git-revisions.txt} | 6 ++--
Documentation/git-show-branch.txt | 2 +-
Documentation/git-show-ref.txt | 2 +-
Documentation/git-show.txt | 2 +-
.../{gittutorial-2.txt => git-tutorial-2.txt} | 24 +++++++--------
.../{gittutorial.txt => git-tutorial.txt} | 24 +++++++--------
Documentation/git-update-server-info.txt | 2 +-
Documentation/git-upload-pack.txt | 2 +-
.../{gitworkflows.txt => git-workflows.txt} | 8 ++---
Documentation/git.txt | 35 +++++++++++-----------
Documentation/gitignore.txt | 2 +-
Documentation/gitk.txt | 2 +-
Documentation/gitweb.conf.txt | 2 +-
Documentation/technical/api-credentials.txt | 2 +-
Documentation/user-manual.txt | 14 ++++-----
builtin/help.c | 4 +--
48 files changed, 159 insertions(+), 159 deletions(-)
rename Documentation/{gitcli.txt => git-cli.txt} (98%)
rename Documentation/{gitcore-tutorial.txt => git-core-tutorial.txt} (99%)
rename Documentation/{gitcredentials.txt => git-credentials.txt} (98%)
rename Documentation/{gitcvs-migration.txt => git-cvs-migration.txt} (94%)
rename Documentation/{gitdiffcore.txt => git-diffcore.txt} (99%)
rename Documentation/{gitglossary.txt => git-glossary.txt} (61%)
rename Documentation/{githooks.txt => git-hooks.txt} (99%)
rename Documentation/{gitnamespaces.txt => git-namespaces.txt} (97%)
rename Documentation/{gitrepository-layout.txt => git-repository-layout.txt} (97%)
rename Documentation/{gitrevisions.txt => git-revisions.txt} (88%)
rename Documentation/{gittutorial-2.txt => git-tutorial-2.txt} (96%)
rename Documentation/{gittutorial.txt => git-tutorial.txt} (97%)
rename Documentation/{gitworkflows.txt => git-workflows.txt} (99%)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 8e7939f..552cc37 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,28 +1,29 @@ MAN5_TXT += gitweb.conf.txt
MAN1_TXT += $(filter-out \
+ $(MAN5_TXT) $(MAN7_TXT) \
$(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard git-*.txt))
MAN1_TXT += git.txt
MAN1_TXT += gitk.txt
MAN1_TXT += gitweb.txt
+MAN5_TXT += git-hooks.txt
+MAN5_TXT += git-repository-layout.txt
MAN5_TXT += gitattributes.txt
-MAN5_TXT += githooks.txt
MAN5_TXT += gitignore.txt
MAN5_TXT += gitmodules.txt
-MAN5_TXT += gitrepository-layout.txt
MAN5_TXT += gitweb.conf.txt
-MAN7_TXT += gitcli.txt
-MAN7_TXT += gitcore-tutorial.txt
-MAN7_TXT += gitcredentials.txt
-MAN7_TXT += gitcvs-migration.txt
-MAN7_TXT += gitdiffcore.txt
-MAN7_TXT += gitglossary.txt
-MAN7_TXT += gitnamespaces.txt
-MAN7_TXT += gitrevisions.txt
-MAN7_TXT += gittutorial-2.txt
-MAN7_TXT += gittutorial.txt
-MAN7_TXT += gitworkflows.txt
+MAN7_TXT += git-cli.txt
+MAN7_TXT += git-core-tutorial.txt
+MAN7_TXT += git-credentials.txt
+MAN7_TXT += git-cvs-migration.txt
+MAN7_TXT += git-diffcore.txt
+MAN7_TXT += git-glossary.txt
+MAN7_TXT += git-namespaces.txt
+MAN7_TXT += git-revisions.txt
+MAN7_TXT += git-tutorial-2.txt
+MAN7_TXT += git-tutorial.txt
+MAN7_TXT += git-workflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d7ec507..666c6ed 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -952,23 +952,23 @@ credential.<url>.*::
Specify an external helper to be called when a username or
password credential is needed; the helper may consult external
storage to avoid prompting the user for the credentials. See
- linkgit:gitcredentials[7] for details.
+ linkgit:git-credentials[7] for details.
credential.useHttpPath::
When acquiring credentials, consider the "path" component of an http
or https URL to be important. Defaults to false. See
- linkgit:gitcredentials[7] for more information.
+ linkgit:git-credentials[7] for more information.
credential.username::
If no username is set for a network authentication, use this username
by default. See credential.<context>.* below, and
- linkgit:gitcredentials[7].
+ linkgit:git-credentials[7].
credential.<url>.*::
Any of the credential.* options above can be applied selectively to
some credentials. For example "credential.https://example.com.username"
would set the default username only for https connections to
- example.com. See linkgit:gitcredentials[7] for details on how URLs are
+ example.com. See linkgit:git-credentials[7] for details on how URLs are
matched.
include::diff-config.txt[]
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 39f2c50..562b0d4 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -366,7 +366,7 @@ ifndef::git-format-patch[]
Look for differences that introduce or remove an instance of
<string>. Note that this is different than the string simply
appearing in diff output; see the 'pickaxe' entry in
- linkgit:gitdiffcore[7] for more details.
+ linkgit:git-diffcore[7] for more details.
-G<regex>::
Look for differences whose added or removed line matches
@@ -481,4 +481,4 @@ For more detailed explanation on these common options, see also
Do not show any source or destination prefix.
For more detailed explanation on these common options, see also
-linkgit:gitdiffcore[7].
+linkgit:git-diffcore[7].
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index 2fb95bb..0f5b23a 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-file.txt
@@ -27,7 +27,7 @@ OPTIONS
<object>::
The name of the object to show.
For a more complete list of ways to spell object names, see
- the "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
+ the "SPECIFYING REVISIONS" section in linkgit:git-revisions[7].
-t::
Instead of the content, show the object type identified by
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 98009d1..d598044 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -59,7 +59,7 @@ unquoted (by mistake), and also avoids ambiguities in certain
These rules make it easy for shell script based tools to parse
reference names, pathname expansion by the shell when a reference name is used
unquoted (by mistake), and also avoids ambiguities in certain
-reference name expressions (see linkgit:gitrevisions[7]):
+reference name expressions (see linkgit:git-revisions[7]):
. A double-dot `..` is often used as in `ref1..ref2`, and in some
contexts this notation means `^ref1 ref2` (i.e. not in
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index c205d23..c2822b4 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -44,7 +44,7 @@ OPTIONS
<commit>...::
Commits to cherry-pick.
For a more complete list of ways to spell commits, see
- linkgit:gitrevisions[7].
+ linkgit:git-revisions[7].
Sets of commits can be passed but no traversal is done by
default, as if the '--no-walk' option was specified, see
linkgit:git-rev-list[1]. Note that specifying a range will
diff --git a/Documentation/gitcli.txt b/Documentation/git-cli.txt
similarity index 98%
rename from Documentation/gitcli.txt
rename to Documentation/git-cli.txt
index 3bc1500..f59f3b6 100644
--- a/Documentation/gitcli.txt
+++ b/Documentation/git-cli.txt
@@ -1,13 +1,13 @@ SYNOPSIS
-gitcli(7)
-=========
+git-cli(7)
+==========
NAME
----
-gitcli - git command line interface and conventions
+git-cli - git command line interface and conventions
SYNOPSIS
--------
-gitcli
+git *
DESCRIPTION
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 41b27da..d8a5143 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -157,7 +157,7 @@ OPTIONS
-n::
--no-verify::
This option bypasses the pre-commit and commit-msg hooks.
- See also linkgit:githooks[5].
+ See also linkgit:git-hooks[5].
--allow-empty::
Usually recording a commit that has the exact same tree as its
@@ -420,7 +420,7 @@ This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
HOOKS
-----
This command can run `commit-msg`, `prepare-commit-msg`, `pre-commit`,
-and `post-commit` hooks. See linkgit:githooks[5] for more
+and `post-commit` hooks. See linkgit:git-hooks[5] for more
information.
FILES
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/git-core-tutorial.txt
similarity index 99%
rename from Documentation/gitcore-tutorial.txt
rename to Documentation/git-core-tutorial.txt
index 5325c5a..1a07c92 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/git-core-tutorial.txt
@@ -1,9 +1,9 @@ NAME
-gitcore-tutorial(7)
-===================
+git-core-tutorial(7)
+====================
NAME
----
-gitcore-tutorial - A git core tutorial for developers
+git-core-tutorial - A git core tutorial for developers
SYNOPSIS
--------
@@ -16,7 +16,7 @@ If you just need to use git as a revision control system you may prefer
work with a git repository.
If you just need to use git as a revision control system you may prefer
-to start with "A Tutorial Introduction to GIT" (linkgit:gittutorial[7]) or
+to start with "A Tutorial Introduction to GIT" (linkgit:git-tutorial[7]) or
link:user-manual.html[the GIT User Manual].
However, an understanding of these low-level tools can be helpful if
@@ -116,7 +116,7 @@ populating your tree.
populating your tree.
[NOTE]
-An advanced user may want to take a look at linkgit:gitrepository-layout[5]
+An advanced user may want to take a look at linkgit:git-repository-layout[5]
after finishing this tutorial.
You have now created your first git repository. Of course, since it's
@@ -970,7 +970,7 @@ are branch heads. 'master^' is the first parent of 'master'
before the commit log message is a short name you can use to
name the commit. In the above example, 'master' and 'mybranch'
are branch heads. 'master^' is the first parent of 'master'
-branch head. Please see linkgit:gitrevisions[7] if you want to
+branch head. Please see linkgit:git-revisions[7] if you want to
see more complex cases.
[NOTE]
@@ -1595,7 +1595,7 @@ cooperation you are probably more familiar with as well.
have to worry. git supports "shared public repository" style of
cooperation you are probably more familiar with as well.
-See linkgit:gitcvs-migration[7] for the details.
+See linkgit:git-cvs-migration[7] for the details.
Bundling your work together
---------------------------
@@ -1696,9 +1696,9 @@ SEE ALSO
SEE ALSO
--------
-linkgit:gittutorial[7],
-linkgit:gittutorial-2[7],
-linkgit:gitcvs-migration[7],
+linkgit:git-tutorial[7],
+linkgit:git-tutorial-2[7],
+linkgit:git-cvs-migration[7],
linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/git-credential-cache.txt b/Documentation/git-credential-cache.txt
index eeff5fa..4a1c101 100644
--- a/Documentation/git-credential-cache.txt
+++ b/Documentation/git-credential-cache.txt
@@ -21,7 +21,7 @@ be used as a credential helper by other parts of git. See
You probably don't want to invoke this command directly; it is meant to
be used as a credential helper by other parts of git. See
-linkgit:gitcredentials[7] or `EXAMPLES` below.
+linkgit:git-credentials[7] or `EXAMPLES` below.
OPTIONS
-------
diff --git a/Documentation/git-credential-store.txt b/Documentation/git-credential-store.txt
index b27c03c..6761191 100644
--- a/Documentation/git-credential-store.txt
+++ b/Documentation/git-credential-store.txt
@@ -24,7 +24,7 @@ be used as a credential helper by other parts of git. See
You probably don't want to invoke this command directly; it is meant to
be used as a credential helper by other parts of git. See
-linkgit:gitcredentials[7] or `EXAMPLES` below.
+linkgit:git-credentials[7] or `EXAMPLES` below.
OPTIONS
-------
@@ -67,7 +67,7 @@ username (if we already have one) match, then the password is returned
credential-store will consider that context a pattern to match against
each entry in the credentials file. If the protocol, hostname, and
username (if we already have one) match, then the password is returned
-to git. See the discussion of configuration in linkgit:gitcredentials[7]
+to git. See the discussion of configuration in linkgit:git-credentials[7]
for more information.
GIT
diff --git a/Documentation/gitcredentials.txt b/Documentation/git-credentials.txt
similarity index 98%
rename from Documentation/gitcredentials.txt
rename to Documentation/git-credentials.txt
index 7dfffc0..85aa1b6 100644
--- a/Documentation/gitcredentials.txt
+++ b/Documentation/git-credentials.txt
@@ -1,9 +1,9 @@ NAME
-gitcredentials(7)
-=================
+git-credentials(7)
+==================
NAME
----
-gitcredentials - providing usernames and passwords to git
+git-credentials - providing usernames and passwords to git
SYNOPSIS
--------
diff --git a/Documentation/gitcvs-migration.txt b/Documentation/git-cvs-migration.txt
similarity index 94%
rename from Documentation/gitcvs-migration.txt
rename to Documentation/git-cvs-migration.txt
index aeb0cdc..6adc45a 100644
--- a/Documentation/gitcvs-migration.txt
+++ b/Documentation/git-cvs-migration.txt
@@ -1,9 +1,9 @@ NAME
-gitcvs-migration(7)
-===================
+git-cvs-migration(7)
+====================
NAME
----
-gitcvs-migration - git for CVS users
+git-cvs-migration - git for CVS users
SYNOPSIS
--------
@@ -20,8 +20,8 @@ Some basic familiarity with git is required. Having gone through
this document explains how to do that.
Some basic familiarity with git is required. Having gone through
-linkgit:gittutorial[7] and
-linkgit:gitglossary[7] should be sufficient.
+linkgit:git-tutorial[7] and
+linkgit:git-glossary[7] should be sufficient.
Developing against a shared repository
--------------------------------------
@@ -83,7 +83,7 @@ possibly created from scratch or from a tarball (see
We assume you have already created a git repository for your project,
possibly created from scratch or from a tarball (see
-linkgit:gittutorial[7]), or imported from an already existing CVS
+linkgit:git-tutorial[7]), or imported from an already existing CVS
repository (see the next section).
Assume your existing repo is at /home/alice/myproject. Create a new "bare"
@@ -154,7 +154,7 @@ points. You can use these, for example, to send all commits to the shared
Git allows you to specify scripts called "hooks" to be run at certain
points. You can use these, for example, to send all commits to the shared
-repository to a mailing list. See linkgit:githooks[5].
+repository to a mailing list. See linkgit:git-hooks[5].
You can enforce finer grained permissions using update hooks. See
link:howto/update-hook-example.txt[Controlling access to branches using
@@ -190,10 +190,10 @@ SEE ALSO
SEE ALSO
--------
-linkgit:gittutorial[7],
-linkgit:gittutorial-2[7],
-linkgit:gitcore-tutorial[7],
-linkgit:gitglossary[7],
+linkgit:git-tutorial[7],
+linkgit:git-tutorial-2[7],
+linkgit:git-core-tutorial[7],
+linkgit:git-glossary[7],
link:everyday.html[Everyday Git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index 9d5353e..ac2cfbf 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -38,7 +38,7 @@ and use the clone as the shared repository.
read/write, or if you want to use linkgit:git-cvsserver[1], then you
probably want to make a bare clone of the imported repository,
and use the clone as the shared repository.
-See linkgit:gitcvs-migration[7].
+See linkgit:git-cvs-migration[7].
OPTIONS
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 940c2ba..895c191 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -163,7 +163,7 @@ You also need to ensure that each repository is "bare" (without a git index
SSH, the users of course also need write access to the git repository itself.
You also need to ensure that each repository is "bare" (without a git index
-file) for `cvs commit` to work. See linkgit:gitcvs-migration[7].
+file) for `cvs commit` to work. See linkgit:git-cvs-migration[7].
[[configaccessmethod]]
All configuration variables can also be overridden for a specific method of
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index f8c0601..7c89f0d 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -81,11 +81,11 @@ and the range notations ("<commit>..<commit>" and
<tree>.
For a more complete list of ways to spell <commit>, see
-"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
+"SPECIFYING REVISIONS" section in linkgit:git-revisions[7].
However, "diff" is about comparing two _endpoints_, not ranges,
and the range notations ("<commit>..<commit>" and
"<commit>\...<commit>") do not mean a range as defined in the
-"SPECIFYING RANGES" section in linkgit:gitrevisions[7].
+"SPECIFYING RANGES" section in linkgit:git-revisions[7].
OPTIONS
-------
@@ -175,7 +175,7 @@ linkgit:git-log[1],
diff(1),
linkgit:git-difftool[1],
linkgit:git-log[1],
-linkgit:gitdiffcore[7],
+linkgit:git-diffcore[7],
linkgit:git-format-patch[1],
linkgit:git-apply[1]
diff --git a/Documentation/gitdiffcore.txt b/Documentation/git-diffcore.txt
similarity index 99%
rename from Documentation/gitdiffcore.txt
rename to Documentation/git-diffcore.txt
index daf1782..9dfdce8 100644
--- a/Documentation/gitdiffcore.txt
+++ b/Documentation/git-diffcore.txt
@@ -1,9 +1,9 @@ NAME
-gitdiffcore(7)
+git-diffcore(7)
==============
NAME
----
-gitdiffcore - Tweaking diff output
+git-diffcore - Tweaking diff output
SYNOPSIS
--------
@@ -274,7 +274,7 @@ linkgit:git-log[1],
linkgit:git-diff-tree[1],
linkgit:git-format-patch[1],
linkgit:git-log[1],
-linkgit:gitglossary[7],
+linkgit:git-glossary[7],
link:user-manual.html[The Git User's Manual]
GIT
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index bf1a02a..6b7d33a 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -481,7 +481,7 @@ Marks must be declared (via `mark`) before they can be used.
* A complete 40 byte or abbreviated commit SHA-1 in hex.
* Any valid Git SHA-1 expression that resolves to a commit. See
- ``SPECIFYING REVISIONS'' in linkgit:gitrevisions[7] for details.
+ ``SPECIFYING REVISIONS'' in linkgit:git-revisions[7] for details.
The special case of restarting an incremental import from the
current branch value should be written as:
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 9a914d0..70d7cbf 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -39,7 +39,7 @@ There are two ways to specify which commits to operate on.
that leads to the <since> to be output.
2. Generic <revision range> expression (see "SPECIFYING
- REVISIONS" section in linkgit:gitrevisions[7]) means the
+ REVISIONS" section in linkgit:git-revisions[7]) means the
commits in the specified range.
The first rule takes precedence in the case of a single <commit>. To
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index b370b02..f54f8c4 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -142,7 +142,7 @@ The 'git gc --auto' command will run the 'pre-auto-gc' hook. See
-----
The 'git gc --auto' command will run the 'pre-auto-gc' hook. See
-linkgit:githooks[5] for more information.
+linkgit:git-hooks[5] for more information.
SEE ALSO
diff --git a/Documentation/gitglossary.txt b/Documentation/git-glossary.txt
similarity index 61%
rename from Documentation/gitglossary.txt
rename to Documentation/git-glossary.txt
index d77a45a..c8157fe 100644
--- a/Documentation/gitglossary.txt
+++ b/Documentation/git-glossary.txt
@@ -1,9 +1,9 @@ NAME
-gitglossary(7)
-==============
+git-glossary(7)
+===============
NAME
----
-gitglossary - A GIT Glossary
+git-glossary - A GIT Glossary
SYNOPSIS
--------
@@ -16,9 +16,9 @@ SEE ALSO
SEE ALSO
--------
-linkgit:gittutorial[7],
-linkgit:gittutorial-2[7],
-linkgit:gitcvs-migration[7],
+linkgit:git-tutorial[7],
+linkgit:git-tutorial-2[7],
+linkgit:git-cvs-migration[7],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/githooks.txt b/Documentation/git-hooks.txt
similarity index 99%
rename from Documentation/githooks.txt
rename to Documentation/git-hooks.txt
index d839233..7a3bc3b 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/git-hooks.txt
@@ -1,9 +1,9 @@ NAME
-githooks(5)
-===========
+git-hooks(5)
+============
NAME
----
-githooks - Hooks used by git
+git-hooks - Hooks used by git
SYNOPSIS
--------
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index f4e0741..a0ffb25 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -120,7 +120,7 @@ ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
----------------------------------------------------------------
+
-To serve multiple repositories from different linkgit:gitnamespaces[7] in a
+To serve multiple repositories from different linkgit:git-namespaces[7] in a
single repository:
+
----------------------------------------------------------------
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 22c0d6e..79000d4 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -29,7 +29,7 @@ OPTIONS
either <since> or <until> is omitted, it defaults to
`HEAD`, i.e. the tip of the current branch.
For a more complete list of ways to spell <since>
- and <until>, see linkgit:gitrevisions[7].
+ and <until>, see linkgit:git-revisions[7].
--follow::
Continue listing the history of a file beyond renames
diff --git a/Documentation/gitnamespaces.txt b/Documentation/git-namespaces.txt
similarity index 97%
rename from Documentation/gitnamespaces.txt
rename to Documentation/git-namespaces.txt
index c6713cf..a031ee7 100644
--- a/Documentation/gitnamespaces.txt
+++ b/Documentation/git-namespaces.txt
@@ -1,9 +1,9 @@ NAME
-gitnamespaces(7)
-================
+git-namespaces(7)
+=================
NAME
----
-gitnamespaces - Git namespaces
+git-namespaces - Git namespaces
SYNOPSIS
--------
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index c964b79..c78469c 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -43,7 +43,7 @@ it can be any arbitrary "SHA-1 expression", such as `master~4` or
+
The <src> is often the name of the branch you would want to push, but
it can be any arbitrary "SHA-1 expression", such as `master~4` or
-`HEAD` (see linkgit:gitrevisions[7]).
+`HEAD` (see linkgit:git-revisions[7]).
+
The <dst> tells which ref on the remote side is updated with this
push. Arbitrary expressions cannot be used here, an actual ref must
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index da067ec..ee5837c 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -295,11 +295,11 @@ which makes little sense.
Do not show a diffstat as part of the rebase process.
--no-verify::
- This option bypasses the pre-rebase hook. See also linkgit:githooks[5].
+ This option bypasses the pre-rebase hook. See also linkgit:git-hooks[5].
--verify::
Allows the pre-rebase hook to run, which is the default. This option can
- be used to override --no-verify. See also linkgit:githooks[5].
+ be used to override --no-verify. See also linkgit:git-hooks[5].
-C<n>::
Ensure at least <n> lines of surrounding context match before
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index b1f7dc6..905a186 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -150,7 +150,7 @@ SEE ALSO
SEE ALSO
--------
-linkgit:git-send-pack[1], linkgit:gitnamespaces[7]
+linkgit:git-send-pack[1], linkgit:git-namespaces[7]
GIT
---
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 7fe2d22..a12f63b 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -41,7 +41,7 @@ two moves ago", `master@{one.week.ago}` means "where master used to
The reflog is useful in various git commands, to specify the old value
of a reference. For example, `HEAD@{2}` means "where HEAD used to be
two moves ago", `master@{one.week.ago}` means "where master used to
-point to one week ago", and so on. See linkgit:gitrevisions[7] for
+point to one week ago", and so on. See linkgit:git-revisions[7] for
more details.
To delete single entries from the reflog, use the subcommand "delete"
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/git-repository-layout.txt
similarity index 97%
rename from Documentation/gitrepository-layout.txt
rename to Documentation/git-repository-layout.txt
index 9f62886..7602980 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/git-repository-layout.txt
@@ -1,9 +1,9 @@ NAME
-gitrepository-layout(5)
-=======================
+git-repository-layout(5)
+========================
NAME
----
-gitrepository-layout - Git Repository Layout
+git-repository-layout - Git Repository Layout
SYNOPSIS
--------
@@ -136,7 +136,7 @@ hooks::
'git init' is run, but all of them are disabled by
default. To enable, the `.sample` suffix has to be
removed from the filename by renaming.
- Read linkgit:githooks[5] for more details about
+ Read linkgit:git-hooks[5] for more details about
each hook.
index::
@@ -203,7 +203,7 @@ linkgit:git-checkout[1],
linkgit:git-pack-refs[1],
linkgit:git-gc[1],
linkgit:git-checkout[1],
-linkgit:gitglossary[7],
+linkgit:git-glossary[7],
link:user-manual.html[The Git User's Manual]
GIT
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 3c63561..ce9cee4 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -236,7 +236,7 @@ Each line of options has this format:
* Use `*` to mean that this option should not be listed in the usage
generated for the `-h` argument. It's shown for `--help-all` as
- documented in linkgit:gitcli[7].
+ documented in linkgit:git-cli[7].
* Use `!` to not make the corresponding negated long option available.
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 70152e8..b6e3a48 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -35,7 +35,7 @@ OPTIONS
<commit>...::
Commits to revert.
For a more complete list of ways to spell commit names, see
- linkgit:gitrevisions[7].
+ linkgit:git-revisions[7].
Sets of commits can also be given but no traversal is done by
default, see linkgit:git-rev-list[1] and its '--no-walk'
option.
diff --git a/Documentation/gitrevisions.txt b/Documentation/git-revisions.txt
similarity index 88%
rename from Documentation/gitrevisions.txt
rename to Documentation/git-revisions.txt
index fc4789f..3bf4531 100644
--- a/Documentation/gitrevisions.txt
+++ b/Documentation/git-revisions.txt
@@ -1,13 +1,13 @@ SYNOPSIS
-gitrevisions(7)
+git-revisions(7)
================
NAME
----
-gitrevisions - specifying revisions and ranges for git
+git-revisions - specifying revisions and ranges for git
SYNOPSIS
--------
-gitrevisions
+git-revisions
DESCRIPTION
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index a8e77b5..d5c27f7 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -31,7 +31,7 @@ OPTIONS
OPTIONS
-------
<rev>::
- Arbitrary extended SHA1 expression (see linkgit:gitrevisions[7])
+ Arbitrary extended SHA1 expression (see linkgit:git-revisions[7])
that typically names a branch head or a tag.
<glob>::
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index 5dbcd47..ca28bc7 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -175,7 +175,7 @@ linkgit:git-update-ref[1],
--------
linkgit:git-ls-remote[1],
linkgit:git-update-ref[1],
-linkgit:gitrepository-layout[5]
+linkgit:git-repository-layout[5]
GIT
---
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index ae4edcc..81bd45e 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -37,7 +37,7 @@ OPTIONS
<object>...::
The names of objects to show.
For a more complete list of ways to spell object names, see
- "SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
+ "SPECIFYING REVISIONS" section in linkgit:git-revisions[7].
include::pretty-options.txt[]
diff --git a/Documentation/gittutorial-2.txt b/Documentation/git-tutorial-2.txt
similarity index 96%
rename from Documentation/gittutorial-2.txt
rename to Documentation/git-tutorial-2.txt
index e00a4d2..8ca2912 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/git-tutorial-2.txt
@@ -1,9 +1,9 @@ NAME
-gittutorial-2(7)
-================
+git-tutorial-2(7)
+=================
NAME
----
-gittutorial-2 - A tutorial introduction to git: part two
+git-tutorial-2 - A tutorial introduction to git: part two
SYNOPSIS
--------
@@ -13,7 +13,7 @@ DESCRIPTION
DESCRIPTION
-----------
-You should work through linkgit:gittutorial[7] before reading this tutorial.
+You should work through linkgit:git-tutorial[7] before reading this tutorial.
The goal of this tutorial is to introduce two fundamental pieces of
git's architecture--the object database and the index file--and to
@@ -395,7 +395,7 @@ branch, and is used to hold the trees involved in a merge operation.
In addition to being the staging area for new commits, the index file
is also populated from the object database when checking out a
branch, and is used to hold the trees involved in a merge operation.
-See linkgit:gitcore-tutorial[7] and the relevant man
+See linkgit:git-core-tutorial[7] and the relevant man
pages for details.
What next?
@@ -404,28 +404,28 @@ SEE ALSO
At this point you should know everything necessary to read the man
pages for any of the git commands; one good place to start would be
with the commands mentioned in link:everyday.html[Everyday git]. You
-should be able to find any unknown jargon in linkgit:gitglossary[7].
+should be able to find any unknown jargon in linkgit:git-glossary[7].
The link:user-manual.html[Git User's Manual] provides a more
comprehensive introduction to git.
-linkgit:gitcvs-migration[7] explains how to
+linkgit:git-cvs-migration[7] explains how to
import a CVS repository into git, and shows how to use git in a
CVS-like way.
For some interesting examples of git use, see the
link:howto-index.html[howtos].
-For git developers, linkgit:gitcore-tutorial[7] goes
+For git developers, linkgit:git-core-tutorial[7] goes
into detail on the lower-level git mechanisms involved in, for
example, creating a new commit.
SEE ALSO
--------
-linkgit:gittutorial[7],
-linkgit:gitcvs-migration[7],
-linkgit:gitcore-tutorial[7],
-linkgit:gitglossary[7],
+linkgit:git-tutorial[7],
+linkgit:git-cvs-migration[7],
+linkgit:git-core-tutorial[7],
+linkgit:git-glossary[7],
linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/gittutorial.txt b/Documentation/git-tutorial.txt
similarity index 97%
rename from Documentation/gittutorial.txt
rename to Documentation/git-tutorial.txt
index f1cb6f3..189d01f 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/git-tutorial.txt
@@ -1,9 +1,9 @@ NAME
-gittutorial(7)
-==============
+git-tutorial(7)
+===============
NAME
----
-gittutorial - A tutorial introduction to git (for version 1.5.1 or newer)
+git-tutorial - A tutorial introduction to git (for version 1.5.1 or newer)
SYNOPSIS
--------
@@ -455,7 +455,7 @@ that various users push changes to; see linkgit:git-push[1] and
Git can also be used in a CVS-like mode, with a central repository
that various users push changes to; see linkgit:git-push[1] and
-linkgit:gitcvs-migration[7].
+linkgit:git-cvs-migration[7].
Exploring history
-----------------
@@ -636,7 +636,7 @@ database, the index file, and a few other odds and ends that you'll
Part two of this tutorial explains the object
database, the index file, and a few other odds and ends that you'll
-need to make the most of git. You can find it at linkgit:gittutorial-2[7].
+need to make the most of git. You can find it at linkgit:git-tutorial-2[7].
If you don't want to continue with that right away, a few other
digressions that may be interesting at this point are:
@@ -653,21 +653,21 @@ linkgit:git-help[1],
smart enough to perform a close-to-optimal search even in the
case of complex non-linear history with lots of merged branches.
- * linkgit:gitworkflows[7]: Gives an overview of recommended
+ * linkgit:git-workflows[7]: Gives an overview of recommended
workflows.
* link:everyday.html[Everyday GIT with 20 Commands Or So]
- * linkgit:gitcvs-migration[7]: Git for CVS users.
+ * linkgit:git-cvs-migration[7]: Git for CVS users.
SEE ALSO
--------
-linkgit:gittutorial-2[7],
-linkgit:gitcvs-migration[7],
-linkgit:gitcore-tutorial[7],
-linkgit:gitglossary[7],
+linkgit:git-tutorial-2[7],
+linkgit:git-cvs-migration[7],
+linkgit:git-core-tutorial[7],
+linkgit:git-glossary[7],
linkgit:git-help[1],
-linkgit:gitworkflows[7],
+linkgit:git-workflows[7],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
diff --git a/Documentation/git-update-server-info.txt b/Documentation/git-update-server-info.txt
index bd0e364..800ab5e 100644
--- a/Documentation/git-update-server-info.txt
+++ b/Documentation/git-update-server-info.txt
@@ -32,7 +32,7 @@ Currently the command updates the following files. Please see
------
Currently the command updates the following files. Please see
-linkgit:gitrepository-layout[5] for description of
+linkgit:git-repository-layout[5] for description of
what they are for:
* objects/info/packs
diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt
index 71f1608..44b9219 100644
--- a/Documentation/git-upload-pack.txt
+++ b/Documentation/git-upload-pack.txt
@@ -36,7 +36,7 @@ SEE ALSO
SEE ALSO
--------
-linkgit:gitnamespaces[7]
+linkgit:git-namespaces[7]
GIT
---
diff --git a/Documentation/gitworkflows.txt b/Documentation/git-workflows.txt
similarity index 99%
rename from Documentation/gitworkflows.txt
rename to Documentation/git-workflows.txt
index 8b8c6ae..8fe1c95 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/git-workflows.txt
@@ -1,9 +1,9 @@ NAME
-gitworkflows(7)
-===============
+git-workflows(7)
+================
NAME
----
-gitworkflows - An overview of recommended workflows with git
+git-workflows - An overview of recommended workflows with git
SYNOPSIS
--------
@@ -466,7 +466,7 @@ SEE ALSO
SEE ALSO
--------
-linkgit:gittutorial[7],
+linkgit:git-tutorial[7],
linkgit:git-push[1],
linkgit:git-pull[1],
linkgit:git-merge[1],
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 555250d..d9d7755 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -21,14 +21,14 @@ page to learn what commands git offers. You can learn more about
unusually rich command set that provides both high-level operations
and full access to internals.
-See linkgit:gittutorial[7] to get started, then see
+See linkgit:git-tutorial[7] to get started, then see
link:everyday.html[Everyday Git] for a useful minimum set of
commands. The link:user-manual.html[Git User's Manual] has a more
in-depth introduction.
After you mastered the basic concepts, you can come back to this
page to learn what commands git offers. You can learn more about
-individual git commands with "git help command". linkgit:gitcli[7]
+individual git commands with "git help command". linkgit:git-cli[7]
manual page gives you an overview of the command line command syntax.
Formatted and hyperlinked version of the latest git documentation
@@ -416,7 +416,7 @@ help ...`.
more detailed discussion).
--namespace=<path>::
- Set the git namespace. See linkgit:gitnamespaces[7] for more
+ Set the git namespace. See linkgit:git-namespaces[7] for more
details. Equivalent to setting the `GIT_NAMESPACE` environment
variable.
@@ -611,15 +611,15 @@ Please see the linkgit:gitrepository-layout[5] document.
(i.e. a `refs/heads/<head>` reference).
For a more complete list of ways to spell object names, see
-"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
+"SPECIFYING REVISIONS" section in linkgit:git-revisions[7].
File/Directory Structure
------------------------
-Please see the linkgit:gitrepository-layout[5] document.
+Please see the linkgit:git-repository-layout[5] document.
-Read linkgit:githooks[5] for more details about each hook.
+Read linkgit:git-hooks[5] for more details about each hook.
Higher level SCMs may provide and manage additional information in the
`$GIT_DIR`.
@@ -627,7 +627,7 @@ Terminology
Terminology
-----------
-Please see linkgit:gitglossary[7].
+Please see linkgit:git-glossary[7].
Environment Variables
@@ -672,7 +672,7 @@ git so take care if using Cogito etc.
option and the core.worktree configuration variable.
'GIT_NAMESPACE'::
- Set the git namespace; see linkgit:gitnamespaces[7] for details.
+ Set the git namespace; see linkgit:git-namespaces[7] for details.
The '--namespace' command-line option also sets this value.
'GIT_CEILING_DIRECTORIES'::
@@ -825,7 +825,7 @@ link:user-manual.html#git-concepts[git concepts chapter of the
More detail on the following is available from the
link:user-manual.html#git-concepts[git concepts chapter of the
-user-manual] and linkgit:gitcore-tutorial[7].
+user-manual] and linkgit:git-core-tutorial[7].
A git project normally consists of a working directory with a ".git"
subdirectory at the top level. The .git directory contains, among other
@@ -881,10 +881,10 @@ introductions to the underlying git architecture.
for a first-time user.
The link:user-manual.html#git-concepts[git concepts chapter of the
-user-manual] and linkgit:gitcore-tutorial[7] both provide
+user-manual] and linkgit:git-core-tutorial[7] both provide
introductions to the underlying git architecture.
-See linkgit:gitworkflows[7] for an overview of recommended workflows.
+See linkgit:git-workflows[7] for an overview of recommended workflows.
See also the link:howto-index.html[howto] documents for some useful
examples.
@@ -893,7 +893,7 @@ Users migrating from CVS may also want to
link:technical/api-index.html[GIT API documentation].
Users migrating from CVS may also want to
-read linkgit:gitcvs-migration[7].
+read linkgit:git-cvs-migration[7].
Authors
@@ -916,12 +916,13 @@ Part of the linkgit:git[1] suite
SEE ALSO
--------
-linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-link:everyday.html[Everyday Git], linkgit:gitcvs-migration[7],
-linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
-linkgit:gitcli[7], link:user-manual.html[The Git User's Manual],
-linkgit:gitworkflows[7]
+linkgit:git-tutorial[7], linkgit:git-tutorial-2[7],
+link:everyday.html[Everyday Git], linkgit:git-cvs-migration[7],
+linkgit:git-glossary[7], linkgit:git-core-tutorial[7],
+linkgit:git-cli[7], link:user-manual.html[The Git User's Manual],
+linkgit:git-workflows[7]
GIT
---
Part of the linkgit:git[1] suite
+
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 0da205f..5b6d396 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -186,7 +186,7 @@ linkgit:git-update-index[1],
--------
linkgit:git-rm[1],
linkgit:git-update-index[1],
-linkgit:gitrepository-layout[5],
+linkgit:git-repository-layout[5],
linkgit:git-check-ignore[1]
GIT
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index a17a354..a931cb2 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -70,7 +70,7 @@ frequently used options.
the form "'<from>'..'<to>'" to show all revisions between '<from>' and
back to '<to>'. Note, more advanced revision selection can be applied.
For a more complete list of ways to spell object names, see
- linkgit:gitrevisions[7].
+ linkgit:git-revisions[7].
<path>...::
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index 4947455..05a2384 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -676,7 +676,7 @@ description of `-S<string>` option, which refers to pickaxe entry in
+
The pickaxe search is described in linkgit:git-log[1] (the
description of `-S<string>` option, which refers to pickaxe entry in
-linkgit:gitdiffcore[7] for more details).
+linkgit:git-diffcore[7] for more details).
+
This feature can be configured on a per-repository basis by setting
repository's `gitweb.pickaxe` configuration variable (boolean).
diff --git a/Documentation/technical/api-credentials.txt b/Documentation/technical/api-credentials.txt
index 5977b58..642d570 100644
--- a/Documentation/technical/api-credentials.txt
+++ b/Documentation/technical/api-credentials.txt
@@ -263,6 +263,6 @@ See also
See also
--------
-linkgit:gitcredentials[7]
+linkgit:git-credentials[7]
linkgit:git-config[5] (See configuration variables `credential.*`)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 1b377dc..0bde9b7 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -408,7 +408,7 @@ references with the same shorthand name, see the "SPECIFYING
For the complete list of paths which git checks for references, and
the order it uses to decide which to choose when there are multiple
references with the same shorthand name, see the "SPECIFYING
-REVISIONS" section of linkgit:gitrevisions[7].
+REVISIONS" section of linkgit:git-revisions[7].
[[Updating-a-repository-With-git-fetch]]
Updating a repository with git fetch
@@ -579,7 +579,7 @@ There are many more; see the "SPECIFYING REVISIONS" section of the
- HEAD: refers to the head of the current branch
There are many more; see the "SPECIFYING REVISIONS" section of the
-linkgit:gitrevisions[7] man page for the complete list of ways to
+linkgit:git-revisions[7] man page for the complete list of ways to
name revisions. Some examples:
-------------------------------------------------
@@ -920,7 +920,7 @@ $ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
$ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
-------------------------------------------------
-(See linkgit:gitrevisions[7] for explanations of commit-selecting
+(See linkgit:git-revisions[7] for explanations of commit-selecting
syntax such as `--not`.)
[[making-a-release]]
@@ -1651,7 +1651,7 @@ how to control this pruning, and see the "SPECIFYING REVISIONS"
The reflogs are kept by default for 30 days, after which they may be
pruned. See linkgit:git-reflog[1] and linkgit:git-gc[1] to learn
how to control this pruning, and see the "SPECIFYING REVISIONS"
-section of linkgit:gitrevisions[7] for details.
+section of linkgit:git-revisions[7] for details.
Note that the reflog history is very different from normal git history.
While normal history is shared by every repository that works on the
@@ -1949,7 +1949,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].)
+linkgit:git-update-server-info[1] and linkgit:git-hooks[5].)
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:
@@ -2061,7 +2061,7 @@ pull, or by a fetch followed by a rebase; see the
solution is to retry the push after first updating your work: either by a
pull, or by a fetch followed by a rebase; see the
<<setting-up-a-shared-repository,next section>> and
-linkgit:gitcvs-migration[7] for more.
+linkgit:git-cvs-migration[7] for more.
[[setting-up-a-shared-repository]]
Setting up a shared repository
@@ -2070,7 +2070,7 @@ all push to and pull from a single shared repository. See
Another way to collaborate is by using a model similar to that
commonly used in CVS, where several developers with special rights
all push to and pull from a single shared repository. See
-linkgit:gitcvs-migration[7] for instructions on how to
+linkgit:git-cvs-migration[7] for instructions on how to
set this up.
However, while there is nothing wrong with git's support for shared
diff --git a/builtin/help.c b/builtin/help.c
index 6067a61..1eca4ea 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -308,10 +308,8 @@ static const char *cmd_to_page(const char *git_cmd)
return "git";
else if (!prefixcmp(git_cmd, "git"))
return git_cmd;
- else if (is_git_command(git_cmd))
- return prepend("git-", git_cmd);
else
- return prepend("git", git_cmd);
+ return prepend("git-", git_cmd);
}
static void setup_man_path(void)
--
1.8.1.2.11.g1a2f572
^ permalink raw reply related
* Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
From: Michael Haggerty @ 2013-02-01 8:39 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <20130130203158.GN1342@serenity.lan>
On 01/30/2013 09:31 PM, John Keeping wrote:
> On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote:
>> [...] maybe we should establish a small Python library of
>> compatibility utilities (like a small "six"). [...]
>> But I haven't had time to think of where to put such a library, how to
>> install it, etc.
>
> If we want to go that route, I think restructuring the
> "git_remote_helpers" directory and re-using its infrastructure for
> installing the "Git Python modules" would be the way to go. The
> directory structure would become something like this:
>
> git/
> `-- python/
> |-- Makefile # existing file pulled out of git_remote_helpers
> |-- < some new utility library >
> |-- git_remote_helpers
> | |-- __init__.py
> | |-- git
> | | |-- __init__.py
> | | |-- exporter.py
> | | |-- git.py
> | | |-- importer.py
> | | |-- non_local.py
> | | `-- repo.py
> | `-- util.py
> |-- setup.cfg # existing file pulled out of git_remote_helpers
> `-- setup.py # existing file pulled out of git_remote_helpers
>
>
> It looks like the GitPython project[1] as already taken the "git" module
> name, so perhaps we should use "git_core" if we do introduce a new
> module.
>
> [1] http://pypi.python.org/pypi/GitPython
This sounds reasonable. But not all Python code will go under the
"python" subdirectory, right? For example, I am working on a Python
script that fits thematically under contrib/hooks.
OTOH (I'm thinking aloud here) it is probably a bad idea for a hook
script to depend on a Python module that is part of git itself. Doing
so would make the hook script depend on a particular version of git (or
at least a version with a compatible Python module). But users might be
reluctant to upgrade git just to install a hook script.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] Verify Content-Type from smart HTTP servers
From: Jeff King @ 2013-02-01 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7v38xhf1i3.fsf@alter.siamese.dyndns.org>
On Thu, Jan 31, 2013 at 02:09:40PM -0800, Junio C Hamano wrote:
> Before parsing a suspected smart-HTTP response verify the returned
> Content-Type matches the standard. This protects a client from
> attempting to process a payload that smells like a smart-HTTP
> server response.
>
> JGit has been doing this check on all responses since the dawn of
> time. I mistakenly failed to include it in git-core when smart HTTP
> was introduced. At the time I didn't know how to get the Content-Type
> from libcurl. I punted, meant to circle back and fix this, and just
> plain forgot about it.
>
> Signed-off-by: Shawn Pearce <spearce@spearce.org>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Should this be "From:" Shawn? The tone of the message and the S-O-B
order makes it look like it.
> @@ -133,16 +135,19 @@ static struct discovery* discover_refs(const char *service)
> last->buf = last->buf_alloc;
>
> if (maybe_smart && 5 <= last->len && last->buf[4] == '#') {
> - /* smart HTTP response; validate that the service
> + /*
> + * smart HTTP response; validate that the service
> * pkt-line matches our request.
> */
> - struct strbuf exp = STRBUF_INIT;
> -
> + strbuf_addf(&exp, "application/x-%s-advertisement", service);
> + if (strbuf_cmp(&exp, &type))
> + die("invalid content-type %s", type.buf);
Hmm. I wondered if it is possible for a non-smart server to send us down
this code path, which would now complain of the bogus content-type.
Something like an info/refs file with:
# 1
# the comment above is meaningless, but puts a "#" at position 4.
But I note that we would already die in the next line:
> if (packet_get_line(&buffer, &last->buf, &last->len) <= 0)
> die("%s has invalid packet header", refs_url);
so I do not think the patch makes anything worse. However, should we
take this opportunity to make the "did we get a smart response" test
more robust? That is, should we actually be checking the content-type
in the outer conditional, and going down the smart code-path if it is
application/x-%s-advertisement, and otherwise treating the result as
dumb?
It's probably not a big deal, as the false positive example above is
quite specific and unlikely, but it just seems cleaner to me.
As a side note, should we (can we) care about the content-type for dumb
http? It should probably be text/plain or application/octet-stream, but
I would not be surprised if we get a variety of random junk in the real
world, though.
-Peff
^ permalink raw reply
* [BUG] git-clone fails due to GnuTLS recv error (-9), then deletes entire local repo
From: TJ @ 2013-02-01 9:00 UTC (permalink / raw)
To: git
Using Ubuntu Precise 12.04 with git version (1.8.0.3) I discovered a bug whereby git-clone deletes the repository
it has just created if there is a GnuTLS error after the final transfer.
I switched to building and using the current git head (1.8.1.2.433.g070c57d.dirty) and found the same issue is still present.
There are two problems here:
1. At the end of the transfer "GnuTLS recv error (-9): A TLS packet with unexpected length was received"
2. git-clone goes on to resolve deltas *then* deletes the entire repository
This is reported as Ubuntu bug #1111882 at https://bugs.launchpad.net/ubuntu/+bug/1111882
The following transcript uses git built with one local patch on top of commit 070c57d which fixes the $(INSTALL) file mode
issue as per my previous list posting "PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA".
GIT_CURL_VERBOSE=1 git clone -v https://git01.codeplex.com/typescript
the operation fails after the final git pack-file has been received and the already-created repository is deleted from the file system.
...
> POST /typescript/git-upload-pack HTTP/1.1
User-Agent: git/1.8.1.2.433.g9808ce0.dirty
Host: git01.codeplex.com
Accept-Encoding: gzip
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Length: 611
* upload completely sent off: 611out of 611 bytes
< HTTP/1.1 200 OK
< Cache-Control: no-cache, max-age=0, must-revalidate
< Pragma: no-cache
< Content-Type: application/x-git-upload-pack-result
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Server: Microsoft-IIS/7.5
< X-Powered-By: ASP.NET
< Date: Thu, 31 Jan 2013 21:43:55 GMT
< Connection: close
<
remote: Counting objects: 149766, done.
remote: Compressing objects: 100% (10580/10580), done.
* GnuTLS recv error (-9): A TLS packet with unexpected length was received.
* Closing connection #0
remote: Total 149766 (delta 138201), reused 149559 (delta 138077)
Receiving objects: 100% (149766/149766), 198.98 MiB | 361 KiB/s, done.
error: RPC failed; result=56, HTTP code = 200
Resolving deltas: 100% (138201/138201), done.
git exits at this point but it deletes the entire cloned ./typescript directory.
So far as I can tell from watching the ./typescript directory from another terminal and also the ethernet interface activity
the transfer is complete but GnuTLS is expecting something more from the HTTPS server which isn't forthcoming, leading to
the error.
The git bug - if this is accepted as a bug - is the deletion of the entire cloned repository.
I tried building the git binary and including an additional debug option in "http.c" that allowed me to set the protocol version using an environment option:
CURLOPT_SSLVERSION=1 git clone ...
where 1 = TLSv1, 2 = SSLv2, 3 = SSLv3.
I tried each protocol but the result was the same.
I did some experimentation using gnutl-cli-debug but was unable to figure out a way to reproduce the SSL/TLS error without
this particular git-clone operation. However, that is a GnuTLS bug, not a git bug.
I did try to build the latest gnutls but it needs a very recent version of libnettle which has the "rsa_decrypt_tr" function. I stopped at that point since I don't want to get into dependency and
library version issues.
Additional research seems to indicate this is a known intentional gnutls behaviour (that has been modified in very recent gnutls that makes use of a very recent libnettle - as mentioned above). The
issue is, apparently, the random size padding of packets to prevent communications compromise for stream ciphers.
I installed stunnel4 (which depends on openssl rather than gnutls) and created a reverse-proxy (client in stunnel terminology):
$ cat /etc/stunnel/rp-codeplex.com.conf
client = yes
[http]
accept = 8888
connect = git01.codeplex.com:443
TIMEOUTclose = 0
$ sudo sed -i 's/\(ENABLED\).*/\1=1/' /etc/default/stunnel4
$ sudo service stunnel4 restart
$ GIT_CURL_VERBOSE=1 git clone -v http://localhost:8888/typescript
...
> POST http://localhost:8888/typescript/git-upload-pack HTTP/1.1
User-Agent: git/1.8.1.2.433.g9808ce0.dirty
Host: localhost:8888
Accept-Encoding: gzip
Proxy-Connection: Keep-Alive
Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Length: 611
* upload completely sent off: 611out of 611 bytes
< HTTP/1.1 200 OK
< Cache-Control: no-cache, max-age=0, must-revalidate
< Pragma: no-cache
< Content-Type: application/x-git-upload-pack-result
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Server: Microsoft-IIS/7.5
< X-Powered-By: ASP.NET
< Date: Thu, 31 Jan 2013 23:38:19 GMT
< Connection: close
<
remote: Counting objects: 149798, done.
remote: Compressing objects: 100% (10612/10612), done.
remote: Total 149798 (delta 138221), reused 149558 (delta 138077)
* Closing connection #0
Receiving objects: 100% (149798/149798), 198.99 MiB | 640 KiB/s, done.
Resolving deltas: 100% (138221/138221), done.
Checking out files: 100% (2851/2851), done.
^ permalink raw reply
* Re: [PATCH/RFC 0/6] commit caching
From: Jeff King @ 2013-02-01 9:11 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Duy Nguyen
In-Reply-To: <CAJo=hJtTYZg+1+RZVfEGTgOGzqxQbN1CLYWrvUp+WHKGxGwHMQ@mail.gmail.com>
On Thu, Jan 31, 2013 at 09:14:26AM -0800, Shawn O. Pearce wrote:
> On Tue, Jan 29, 2013 at 1:14 AM, Jeff King <peff@peff.net> wrote:
> > This is the cleaned-up version of the commit caching patches I mentioned
> > here:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/212329
> ...
> > The short of it is that for an extra 31M of disk
> > space (~4%), I get a warm-cache speedup for "git rev-list --all" of
> > ~4.2s to ~0.66s.
>
> I have to admit, this is a nice gain. I don't think users often dig
> through all commits to the root but I can see how this might improve
> git log with a path filter.
It doesn't just help digging to the roots. It should speed up most
traversals. So merge-bases, --contains, etc, would all be better. I
suspect we could also make --topo-order startup a lot faster, too.
It also helps "rev-list --objects --all", though obviously not by as
large a percentage. And since the main use of that is reachability
bitmaps, the improvements aren't as exciting there.
> > Coupled with using compression level 0 for trees (which do not compress
> > well at all, and yield only a 2% increase in size when left
> > uncompressed), my "git rev-list --objects --all" time drops from ~40s to
> > ~25s.
>
> This uhm.... is nice?
>
> But consider reachability bitmaps. ~40s to ~80ms. :-)
Yeah, yeah. I'm working my way up to it. :)
I wanted to see first how good we could get with a more generic
approach. I think this work may still have value even with reachability
bitmaps, as it will help regular traversals as well as tree access for
pathspec limiting.
At this point I'm convinced that my 25s is about the best we will do for
reachability analysis with a graph traversal. The repeated hashcmps to
see that we've visited each node are starting to dominate. So the next
obvious step is to try reachability bitmaps. I was hoping to iron out
the "pack metadata goes here" issues with the commit cache stuff,
though, as the actual cache implementation is quite simple (whereas the
bitmap stuff is more on the complex side, but can build on the same
metadata base).
> Yup. I have also futzed with the one in JGit for quite a while now. I
> pull some tricks there like making it a 2 level directory to reduce
> the need to find a contiguous array of 8M entries when processing the
> Linux kernel, and I try to preallocate the first level table based on
> the number of objects in pack-*.idx files. But the bottleneck is
> basically the cache lookups and hits, these happen like 100M times on
> 2M objects, because its every link in nearly every tree.
Right. I tried some multi-level tricks (and even a radix trie), but I
couldn't get anything to beat the simple-and-stupid single hash table
with linear probing.
> If we modified pack-objects' delta compressor for tree objects to only
> generate delta instructions at tree record boundaries, a delta-encoded
> tree can be processed without inflating the full content of that tree.
> Because of the way deltas are created, "most" tree deltas should have
> their delta base scanned by the object traversal before the delta is
> considered. This means the tree delta just needs to consider the much
> smaller records that are inserted into the base. We know these are
> different SHA-1s than what was there before, so they are more likely
> to be new to the lookup_object table.
So sort of a magic shortcut tree diff you get while accessing the
object. Neat idea.
> So the --objects traversal algorithm can change to get the delta base
> SHA-1 and raw tree delta from the pack storage. Perform a
> lookup_object on the base to see if it has been scanned. If it has,
> just scan the delta insert instructions. If the base has not yet been
> scanned, inflate the tree to its normal format and scan the entire
> tree.
This would not perform well if we hit the deltas before the bases. In
general, though, our "use the larger as the base" heuristic should mean
that our traversal hits the bases first.
> This is an approximation of what Nico and I were talking about doing
> for pack v4. But doesn't require a file format change. :-)
Yeah. It just needs to be very careful that the deltas it is looking at
all fall on record boundaries, since we might get deltas generated by
other versions of git. Can we necessarily identify that case for sure,
though? I imagine a tree delta like that would look something like:
delete bytes 100-120
add 20 bytes at offset 100: \x12\x34\x56...
Without looking at the base object, and without knowing whether the
delta was generated by our particular implementation, how can we be sure
this is a sha1 replacement and not the renaming of part of a file? Or
are you proposing some flag in the packfile to indicate "yes, this tree
really was delta'd only at record boundaries"?
It could be a big win, but it does seem quite complex and error-prone.
And it only helps with reachability, not regular traversals, so it's not
very generic. Which makes me think the bitmap route is a much better way
to go.
-Peff
^ permalink raw reply
* Re: [PATCH 0/2] optimizing pack access on "read only" fetch repos
From: Jeff King @ 2013-02-01 9:14 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <CAJo=hJuGw8x=VrjWhvZhzakuhWrCWr2FRuEsNt5gQNC=6PPuVw@mail.gmail.com>
On Thu, Jan 31, 2013 at 08:47:37AM -0800, Shawn O. Pearce wrote:
> >> - System resource cost we incur by having to keep 50 file
> >> descriptors open and maintaining 50 mmap windows will reduce by
> >> 50 fold.
> >
> > I wonder how measurable that is (and if it matters on Linux versus less
> > efficient platforms).
>
> It does matter. We know it has a negative impact on JGit even on Linux
> for example. You don't want 300 packs in a repository. 50 might be
> tolerable. 300 is not.
I'd love to see numbers if you have them. It's not that I don't believe
it is slower, but knowing _how much_ is important when thinking about
what kind of performance increase we are looking to get (which in turn
impacts how much effort to put into the repacking).
-Peff
^ permalink raw reply
* Re: Re: Segmentation fault with latest git (070c57df)
From: Jongman Heo @ 2013-02-01 9:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Thomas Rast, git, Antoine Pelisse
Junio C Hamano<gitster@pobox.com> wrote :
> 허종만 writes:
>> But usually when I build upstream Linux kernel, I don't do "make
>> clean" after git pull.. I didn't expect that I needed "make
>> clean" for git build.
>
> We don't expect anybody need "make clean", either. There is
> something wrong in the dependency.
Hi all,
I can reproduce the issue in my machine (RedHat Enterprise 5, x86 PAE) as follows.
But in my different machine (Fedora 16 x86) I can't reproduce.
$ git reset --hard v1.8.1 # back to v1.8.1
$ make clean
$ make all install # this git works fine
$ git pull # top commit 9a6c84e6, "Merge git://ozlabs.org/~paulus/gitk"
$ make all install
$ git fetch # this git segfaults
Segmentation fault
So if there is any patch to test, just let me know (but will not available during weekend).
Regards,
Jongman Heo
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Jeff King @ 2013-02-01 9:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Duy Nguyen, Shawn O. Pearce
In-Reply-To: <7vk3qvm962.fsf@alter.siamese.dyndns.org>
On Tue, Jan 29, 2013 at 11:17:41PM -0800, Junio C Hamano wrote:
> > True, but it is even less headache if the file is totally separate and
> > optional.
>
> Once you start thinking about using an offset to some list of SHA-1,
> perhaps? A section inside the same file can never go out of sync.
Yes, having a data dependency is important. It is unavoidable to have a
dependency on the packfile, though (and that is why the index and the
metapacks embed the sha1 of the packfile). If the offsets used are
packfile offsets, then that is sufficient.
If the offsets are from the index, then yes, putting it in the same file
is one way to keep them tied together. Another way is to do the same
sha1 verification, except to embed the sha1 of the index in the
metapack.
So I certainly consider putting the dependency-handling to be a point in
favor of the same file, but I'd weight it against other points (headache
of bumping index version, performance of both types, etc).
> Also a longer-term advantage is that you can teach index-pack to do
> this.
I think that is roughly the same amount of difficulty to do whether they
are in the same file or not.
-Peff
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Jeff King @ 2013-02-01 9:42 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git, Duy Nguyen
In-Reply-To: <CAJo=hJv0aqLpitnRJ6WKdPCETT6YgX5Njpv44DAYUg_KALhf=g@mail.gmail.com>
On Thu, Jan 31, 2013 at 09:03:26AM -0800, Shawn O. Pearce wrote:
> > Of course, it is more convenient to store this kind of things in a
> > separate file while experimenting and improving the mechanism, but I
> > do not think we want to see each packfile in a repository comes with
> > 47 auxiliary files with different suffixes 5 years down the road.
>
> Arrrrgggh.
>
> Right now we are in the middle of refactoring the JGit reachability
> bitmap implementation to store it into a separate file and get it out
> of the .idx file. This work is nearly completed. So this thread is
> great timing. :-)
>
> I think Junio is right about not wanting 47 different tiny auxiliary
> files for a single pack. We are unlikely to create that many, but
> right now there are proposals floating around for at least 2 new
> auxiliary files (commit cache and reachability bitmaps). So its not
> impossible that another will be discovered in the future.
Why don't we want 47 files (or even 3)? If it makes the implementation
more flexible or simple without sacrificing performance, I don't see a
problem. The filesystem is there to organize our data; we do not cram
all of our files into one just to save a few inodes.
We _do_ cram our data into packfiles and packed-refs when we can save
O(n) inodes. But if we are talking about a handful of extra files that
we must readdir() over while preparing the objects/pack directory, I
don't think that is the same thing.
The data dependency issues (can the files get out of sync? How common is
it? Can we detect it?) and performance issues are more interesting to
me. With respect to the latter, here's specifically what I'm thinking
of. Let's imagine we have an extension for reachability bitmaps that
takes up an extra 10MB. When we mmap the .idx file, do we always mmap
the extra bytes? What's the performance impact of the extra mmap? I
recall on some non-Linux systems it can be quite expensive. For most git
commands which are not going to do a reachability analysis, this is a
loss.
I don't know if this is an issue big enough to care about or not. But I
think it's worth benchmarking and including in the decision.
> Junio may be right about the hole in the index file for git-core. I
> haven't checked the JGit implementation, but I suspect it does not
> have this hole. IIRC JGit consumes the index sections and then expects
> the pack trailer SHA-1 to be present immediately after the last table.
> This happens because JGit doesn't use mmap() to load the index, it
> streams the file into memory and does some reformatting on the tables
> to make search faster.
Yeah, looking at the PackIndexV2 implementation, it counts the 64-bit
offsets from the first table, calculates the size of the large offset
table, reads past it, and then expects the pack checksum. So let's
assume we would have to bump to v3 to implement it inside the .idx file.
> If we are going to change the index to support extension sections and
> I have to modify JGit to grok this new format, it needs to be index v3
> not index v2. If we are making index v3 we should just put index v3 on
> the end of the pack file.
I'm not sure what you mean by your last sentence here.
-Peff
^ permalink raw reply
* Re: Re: Segmentation fault with latest git (070c57df)
From: Jeff King @ 2013-02-01 9:57 UTC (permalink / raw)
To: Jongman Heo; +Cc: Junio C Hamano, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <17285958.791361359710080706.JavaMail.weblogic@epml01>
On Fri, Feb 01, 2013 at 09:14:41AM +0000, Jongman Heo wrote:
> I can reproduce the issue in my machine (RedHat Enterprise 5, x86 PAE) as follows.
Great, thanks for taking the time to reproduce.
> But in my different machine (Fedora 16 x86) I can't reproduce.
That makes me wonder if it is related to the gcc or make version. I
couldn't reproduce the problem on my gcc-4.1 system, though. My make is:
$ make --version
GNU Make 3.81
[...]
> $ git reset --hard v1.8.1 # back to v1.8.1
> $ make clean
> $ make all install # this git works fine
After this step, what does builtin/.depend/fetch.o.d contain? It should
show a dependency of builtin/fetch.o on string-list (among other
things).
> $ git pull # top commit 9a6c84e6, "Merge git://ozlabs.org/~paulus/gitk"
> $ make all install
Can you try running "make -d builtin/fetch.o" here instead of "make all
install"? Can you confirm that it reads builtin/.depend/fetch.o, and
that fetch.o gets rebuilt (you should even be able to see the list of
"newer than" dependencies in the debug output)?
Another thing to double-check: does it work if you instead run
make all install COMPUTE_HEADER_DEPENDENCIES=no
?
-Peff
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Jeff King @ 2013-02-01 10:00 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130130135607.GA23154@lanh>
On Wed, Jan 30, 2013 at 08:56:07PM +0700, Nguyen Thai Ngoc Duy wrote:
> Another point, but not really important at this stage, I think we have
> memory leak somewhere (lookup_commit??). It used up to 800 MB RES on
> linux-2.6.git while generating the cache.
We generate (and then leak!) the linked list in commit_metapack_write.
That may be the culprit.
-Peff
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Jeff King @ 2013-02-01 10:15 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130131110656.GA28093@lanh>
On Thu, Jan 31, 2013 at 06:06:56PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Wed, Jan 30, 2013 at 09:16:29PM +0700, Duy Nguyen wrote:
> > Perhaps we could store abbrev sha-1 instead of full sha-1. Nice
> > space/time trade-off.
>
> Following the on-disk format experiment yesterday, I changed the
> format to:
>
> - a list a _short_ SHA-1 of cached commits
> - a list of cache entries, each (5 uint32_t) consists of:
> - uint32_t for the index in .idx sha-1 table to get full SHA-1 of
> the commit
> - uint32_t for timestamp
> - uint32_t for tree, 1st and 2nd parents for the index in .idx
> table
Thanks for working on this, as it was the next step I was going to take. :)
The short-sha1 is a clever idea. Looks like it saves us on the order of
4MB for linux-2.6 (versus the full 20-byte sha1). Not as big as the
savings we get from dropping the other 3 sha1's to uint32_t, but still
not bad.
I guess the next steps in iterating on this would be:
1. splitting out the refactoring here into separate patches
2. squashing the cleaned-up bits into my patch 4/6
3. deciding whether this should go into a separate file or as part of
index v3. Your offsets depend on the .idx file having a sorted sha1
list. That is not likely to change, but it would still be nice to
make sure they cannot get out of sync. I'm still curious what the
performance impact is for mmap-ing N versus N+8MB.
> The length of SHA-1 is chosen to be able to unambiguously identify any
> cached commits. Full SHA-1 check is done after to catch false
> positives.
Just to be clear, these false positives come because the abbreviation is
unambiguous within the packfile, but we might be looking for a commit
that is not even in our pack, right?
-Peff
^ permalink raw reply
* [PATH/RFC] Revert "compat: add strtok_r()"
From: Erik Faye-Lund @ 2013-02-01 10:33 UTC (permalink / raw)
To: git; +Cc: Erik Faye-Lund
This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.
commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
the only call-site for strtok_r. So let's get rid of the compat
implementation as well.
Conflicts:
Makefile
config.mak.in
configure.ac
---
I just noticed that we have an unused compat-implementation of strtok_r,
so here's a patch to get rid of it.
Makefile | 6 ------
compat/strtok_r.c | 61 -------------------------------------------------------
configure.ac | 6 ------
git-compat-util.h | 5 -----
4 files changed, 78 deletions(-)
delete mode 100644 compat/strtok_r.c
diff --git a/Makefile b/Makefile
index 1b30d7b..6d16a52 100644
--- a/Makefile
+++ b/Makefile
@@ -98,8 +98,6 @@ all::
#
# Define NO_MKSTEMPS if you don't have mkstemps in the C library.
#
-# Define NO_STRTOK_R if you don't have strtok_r in the C library.
-#
# Define NO_FNMATCH if you don't have fnmatch in the C library.
#
# Define NO_FNMATCH_CASEFOLD if your fnmatch function doesn't have the
@@ -1202,10 +1200,6 @@ endif
ifdef NO_STRTOULL
COMPAT_CFLAGS += -DNO_STRTOULL
endif
-ifdef NO_STRTOK_R
- COMPAT_CFLAGS += -DNO_STRTOK_R
- COMPAT_OBJS += compat/strtok_r.o
-endif
ifdef NO_FNMATCH
COMPAT_CFLAGS += -Icompat/fnmatch
COMPAT_CFLAGS += -DNO_FNMATCH
diff --git a/compat/strtok_r.c b/compat/strtok_r.c
deleted file mode 100644
index 7b5d568..0000000
--- a/compat/strtok_r.c
+++ /dev/null
@@ -1,61 +0,0 @@
-/* Reentrant string tokenizer. Generic version.
- Copyright (C) 1991,1996-1999,2001,2004 Free Software Foundation, Inc.
- This file is part of the GNU C Library.
-
- The GNU C Library is free software; you can redistribute it and/or
- modify it under the terms of the GNU Lesser General Public
- License as published by the Free Software Foundation; either
- version 2.1 of the License, or (at your option) any later version.
-
- The GNU C Library is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public
- License along with the GNU C Library; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
- 02111-1307 USA. */
-
-#include "../git-compat-util.h"
-
-/* Parse S into tokens separated by characters in DELIM.
- If S is NULL, the saved pointer in SAVE_PTR is used as
- the next starting point. For example:
- char s[] = "-abc-=-def";
- char *sp;
- x = strtok_r(s, "-", &sp); // x = "abc", sp = "=-def"
- x = strtok_r(NULL, "-=", &sp); // x = "def", sp = NULL
- x = strtok_r(NULL, "=", &sp); // x = NULL
- // s = "abc\0-def\0"
-*/
-char *
-gitstrtok_r (char *s, const char *delim, char **save_ptr)
-{
- char *token;
-
- if (s == NULL)
- s = *save_ptr;
-
- /* Scan leading delimiters. */
- s += strspn (s, delim);
- if (*s == '\0')
- {
- *save_ptr = s;
- return NULL;
- }
-
- /* Find the end of the token. */
- token = s;
- s = strpbrk (token, delim);
- if (s == NULL)
- /* This token finishes the string. */
- *save_ptr = token + strlen (token);
- else
- {
- /* Terminate the token and make *SAVE_PTR point past it. */
- *s = '\0';
- *save_ptr = s + 1;
- }
- return token;
-}
diff --git a/configure.ac b/configure.ac
index 1991258..f3462d9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -901,12 +901,6 @@ GIT_CHECK_FUNC(strcasestr,
[NO_STRCASESTR=YesPlease])
GIT_CONF_SUBST([NO_STRCASESTR])
#
-# Define NO_STRTOK_R if you don't have strtok_r
-GIT_CHECK_FUNC(strtok_r,
-[NO_STRTOK_R=],
-[NO_STRTOK_R=YesPlease])
-GIT_CONF_SUBST([NO_STRTOK_R])
-#
# Define NO_FNMATCH if you don't have fnmatch
GIT_CHECK_FUNC(fnmatch,
[NO_FNMATCH=],
diff --git a/git-compat-util.h b/git-compat-util.h
index e5a4b74..89a44ab 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -408,11 +408,6 @@ extern uintmax_t gitstrtoumax(const char *, char **, int);
extern intmax_t gitstrtoimax(const char *, char **, int);
#endif
-#ifdef NO_STRTOK_R
-#define strtok_r gitstrtok_r
-extern char *gitstrtok_r(char *s, const char *delim, char **save_ptr);
-#endif
-
#ifdef NO_HSTRERROR
#define hstrerror githstrerror
extern const char *githstrerror(int herror);
--
1.8.0.msysgit.0.3.gd0186ec
^ permalink raw reply related
* Re: [PATH/RFC] Revert "compat: add strtok_r()"
From: Erik Faye-Lund @ 2013-02-01 10:37 UTC (permalink / raw)
To: git; +Cc: Erik Faye-Lund
In-Reply-To: <1359714786-1912-1-git-send-email-kusmabite@gmail.com>
On Fri, Feb 1, 2013 at 11:33 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.
>
> commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
> the only call-site for strtok_r. So let's get rid of the compat
> implementation as well.
>
> Conflicts:
> Makefile
> config.mak.in
> configure.ac
> ---
>
> I just noticed that we have an unused compat-implementation of strtok_r,
> so here's a patch to get rid of it.
>
Ugh, I forgot this part:
diff --git a/config.mak.uname b/config.mak.uname
index bea34f0..7f3018f 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -321,7 +321,6 @@ ifeq ($(uname_S),Windows)
NO_UNSETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
- NO_STRTOK_R = YesPlease
NO_FNMATCH = YesPlease
NO_MEMMEM = YesPlease
# NEEDS_LIBICONV = YesPlease
@@ -476,7 +475,6 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_UNSETENV = YesPlease
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
- NO_STRTOK_R = YesPlease
NO_FNMATCH = YesPlease
NO_MEMMEM = YesPlease
NEEDS_LIBICONV = YesPlease
^ permalink raw reply related
* Re: [PATCH 4/6] introduce a commit metapack
From: Jeff King @ 2013-02-01 10:40 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130131110656.GA28093@lanh>
On Thu, Jan 31, 2013 at 06:06:56PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Wed, Jan 30, 2013 at 09:16:29PM +0700, Duy Nguyen wrote:
> > Perhaps we could store abbrev sha-1 instead of full sha-1. Nice
> > space/time trade-off.
>
> Following the on-disk format experiment yesterday, I changed the
> format to:
>
> - a list a _short_ SHA-1 of cached commits
> - a list of cache entries, each (5 uint32_t) consists of:
> - uint32_t for the index in .idx sha-1 table to get full SHA-1 of
> the commit
> - uint32_t for timestamp
> - uint32_t for tree, 1st and 2nd parents for the index in .idx
> table
BTW, I needed the minor fixups below to silence some warnings from your
patch. Here are the cold and warm cache timings I got, as compared to
stock git and my implementation:
Pack | Cold Revs | Warm Revs
-------+--------------+------------
stock | 12.54 | 4.14
me | 4.76 (-62%) | 0.66 (-84%)
duy | 4.36 (-65%) | 0.55 (-86%)
Not surprising; yours is just a bit faster in terms of CPU, and even
gains a little more in the cold cache case. Nice. Of course that is just
gravy on top of the smaller disk usage, too. :)
---
diff --git a/commit-metapack.c b/commit-metapack.c
index c984b8e..78fd961 100644
--- a/commit-metapack.c
+++ b/commit-metapack.c
@@ -106,7 +106,7 @@ int commit_metapack(unsigned char *sha1,
for (p = commit_metapacks; p; p = p->next) {
struct commit_entry *data;
uint32_t p1, p2;
- unsigned lo, hi, mi;
+ unsigned lo, hi;
int pos;
/* sha1_entry_pos does not work with abbreviated sha-1 */
@@ -161,7 +161,7 @@ static void get_commits(struct metapack_writer *mw,
struct write_cb *write_cb = (struct write_cb *)data;
enum object_type type = sha1_object_info(sha1, NULL);
struct commit *c;
- int p1, p2;
+ int p1 = -1, p2 = -1;
if (type != OBJ_COMMIT)
return;
diff --git a/commit.c b/commit.c
index b326201..5b776f8 100644
--- a/commit.c
+++ b/commit.c
@@ -309,7 +309,7 @@ static int parse_commit_metapack(struct commit *item)
static int parse_commit_metapack(struct commit *item)
{
- unsigned char *tree, *p1, *p2;
+ const unsigned char *tree, *p1, *p2;
uint32_t ts;
if (commit_metapack(item->object.sha1, &ts, &tree, &p1, &p2) < 0)
^ permalink raw reply related
* Re: Re: Re: Segmentation fault with latest git (070c57df)
From: Jeff King @ 2013-02-01 10:44 UTC (permalink / raw)
To: Jongman Heo; +Cc: Junio C Hamano, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <32006438.796571359714624362.JavaMail.weblogic@epml01>
On Fri, Feb 01, 2013 at 10:30:24AM +0000, Jongman Heo wrote:
> Short answer;
>
> * Version of make is 3.81 on both machines
> * builtin/fetch.o is not rebuilt (see entire log below)
> * git works fine with "make all install COMPUTE_HEADER_DEPENDENCIES=no"
OK, that gets us closer. It's definitely a problem with the automatic
header dependencies, then.
> [...make debug output...]
> Reading makefile `builtin/.depend/fetch.o.d' (search path) (no ~ expansion)...
So we definitely have the dep file...
> [...]
> Finished prerequisites of target file `builtin/fetch.o'.
> Prerequisite `builtin/fetch.c' is older than target `builtin/fetch.o'.
> Prerequisite `GIT-CFLAGS' is older than target `builtin/fetch.o'.
> No need to remake target `builtin/fetch.o'.
But it doesn't stimulate any prerequisites in make, which is weird.
What's in builtin/.depend/fetch.o.d?
-Peff
^ permalink raw reply
* Re: Re: Re: Re: Segmentation fault with latest git (070c57df)
From: Jongman Heo @ 2013-02-01 10:59 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Thomas Rast, git, Antoine Pelisse
>> [...]
>> Finished prerequisites of target file `builtin/fetch.o'.
>> Prerequisite `builtin/fetch.c' is older than target `builtin/fetch.o'.
>> Prerequisite `GIT-CFLAGS' is older than target `builtin/fetch.o'.
>> No need to remake target `builtin/fetch.o'.
>
>But it doesn't stimulate any prerequisites in make, which is weird.
>What's in builtin/.depend/fetch.o.d?
>
>-Peff
Hi,
please see below~.
$ cat builtin/.depend/fetch.o.d
fetch.o: builtin/fetch.c cache.h git-compat-util.h compat/bswap.h \
strbuf.h hash.h advice.h gettext.h convert.h refs.h commit.h object.h \
tree.h decorate.h builtin.h cache.h commit.h notes.h string-list.h \
string-list.h remote.h transport.h remote.h run-command.h \
parse-options.h sigchain.h submodule.h connected.h argv-array.h
cache.h:
git-compat-util.h:
compat/bswap.h:
strbuf.h:
hash.h:
advice.h:
gettext.h:
convert.h:
refs.h:
commit.h:
object.h:
tree.h:
decorate.h:
builtin.h:
cache.h:
commit.h:
notes.h:
string-list.h:
string-list.h:
remote.h:
transport.h:
remote.h:
run-command.h:
parse-options.h:
sigchain.h:
submodule.h:
connected.h:
argv-array.h:
^ permalink raw reply
* Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
From: John Keeping @ 2013-02-01 11:16 UTC (permalink / raw)
To: Michael Haggerty; +Cc: John Keeping, git
In-Reply-To: <510B7F4B.7040902@alum.mit.edu>
On Fri, Feb 01, 2013 at 09:39:39AM +0100, Michael Haggerty wrote:
> On 01/30/2013 09:31 PM, John Keeping wrote:
> > On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote:
> >> [...] maybe we should establish a small Python library of
> >> compatibility utilities (like a small "six"). [...]
> >> But I haven't had time to think of where to put such a library, how to
> >> install it, etc.
> >
> > If we want to go that route, I think restructuring the
> > "git_remote_helpers" directory and re-using its infrastructure for
> > installing the "Git Python modules" would be the way to go. The
> > directory structure would become something like this:
> >
> > git/
> > `-- python/
> > |-- Makefile # existing file pulled out of git_remote_helpers
> > |-- < some new utility library >
> > |-- git_remote_helpers
> > | |-- __init__.py
> > | |-- git
> > | | |-- __init__.py
> > | | |-- exporter.py
> > | | |-- git.py
> > | | |-- importer.py
> > | | |-- non_local.py
> > | | `-- repo.py
> > | `-- util.py
> > |-- setup.cfg # existing file pulled out of git_remote_helpers
> > `-- setup.py # existing file pulled out of git_remote_helpers
> >
> >
> > It looks like the GitPython project[1] as already taken the "git" module
> > name, so perhaps we should use "git_core" if we do introduce a new
> > module.
> >
> > [1] http://pypi.python.org/pypi/GitPython
>
> This sounds reasonable. But not all Python code will go under the
> "python" subdirectory, right? For example, I am working on a Python
> script that fits thematically under contrib/hooks.
I was thinking of it as analagous with the "perl" directory that
currently exists. So the "python" directory will contain library code
but scripts can live wherever is most appropriate.
One way of looking at it is: could the user want to have this installed
for all available versions of Python? For a script, the answer is "no"
because they will call it and it will just run. For libraries, you want
them to be available with whatever Python interpreter you happen to be
running (assuming that it is a version supported by the library).
> OTOH (I'm thinking aloud here) it is probably a bad idea for a hook
> script to depend on a Python module that is part of git itself. Doing
> so would make the hook script depend on a particular version of git (or
> at least a version with a compatible Python module). But users might be
> reluctant to upgrade git just to install a hook script.
I don't think such a dependency is a bad idea in the longer term. If a
"Git Python library" is developed, then at some point most people who
have Git installed will have some version of that library - it becomes a
case of perhaps wanting to limit yourself to some subset of the library
rather than just not using it.
In fact, git_remote_helpers has been available since Git 1.7.0 and
contains a lot of functionality that is more generic than its name
suggests.
John
^ permalink raw reply
* Aw: Re: Aw: Re: [PATCH v3 3/6] Change 'git' to 'Git' whenever the whole system is referred to #2
From: Thomas Ackermann @ 2013-02-01 18:04 UTC (permalink / raw)
To: gitster, th.acker; +Cc: git, davvid
In-Reply-To: <7vzjzodfp1.fsf@alter.siamese.dyndns.org>
>
> I think we have waited long enough and as far as I recall we didn't
> see any reports of misconversion or forgotten conversion, so I'll
> squash the fixes parked on the topic branch, whose tip is at
> bfb8e1eb6375afb (fixup! Change 'git' to 'Git' whenever the whole
> system is referred to #4, 2013-01-22), and merge the result to
> 'next' sometime tomorrow.
>
Here are my final fixups on top of bfb8e1eb6375afb:
I morphed the remarks from Junio and David into patch form and
also did the reverse check for wrong usage of 'Git' instead of 'git'.
While doing the later I also noticed some small glitches and fixed them.
Squash at your will.
[PATCH 1/6] fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #2
[PATCH 2/6] fixup! fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
[PATCH 3/6] fixup! Documentation: avoid poor-man's small caps
[PATCH 4/6] Fix places where 'Git' should be 'git
[PATCH 5/6] Add a description for 'gitfile' to glossary
[PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
---
Thomas
^ permalink raw reply
* [PATCH 1/6] fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #2
From: Thomas Ackermann @ 2013-02-01 18:06 UTC (permalink / raw)
To: gitster, th.acker; +Cc: git, davvid
In-Reply-To: <210945773.1090030.1359741840305.JavaMail.ngmail@webmail18.arcor-online.net>
Found by David and Junio:
Inconsistent quoting within config.txt should be fixed in a separate patch.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/config.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3652ee0..1bfbc7a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1773,7 +1773,7 @@ pull.twohead::
The default merge strategy to use when pulling a single branch.
push.default::
- Defines the action Git push should take if no refspec is given
+ Defines the action `git push` should take if no refspec is given
on the command line, no refspec is configured in the remote, and
no refspec is implied by any of the options given on the command
line. Possible values are:
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* [PATCH 2/6] fixup! fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
From: Thomas Ackermann @ 2013-02-01 18:07 UTC (permalink / raw)
To: gitster, th.acker; +Cc: git, davvid
In-Reply-To: <210945773.1090030.1359741840305.JavaMail.ngmail@webmail18.arcor-online.net>
Found by Junio:
Change git-dir to $GIT_DIR and git-file to gitfile.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/git-rev-parse.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index c743469..14386ed 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -187,9 +187,9 @@ print a message to stderr and exit with nonzero status.
Flags and parameters to be parsed.
--resolve-git-dir <path>::
- Check if <path> is a valid git-dir or a git-file pointing to a valid
- git-dir. If <path> is a valid git-dir the resolved path to git-dir will
- be printed.
+ Check if <path> is a valid `$GIT_DIR` or a gitfile pointing to a valid
+ `$GIT_DIR`. If <path> is a valid `$GIT_DIR` the resolved path to `$GIT_DIR`
+ will be printed.
include::revisions.txt[]
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* [PATCH 3/6] fixup! Documentation: avoid poor-man's small caps
From: Thomas Ackermann @ 2013-02-01 18:08 UTC (permalink / raw)
To: gitster, th.acker; +Cc: git, davvid
In-Reply-To: <210945773.1090030.1359741840305.JavaMail.ngmail@webmail18.arcor-online.net>
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/git-tools.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
index 338986a..ad8b823 100644
--- a/Documentation/git-tools.txt
+++ b/Documentation/git-tools.txt
@@ -29,7 +29,7 @@ Alternative/Augmentative Porcelains
- *pg* (http://www.spearce.org/category/projects/scm/pg/)
pg is a shell script wrapper around Git to help the user manage a set of
- patches to files. pg is somewhat like quilt or StGIT, but it does have a
+ patches to files. pg is somewhat like quilt or StGit, but it does have a
slightly different feature set.
@@ -60,7 +60,7 @@ History Viewers
- *qgit* (http://digilander.libero.it/mcostalba/)
- QGit is a git/StGIT GUI viewer built on Qt/C++. QGit could be used
+ QGit is a git/StGit GUI viewer built on Qt/C++. QGit could be used
to browse history and directory tree, view annotated files, commit
changes cherry picking single files or applying patches.
Currently it is the fastest and most feature rich among the Git
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* Re: [PATCH] Verify Content-Type from smart HTTP servers
From: Junio C Hamano @ 2013-02-01 18:09 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, git
In-Reply-To: <20130201085248.GA30644@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Should this be "From:" Shawn? The tone of the message and the S-O-B
> order makes it look like it.
Yes. I should have left that line when edited the format-patch
output in my MUA to say I was resending something that vger rejected
and people did not see after tweaking the patch to slip their taboo
list.
>> @@ -133,16 +135,19 @@ static struct discovery* discover_refs(const char *service)
>> last->buf = last->buf_alloc;
>>
>> if (maybe_smart && 5 <= last->len && last->buf[4] == '#') {
>> - /* smart HTTP response; validate that the service
>> + /*
>> + * smart HTTP response; validate that the service
>> * pkt-line matches our request.
>> */
>> - struct strbuf exp = STRBUF_INIT;
>> -
>> + strbuf_addf(&exp, "application/x-%s-advertisement", service);
>> + if (strbuf_cmp(&exp, &type))
>> + die("invalid content-type %s", type.buf);
>
> Hmm. I wondered if it is possible for a non-smart server to send us down
> this code path, which would now complain of the bogus content-type.
> Something like an info/refs file with:
>
> # 1
> # the comment above is meaningless, but puts a "#" at position 4.
>
> But I note that we would already die in the next line:
>
>> if (packet_get_line(&buffer, &last->buf, &last->len) <= 0)
>> die("%s has invalid packet header", refs_url);
>
> so I do not think the patch makes anything worse. However, should we
> take this opportunity to make the "did we get a smart response" test
> more robust? That is, should we actually be checking the content-type
> in the outer conditional, and going down the smart code-path if it is
> application/x-%s-advertisement, and otherwise treating the result as
> dumb?
Does the outer caller that switches between dumb and smart actually
know what service type it is requesting (I am not familiar with the
callchain involved)? Even if it doesn't, it may still make sense.
> As a side note, should we (can we) care about the content-type for dumb
> http? It should probably be text/plain or application/octet-stream, but
> I would not be surprised if we get a variety of random junk in the real
> world, though.
The design objective of dumb http protocol was to allow working with
any dumb bit transfer thing, so I'd prefer to keep it lenient and
allow application/x-git-loose-object-file and somesuch.
Thanks.
^ 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