With the conversion of HTML documentation to man pages
tutorial.html -> gittutorial (7)
tutorial-2.html -> gittutorial-2 (7)
cvs-migration.html -> gitcvs-migration (7)
diffcore.html -> gitdiffcore (7)
repository-layout.html -> gitrepository-layout (5)
hooks.html -> githooks (5)
glossary.html -> gitglossary (7)
core-tutorial.html -> gitcore-tutorial (7)
and the automatic update of references to these pages,
a little debris was left behind. We clear it away.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Higher stages store the blobs involved from their side verbatim. Removal
of uninteresting hunks are done by "diff --cc" upon demand and not stored
in the index.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch renames the following documents and at the same time converts
them to the man format:
core-tutorial.txt -> gitcore-tutorial.txt
glossary.txt -> gitglossary.txt
But as the glossary is included in the user manual and as the new
gitglossary man page cannot be included as a whole in the user manual,
the actual glossary content is now in its own "glossary-content.txt"
new file. And this file is included by both the user manual and the
gitglossary man page.
Other documents that reference the above ones are changed accordingly
and sometimes improved a little too.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch renames the following documents and at the same time converts
them to the man page format:
cvs-migration.txt -> gitcvs-migration.txt
tutorial.txt -> gittutorial.txt
tutorial-2.txt -> gittutorial-2.txt
These new man pages are put in section 7, and other documents that reference
the above ones are change accordingly.
[jc: with help from Nanako to clean things up]
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
25ee9731c1 made the '--prune' option
deprecated and removed its description from the git-gc man page. This
patch removes all references to this option from the rest of the Git
documentation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Texts between ~ and ~ will be subscripted during the asciidoc translation.
Signed-off-by: Guanqun Lu <Guanqun.Lu@Gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock
Asciidoc configuration:
@@ -149,7 +153,10 @@
# Inline macros.
# Backslash prefix required for escape processing.
# (?s) re flag for line spanning.
-(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
+# Explicit so they can be nested.
+(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
# Anchor: [[[id]]]. Bibliographic anchor.
(?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3
# Anchor: [[id,xreflabel]]
This default regex now matches explicit values, and unfortunately in this
case gitlink was being matched by just 'link', causing the wrong inline
macro template to be applied. By renaming the macro, we can avoid being
matched by the wrong regex.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
Acked-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Replace the word 'update-cache' by 'update-index' everywhere
cvsimport: fix usage of cvsimport.module
t7003-filter-branch: Fix test of a failing --msg-filter.
cvsimport: miscellaneous packed-ref fixes
cvsimport: use rev-parse to support packed refs
Add basic cvsimport tests
* maint:
user-manual: recovering from corruption
user-manual: clarify language about "modifying" old commits
user-manual: failed push to public repository
user-manual: define "branch" and "working tree" at start
git-checkout: describe detached head correctly
Some instructions on dealing with corruption of the object database.
Most of this text is from an example by Linus, identified by Nicolas
Pitre <nico@cam.org> with a little further editing by me.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
It's important to remember that git doesn't really allowing "editing" or
"modifying" commits, only replacing them by new commits. Redo some of
the language to make this clearer.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
* maint:
Documentation: Fix references to deprecated commands
user-manual: mention "..." in "Generating diffs", etc.
user-manual: Add section "Why bisecting merge commits can be harder ..."
git-remote.txt: fix example url
We should mention the use of the "..." syntax for git-diff here. The
note about the difference between diff and the combined output of
git-format-patch then no longer fits so well, so remove it. Add a
reference to the git-format-patch[1] manpage.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
This commit adds a discussion of the challenge of bisecting
merge commits to the user manual. The original author is
Junio C Hamano <gitster@pobox.com>, who posted the text to
the mailing list <http://marc.info/?l=git&m=119403257315527&w=2>.
His email was adapted for the manual.
The discussion is added to "Rewriting history and maintainig
patch series". The text added requires good understanding of
merging and rebasing. Therefore it should not be placed too
early in the manual. Right after the section on "Problems with
rewriting history", the discussion of bisect gives another reason
for linearizing as much of the history as possible.
The text includes suggestions and fixes by
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> and
Benoit Sigoure <tsuna@lrde.epita.fr>.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Junio screwed up when applying the previous round of the patch;
rewording from "previous" to "old" does make the description
clearer.
Also revert the rewording from head to branch. The description
is talking about the branch's tip commit and using the word head
is clearer.
Based on input from Sergei and Bruce.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Just for consistency, use the spelling URL everywhere.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If I'm handed a file, then it typically lives outside the
working directory. git-log only operates on in-tree files,
so the first 'filename' should be an in-tree one, or it should
look at all files. This patch does the latter, so it would
also find renamed files. However, it is also slower.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
em dashes were used inconsistently in the manual.
This changes them to the way they are used in US English.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rework the introduction to the Submodules section to explain why
someone would use them, and fix up submodule references from the
tree-object and todo sections.
Signed-off-by: Michael Smith <msmith@cbnco.com>
Acked-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Michael Smith <msmith@cbnco.com>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The scripts taken from Tony Luck's howto assume all refs can be found
under .git/refs, but this is not necessarily true, especially since
git-gc runs git-pack-refs.
Also add a note warning of this in the chapter that introduces refs, and
fix the same incorrect assumption in one other spot.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Actually I don't think we've previously mentioned .git/objects, so we
need a different introduction here.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Rewrite the introduction. Rewrite each section completely to make them
work in the new order, to add some examples, and to move plumbing
commands (like git-commit-tree) to the following chapter.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The bottom-up blog, tree, commit order makes sense unless you want to
give explicit examples--it's easier to discover objects to examine if
you go in the other order....,
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Add an example using git-ls-files, standardize on the new "index"
terminology (as opposed to "cache"), attempt to clarify discussion and
make it a little shorter, avoid some unnecessary jargon ("write-back
cache").
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The low-level index operations aren't as important to regular users as
the rest of this "git concepts" chapter; so move it into a separate
chapter, and do some minor cleanup.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
"git internals" sounds like something only git developers must know
about, but this stuff should be of wider interest. Rename the chapter
and give it a slightly friendlier introduction.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The descriptions of the various object types should all be a subsection
of the "Object Database" section.
I cribbed most of this chapter from the README (now core-intro.txt and
git(7)), because there's stuff in there people need to know and I was
too lazy to rewrite it. The audience isn't quite right, though--the
chapter is a mixture of user- and developer- level documentation that
isn't as appropriate now as it was originally.
So, reserve this chapter for stuff users need to know, and move the
source code introduction into a new "git hacking" chapter where we'll
also move any hacker-only technical details.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Actually, we should have a competition for the favorite example commit.
Criteria:
- length: one-line changes with one-line comments preferred,
and no long lines
- significance/memorability
- comic value
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The immediate motivation for writing this section was to explain the
various places ignore patterns could be used. However, I still think
.gitignore is the case most people will want to learn about first. It
also makes it a bit more concrete to introduce ignore patterns in the
context of .gitignore first. And the existance of gitignore(5) relieves
the pressure to explain it all here.
So, stick to the .gitignore example, with only a brief mention of the
others, explain the syntax only by example, and leave the rest to
gitignore(5).
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Cc: Johan Herland <johan@herland.net>
The git gui project seems to be still in early stages, but at a point
where it's worth mentioning as an alternative way of creating commits.
One feature of interest is the ability to manipulate individual diff
hunks. However, people have found that feature not to be easily
discoverable from the user-interface. Pending some ui improvements, a
parenthetical hint here may help.
(Thanks to Steffen Prohask and Junio Hamano for suggesting the
language.)
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Update documentation to reflect the --track default.
That change seems to have happened in the 1.5.3 -rc's, so bump the "for
version x.y.z or newer" warning as well.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
* maint:
user-manual: fix directory name in git-archive example
user-manual: more explanation of push and pull usage
tutorial: Fix typo
user-manual: grammar and style fixes
Recently a user on the mailing list complained that they'd read the
manual but couldn't figure out how to keep a couple private repositories
in sync. They'd tried using push, and were surprised by the effect.
Add a little text in an attempt to make it clear that:
- Pushing to a branch that is checked out will have odd results.
- It's OK to synchronize just using pull if that's simpler.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
- "method of" is vulgar, "method for" is nicer
- "recovery" becomes "recovering" from Steve Hoelzer's original version
of this patch
- "if you want" is nicer as "if you wish"
- "you may" should be "you can"; "you may" is "you have permission to"
rather than "you can"'s "it is possible to"
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
This one fixes a small formulation weirdness in
Documentation/user-manual.txt
Signed-off-by: Marcus Fritzsch <m@fritschy.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It turns out that the attribute definition we have had for a
long time to hide "^" character from AsciiDoc 7 was not honored
by AsciiDoc 8 even under "-a asciidoc7compatible" mode. There is
a similar breakage with the "compatible" mode with + characters.
The double colon at the end of definition list term needs
to be attached to the term, without a whitespace. After this
minimum fixups, AsciiDoc 8 (I used 8.2.1 on Debian) with
compatibility mode seems to produce reasonably good results.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
tutorial: use "project history" instead of "changelog" in header
Documentation: user-manual todo
user-manual: add a missing section ID
Fix typo in remote branch example in git user manual
user-manual: quick-start updates
In Documentation/user-manual.txt the example
$ git checkout --track -b origin/maint maint
under "Getting updates with git pull", should read
$ git checkout --track -b maint origin/maint
This was noticed by Ron, and reported through
http://bugs.debian.org/427502
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Update text to reflect new position in appendix.
Update the name to reflect the fact that this is closer to reference
than tutorial documentation (as suggested by Jonas Fonseca).
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only git-ls-files(1) describes the gitignore format in detail, and it does so
with reference to git-ls-files options. Most users don't use the plumbing
command git-ls-files directly, and shouldn't have to look in its manpage for
information on the gitignore format.
Create a new manpage gitignore(5) (Documentation/gitignore.txt), and factor
out the gitignore documentation into that file, changing it to refer to
.gitignore and $GIT_DIR/info/exclude as used by porcelain commands. Reference
gitignore(5) from other relevant manpages and documentation. Remove
now-redundant information on exclude patterns from git-ls-files(1), leaving
only information on how git-ls-files options specify exclude patterns and what
precedence they have.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The todo list at the end of the user manual says that something must be
said about .gitignore. Also, there seems to be a lack of documentation
on how to choose between the various types of ignore files (.gitignore
vs. .git/info/exclude, etc.).
This patch adds a section on ignoring files which try to introduce how
to tell git about ignored files, and how the different strategies
complement eachother.
The syntax of exclude patterns is explained in a simplified manner, with
a reference to git-ls-files(1) which already contains a more thorough
explanation.
Signed-off-by: Johan Herland <johan@herland.net>
Another amusing git exploration example brought up in irc. (Credit to
aeruder for the complete solution.)
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I don't really want to look like we're encouraging the shared repository
thing. Take down some of the argument for using purely
single-developer-owned repositories and collaborating using patches and
pulls instead.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Helping a couple people set up public repos recently, I wanted to point
them at this piece of the user manual, but found it wasn't as helpful as
it could be:
- It starts with a big explanation of why you'd want a public
repository, not necessary in their case since they already knew
why they wanted that. So, separate that out.
- It skimps on some of the git-daemon details, and puts the http
export information first. Fix that.
Also group all the public repo subsections into a single section, and do
some miscellaneous related editing.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Move howto/using-topic-branches into the user manual as an example for
the "sharing development" chapter. While we're at it, remove some
discussion that's covered in earlier chapters, modernize somewhat (use
separate-heads setup, remotes, replace "whatchanged" by "log", etc.),
and replace syntax we'd need to explain by syntax we've already covered
(e.g. old..new instead of new ^old).
The result may not really describe what Tony Luck does any more.... Hope
that's not annoying.
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
There seems to be a perception that the howto's are bit-rotting a
little. The manual might be a more visible location for some of them,
and make-dist.txt seems like a good candidate to include as an example
in the manual.
For now, incorporate much of it verbatim. Later we may want to update
the example a bit.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The quick start interrupts the flow of the manual a bit. Move it to
"appendix A" but add a reference to it in the preface. Also rename the
todo chapter to "appendix B", and revise the preface a little.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Some revisions suggested by Junio along with some minor style fixes and
one compile fix (asterisks need escaping).
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
In http://thread.gmane.org/gmane.comp.version-control.git/42479,
a birdview on the source code was requested.
J. Bruce Fields suggested that my reply should be included in the
user manual, and there was nothing of an outcry, so here it is,
not 2 months later.
It includes modifications as suggested by J. Bruce Fields, Karl
Hasselström and Daniel Barkalow.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
* maint:
format-patch: add MIME-Version header when we add content-type.
Fixed link in user-manual
import-tars: Use the "Link indicator" to identify directories
git name-rev writes beyond the end of malloc() with large generations
Documentation/branch: fix small typo in -D example
Currently
$ git grep '\([^t]\|^\)'link: user-manual.txt
gives four hits that refer to .txt version of the documentation
set, but at least "hooks" and "cvs-migration" have HTML variants
installed, so refer to them instead.
Signed-off-by: Junio C Hamano <junkio@cox.net>
More typo fixes from Santi Béjar, plus a couple other mistakes I noticed
along the way.
Cc: Santi Béjar <sbejar@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I cherry-picked some additional miscellaneous fixes from those suggested
by Santi Béjar, including fixes to:
- correct discussion of repository/HEAD->repository shortcut
- add mention of git-mergetool
- add mention of --track
- mention "-f" as well as "+" for fetch
Cc: Santi Béjar <sbejar@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Santi Béjar points out that when telling people how to "introduce
themselves" to git we're advising them to replace their entire
.gitconfig file. Fix that.
Cc: "Santi Béjar <sbejar@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The previous commit calls attention to the fact that we have two
sections each devoted to fast-forwards and to dangling objects. Revise
and attempt to differentiate them a bit. Some more reorganization may
be required later....
Signed-off-by: J. Bruce Fields
Any section lacking an id gets an annoying warning when you build
the manual. More seriously, the table of contents then generates
volatile id's which change with every build, with the effect that
we get URL's that change all the time.
The ID's are manually generated and sometimes inconsistent, but
that's OK.
XXX: what to do about the preface?
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Nicolas Pitre pointed out a couple typos and some room for improvement
in the discussion of detached heads.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Cc: Nicolas Pitre <nico@cam.org>
Most other documentation will frequently be read from an installation
of git so will naturally be associated with the installed version.
But these two documents in particular are often read from web pages
while users are still exploring git. It's important to mention
version 1.5.1 since these documents provide example commands that
won't work with previous versions of git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is slightly simpler if we use a detached head. And it's probably
good to have another example that uses this feature.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a brief mention of detached HEADs and .git/HEAD.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The name "master" isn't actually quite so special. Also, fix some bad
grammar.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
