global/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2026-03-13 10:23:30 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge commit 'mingw/master' into devel

Browse Source 
Conflicts:
	daemon.c
	gitk-git/gitk
	hash-object.c
	imap-send.c
	index-pack.c
	t/t5602-clone-remote-exec.sh
	t/t7004-tag.sh
This commit is contained in:
Steffen Prohaska
2008-12-25 12:14:55 +01:00
parent a5ed0042d9 2fb7da977b
commit e1c3d0dd35
530 changed files with 31756 additions and 11600 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.gitignore vendored
View File

@@ -51,6 +51,7 @@ git-gc
git-get-tar-commit-id
git-grep
git-hash-object
git-help
git-http-fetch
git-http-push
git-imap-send
@@ -117,6 +118,7 @@ git-show
git-show-branch
git-show-index
git-show-ref
git-stage
git-stash
git-status
git-stripspace

14
Documentation/Makefile
View File

@@ -6,7 +6,7 @@ MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
gitrepository-layout.txt
MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
gitdiffcore.txt
gitdiffcore.txt gitworkflows.txt
MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
@@ -44,6 +44,7 @@ MANPAGE_XSL = callouts.xsl
INSTALL?=install
RM ?= rm -f
DOC_REF = origin/man
HTML_REF = origin/html
infodir?=$(prefix)/share/info
MAKEINFO=makeinfo
@@ -86,7 +87,9 @@ man7: $(DOC_MAN7)
info: git.info gitman.info
install: man
install: install-man
install-man: man
$(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
$(INSTALL) -d -m 755 $(DESTDIR)$(man5dir)
$(INSTALL) -d -m 755 $(DESTDIR)$(man7dir)
@@ -219,7 +222,12 @@ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
install-webdoc : html
sh ./install-webdoc.sh $(WEBDOC_DEST)
quick-install:
quick-install: quick-install-man
quick-install-man:
sh ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
quick-install-html:
sh ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir)
.PHONY: .FORCE-GIT-VERSION-FILE

10
Documentation/RelNotes-1.5.4.7.txt Normal file
View File

@@ -0,0 +1,10 @@
GIT v1.5.4.7 Release Notes
==========================
Fixes since 1.5.4.7
-------------------
* Removed support for an obsolete gitweb request URI, whose
implementation ran "git diff" Porcelain, instead of using plumbing,
which would have run an external diff command specified in the
repository configuration as the gitweb user.

10
Documentation/RelNotes-1.5.5.6.txt Normal file
View File

@@ -0,0 +1,10 @@
GIT v1.5.5.6 Release Notes
==========================
Fixes since 1.5.5.5
-------------------
* Removed support for an obsolete gitweb request URI, whose
implementation ran "git diff" Porcelain, instead of using plumbing,
which would have run an external diff command specified in the
repository configuration as the gitweb user.

10
Documentation/RelNotes-1.5.6.6.txt Normal file
View File

@@ -0,0 +1,10 @@
GIT v1.5.6.6 Release Notes
==========================
Fixes since 1.5.6.5
-------------------
* Removed support for an obsolete gitweb request URI, whose
implementation ran "git diff" Porcelain, instead of using plumbing,
which would have run an external diff command specified in the
repository configuration as the gitweb user.

100
Documentation/RelNotes-1.6.0.3.txt
View File

@@ -13,17 +13,105 @@ Fixes since v1.6.0.2
* Continuing "git rebase -i" was also very confused when the user left
some staged changes in the index after "edit".
* "git rebase -i" now honors the pre-rebase hook, just like the
other rebase implementations "git rebase" and "git rebase -m".
* "git rebase -i" incorrectly aborted when there is no commit to replay.
* Behaviour of "git diff --quiet" was inconsistent with "diff --exit-code"
with the output redirected to /dev/null.
* "git diff --no-index" on binary files no longer outputs a bogus
"diff --git" header line.
* "git diff" hunk header patterns with multiple elements separated by LF
were not used correctly.
* Hunk headers in "git diff" default to using extended regular
expressions, fixing some of the internal patterns on non-GNU
platforms.
* New config "diff.*.xfuncname" exposes extended regular expressions
for user specified hunk header patterns.
* "git gc" when ejecting otherwise unreachable objects from packfiles into
loose form leaked memory.
* "git index-pack" was recently broken and mishandled objects added by
thin-pack completion processing under memory pressure.
* "git index-pack" was recently broken and misbehaved when run from inside
.git/objects/pack/ directory.
* "git stash apply sash@{1}" was fixed to error out. Prior versions
would have applied stash@{0} incorrectly.
* "git stash apply" now offers a better suggestion on how to continue
if the working tree is currently dirty.
* "git for-each-ref --format=%(subject)" fixed for commits with no
no newline in the message body.
* "git remote" fixed to protect printf from user input.
* "git remote show -v" now displays all URLs of a remote.
* "git checkout -b branch" was confused when branch already existed.
* "git checkout -q" once again suppresses the locally modified file list.
* "git clone -q", "git fetch -q" asks remote side to not send
progress messages, actually making their output quiet.
* Cross-directory renames are no longer used when creating packs. This
allows more graceful behavior on filesystems like sshfs.
* Stale temporary files under $GIT_DIR/objects/pack are now cleaned up
automatically by "git prune".
* "git merge" once again removes directories after the last file has
been removed from it during the merge.
* "git merge" did not allocate enough memory for the structure itself when
enumerating the parents of the resulting commit.
* "git blame -C -C" no longer segfaults while trying to pass blame if
it encounters a submodule reference.
* "git rm" incorrectly claimed that you have local modifications when a
path was merely stat-dirty.
* "git svn" fixed to display an error message when 'set-tree' failed,
instead of a Perl compile error.
* "git submodule" fixed to handle checking out a different commit
than HEAD after initializing the submodule.
* The "git commit" error message when there are still unmerged
files present was clarified to match "git write-tree".
* "git init" was confused when core.bare or core.sharedRepository are set
in system or user global configuration file by mistake. When --bare or
--shared is given from the command line, these now override such
settings made outside the repositories.
* Some segfaults due to uncaught NULL pointers were fixed in multiple
tools such as apply, reset, update-index.
* Solaris builds now default to OLD_ICONV=1 to avoid compile warnings;
Solaris 8 does not define NEEDS_LIBICONV by default.
* "Git.pm" tests relied on unnecessarily more recent version of Perl.
* "gitweb" triggered undef warning on commits without log messages.
Many other documentation updates.
* "gitweb" triggered undef warnings on missing trees.
--
exec >/var/tmp/1
O=v1.6.0.2-32-g8d11fde
echo O=$(git describe maint)
git shortlog --no-merges $O..maint
* "gitweb" now removes PATH_INFO from its URLs so users don't have
to manually set the URL in the gitweb configuration.
* Bash completion removed support for legacy "git-fetch", "git-push"
and "git-pull" as these are no longer installed. Dashless form
("git fetch") is still however supported.
Many other documentation updates.

39
Documentation/RelNotes-1.6.0.4.txt Normal file
View File

@@ -0,0 +1,39 @@
GIT v1.6.0.4 Release Notes
==========================
Fixes since v1.6.0.3
--------------------
* 'git add -p' said "No changes" when only binary files were changed.
* 'git archive' did not work correctly in bare repositories.
* 'git checkout -t -b newbranch' when you are on detached HEAD was broken.
* when we refuse to detect renames because there are too many new or
deleted files, 'git diff' did not say how many there are.
* 'git push --mirror' tried and failed to push the stash; there is no
point in sending it to begin with.
* 'git push' did not update the remote tracking reference if the corresponding
ref on the remote end happened to be already up to date.
* 'git pull $there $branch:$current_branch' did not work when you were on
a branch yet to be born.
* when giving up resolving a conflicted merge, 'git reset --hard' failed
to remove new paths from the working tree.
* 'git send-email' had a small fd leak while scanning directory.
* 'git status' incorrectly reported a submodule directory as an untracked
directory.
* 'git svn' used deprecated 'git-foo' form of subcommand invocation.
* 'git update-ref -d' to remove a reference did not honor --no-deref option.
* Plugged small memleaks here and there.
* Also contains many documentation updates.

56
Documentation/RelNotes-1.6.0.5.txt Normal file
View File

@@ -0,0 +1,56 @@
GIT v1.6.0.5 Release Notes
==========================
Fixes since v1.6.0.4
--------------------
* "git checkout" used to crash when your HEAD was pointing at a deleted
branch.
* "git checkout" from an un-checked-out state did not allow switching out
of the current branch.
* "git diff" always allowed GIT_EXTERNAL_DIFF and --no-ext-diff was no-op for
the command.
* Giving 3 or more tree-ish to "git diff" is supposed to show the combined
diff from second and subsequent trees to the first one, but the order was
screwed up.
* "git fast-export" did not export all tags.
* "git ls-files --with-tree=<tree>" did not work with options other
than -c, most notably with -m.
* "git pack-objects" did not make its best effort to honor --max-pack-size
option when a single first object already busted the given limit and
placed many objects in a single pack.
* "git-p4" fast import frontend was too eager to trigger its keyword expansion
logic, even on a keyword-looking string that does not have closing '$' on the
same line.
* "git push $there" when the remote $there is defined in $GIT_DIR/branches/$there
behaves more like what cg-push from Cogito used to work.
* when giving up resolving a conflicted merge, "git reset --hard" failed
to remove new paths from the working tree.
* "git tag" did not complain when given mutually incompatible set of options.
* The message constructed in the internal editor was discarded when "git
tag -s" failed to sign the message, which was often caused by the user
not configuring GPG correctly.
* "make check" cannot be run without sparse; people may have meant to say
"make test" instead, so suggest that.
* Internal diff machinery had a corner case performance bug that choked on
a large file with many repeated contents.
* "git repack" used to grab objects out of packs marked with .keep
into a new pack.
* Many unsafe call to sprintf() style varargs functions are corrected.
* Also contains quite a few documentation updates.

33
Documentation/RelNotes-1.6.0.6.txt Normal file
View File

@@ -0,0 +1,33 @@
GIT v1.6.0.6 Release Notes
==========================
Fixes since 1.6.0.5
-------------------
* "git fsck" had a deep recursion that wasted stack space.
* "git fast-export" and "git fast-import" choked on an old style
annotated tag that lack the tagger information.
* "git mergetool -- file" did not correctly skip "--" marker that
signals the end of options list.
* "git show $tag" segfaulted when an annotated $tag pointed at a
nonexistent object.
* "git show 2>error" when the standard output is automatically redirected
to the pager redirected the standard error to the pager as well; there
was no need to.
* "git send-email" did not correctly handle list of addresses when
they had quoted comma (e.g. "Lastname, Givenname" <mail@addre.ss>).
* Logic to discover branch ancestry in "git svn" was unreliable when
the process to fetch history was interrupted.
* Removed support for an obsolete gitweb request URI, whose
implementation ran "git diff" Porcelain, instead of using plumbing,
which would have run an external diff command specified in the
repository configuration as the gitweb user.
Also contains numerous documentation typofixes.

282
Documentation/RelNotes-1.6.1.txt Normal file
View File

@@ -0,0 +1,282 @@
GIT v1.6.1 Release Notes
========================
Updates since v1.6.0
--------------------
When some commands (e.g. "git log", "git diff") spawn pager internally, we
used to make the pager the parent process of the git command that produces
output. This meant that the exit status of the whole thing comes from the
pager, not the underlying git command. We swapped the order of the
processes around and you will see the exit code from the command from now
on.
(subsystems)
* gitk can call out to git-gui to view "git blame" output; git-gui in turn
can run gitk from its blame view.
* Various git-gui updates including updated translations.
* Various gitweb updates from repo.or.cz installation.
* Updates to emacs bindings.
(portability)
* A few test scripts used nonportable "grep" that did not work well on
some platforms, e.g. Solaris.
* Sample pre-auto-gc script has OS X support.
* Makefile has support for (ancient) FreeBSD 4.9.
(performance)
* Many operations that are lstat(3) heavy can be told to pre-execute
necessary lstat(3) in parallel before their main operations, which
potentially gives much improved performance for cold-cache cases or in
environments with weak metadata caching (e.g. NFS).
* The underlying diff machinery to produce textual output has been
optimized, which would result in faster "git blame" processing.
* Most of the test scripts (but not the ones that try to run servers)
can be run in parallel.
* Bash completion of refnames in a repository with massive number of
refs has been optimized.
* Cygwin port uses native stat/lstat implementations when applicable,
which leads to improved performance.
* "git push" pays attention to alternate repositories to avoid sending
unnecessary objects.
* "git svn" can rebuild an out-of-date rev_map file.
(usability, bells and whistles)
* When you mistype a command name, git helpfully suggests what it guesses
you might have meant to say. help.autocorrect configuration can be set
to a non-zero value to accept the suggestion when git can uniquely
guess.
* The packfile machinery hopefully is more robust when dealing with
corrupt packs if redundant objects involved in the corruption are
available elsewhere.
* "git add -N path..." adds the named paths as an empty blob, so that
subsequent "git diff" will show a diff as if they are creation events.
* "git add" gained a built-in synonym for people who want to say "stage
changes" instead of "add contents to the staging area" which amounts
to the same thing.
* "git apply" learned --include=paths option, similar to the existing
--exclude=paths option.
* "git bisect" is careful about a user mistake and suggests testing of
merge base first when good is not a strict ancestor of bad.
* "git bisect skip" can take a range of commits.
* "git blame" re-encodes the commit metainfo to UTF-8 from i18n.commitEncoding
by default.
* "git check-attr --stdin" can check attributes for multiple paths.
* "git checkout --track origin/hack" used to be a syntax error. It now
DWIMs to create a corresponding local branch "hack", i.e. acts as if you
said "git checkout --track -b hack origin/hack".
* "git checkout --ours/--theirs" can be used to check out one side of a
conflicting merge during conflict resolution.
* "git checkout -m" can be used to recreate the initial conflicted state
during conflict resolution.
* "git cherry-pick" can also utilize rerere for conflict resolution.
* "git clone" learned to be verbose with -v
* "git commit --author=$name" can look up author name from existing
commits.
* output from "git commit" has been reworded in a more concise and yet
more informative way.
* "git count-objects" reports the on-disk footprint for packfiles and
their corresponding idx files.
* "git daemon" learned --max-connections=<count> option.
* "git daemon" exports REMOTE_ADDR to record client address, so that
spawned programs can act differently on it.
* "git describe --tags" favours closer lightweight tags than farther
annotated tags now.
* "git diff" learned to mimic --suppress-blank-empty from GNU diff via a
configuration option.
* "git diff" learned to put more sensible hunk headers for Python,
HTML and ObjC contents.
* "git diff" learned to vary the a/ vs b/ prefix depending on what are
being compared, controlled by diff.mnemonicprefix configuration.
* "git diff" learned --dirstat-by-file to count changed files, not number
of lines, when summarizing the global picture.
* "git diff" learned "textconv" filters --- a binary or hard-to-read
contents can be munged into human readable form and the difference
between the results of the conversion can be viewed (obviously this
cannot produce a patch that can be applied, so this is disabled in
format-patch among other things).
* "--cached" option to "git diff has an easier to remember synonym "--staged",
to ask "what is the difference between the given commit and the
contents staged in the index?"
* "git for-each-ref" learned "refname:short" token that gives an
unambiguously abbreviated refname.
* Auto-numbering of the subject lines is the default for "git
format-patch" now.
* "git grep" learned to accept -z similar to GNU grep.
* "git help" learned to use GIT_MAN_VIEWER environment variable before
using "man" program.
* "git imap-send" can optionally talk SSL.
* "git index-pack" is more careful against disk corruption while
completing a thin pack.
* "git log --check" and "git log --exit-code" passes their underlying diff
status with their exit status code.
* "git log" learned --simplify-merges, a milder variant of --full-history;
"gitk --simplify-merges" is easier to view than with --full-history.
* "git log" learned "--source" to show what ref each commit was reached
from.
* "git log" also learned "--simplify-by-decoration" to show the
birds-eye-view of the topology of the history.
* "git log --pretty=format:" learned "%d" format element that inserts
names of tags that point at the commit.
* "git merge --squash" and "git merge --no-ff" into an unborn branch are
noticed as user errors.
* "git merge -s $strategy" can use a custom built strategy if you have a
command "git-merge-$strategy" on your $PATH.
* "git pull" (and "git fetch") can be told to operate "-v"erbosely or
"-q"uietly.
* "git push" can be told to reject deletion of refs with receive.denyDeletes
configuration.
* "git rebase" honours pre-rebase hook; use --no-verify to bypass it.
* "git rebase -p" uses interactive rebase machinery now to preserve the merges.
* "git reflog expire branch" can be used in place of "git reflog expire
refs/heads/branch".
* "git remote show $remote" lists remote branches one-per-line now.
* "git send-email" can be given revision range instead of files and
maildirs on the command line, and automatically runs format-patch to
generate patches for the given revision range.
* "git submodule foreach" subcommand allows you to iterate over checked
out submodules.
* "git submodule sync" subcommands allows you to update the origin URL
recorded in submodule directories from the toplevel .gitmodules file.
* "git svn branch" can create new branches on the other end.
* "gitweb" can use more saner PATH_INFO based URL.
(internal)
* "git hash-object" learned to lie about the path being hashed, so that
correct gitattributes processing can be done while hashing contents
stored in a temporary file.
* various callers of git-merge-recursive avoid forking it as an external
process.
* Git class defined in "Git.pm" can be subclasses a bit more easily.
* We used to link GNU regex library as a compatibility layer for some
platforms, but it turns out it is not necessary on most of them.
* Some path handling routines used fixed number of buffers used alternately
but depending on the call depth, this arrangement led to hard to track
bugs. This issue is being addressed.
Fixes since v1.6.0
------------------
All of the fixes in v1.6.0.X maintenance series are included in this
release, unless otherwise noted.
* Porcelains implemented as shell scripts were utterly confused when you
entered to a subdirectory of a work tree from sideways, following a
symbolic link (this may need to be backported to older releases later).
* Tracking symbolic links would work better on filesystems whose lstat()
returns incorrect st_size value for them.
* "git add" and "git update-index" incorrectly allowed adding S/F when S
is a tracked symlink that points at a directory D that has a path F in
it (we still need to fix a similar nonsense when S is a submodule and F
is a path in it).
* "git am" after stopping at a broken patch lost --whitespace, -C, -p and
--3way options given from the command line initially.
* "git diff --stdin" used to take two trees on a line and compared them,
but we dropped support for such a use case long time ago. This has
been resurrected.
* "git filter-branch" failed to rewrite a tag name with slashes in it.
* "git http-push" did not understand URI scheme other than opaquelocktoken
when acquiring a lock from the server (this may need to be backported to
older releases later).
* "git revert" records relative to which parent a revert was made when
reverting a merge. Together with new documentation that explains issues
around reverting a merge and merging from the updated branch later, this
hopefully will reduce user confusion (this may need to be backported to
older releases later).
* "git rm --cached" used to allow an empty blob that was added earlier to
be removed without --force, even when the file in the work tree has
since been modified.
* "git push --tags --all $there" failed with generic usage message without
telling saying these two options are incompatible.
* "git log --author/--committer" match used to potentially match the
timestamp part, exposing internal implementation detail. Also these did
not work with --fixed-strings match at all.
* "gitweb" did not mark non-ASCII characters imported from external HTML fragments
correctly.
--
exec >/var/tmp/1
O=v1.6.1-rc3-74-gf66bc5f
echo O=$(git describe master)
git shortlog --no-merges $O..master ^maint

32
Documentation/SubmittingPatches
View File

@@ -71,7 +71,7 @@ run git diff --check on your changes before you commit.
(1a) Try to be nice to older C compilers
We try to support wide range of C compilers to compile
We try to support a wide range of C compilers to compile
git with. That means that you should not use C99 initializers, even
if a lot of compilers grok it.
@@ -222,6 +222,9 @@ D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
the change to its true author (see (2) above).
Also notice that a real name is used in the Signed-off-by: line. Please
don't hide your real name.
Some people also put extra tags at the end.
"Acked-by:" says that the patch was reviewed by the person who
@@ -456,3 +459,30 @@ This should help you to submit patches inline using KMail.
5) Back in the compose window: add whatever other text you wish to the
message, complete the addressing and subject fields, and press send.
Gmail
-----
Submitting properly formatted patches via Gmail is simple now that
IMAP support is available. First, edit your ~/.gitconfig to specify your
account settings:
[imap]
folder = "[Gmail]/Drafts"
host = imaps://imap.gmail.com
user = user@gmail.com
pass = p4ssw0rd
port = 993
sslverify = false
Next, ensure that your Gmail settings are correct. In "Settings" the
"Use Unicode (UTF-8) encoding for outgoing messages" should be checked.
Once your commits are ready to send to the mailing list, run the following
command to send the patch emails to your Gmail Drafts folder.
$ git format-patch -M --stdout origin/master | git imap-send
Go to your Gmail account, open the Drafts folder, find the patch email, fill
in the To: and CC: fields and send away!

23
Documentation/asciidoc.conf
View File

@@ -7,6 +7,9 @@
# Show GIT link as: <command>(<section>); if section is defined, else just show
# the command.
[macros]
(?su)[\\]?(?P<name>linkgit):(?P<target>\S*?)\[(?P<attrlist>.*?)\]=
[attributes]
asterisk=&#42;
plus=&#43;
@@ -40,6 +43,26 @@ endif::doctype-manpage[]
</literallayout>
{title#}</example>
endif::docbook-xsl-172[]
ifdef::docbook-xsl-172[]
ifdef::doctype-manpage[]
# The following two small workarounds insert a simple paragraph after screen
[listingblock]
<example><title>{title}</title>
<screen>
|
</screen><simpara></simpara>
{title#}</example>
[verseblock]
<formalpara{id? id="{id}"}><title>{title}</title><para>
{title%}<literallayout{id? id="{id}"}>
{title#}<literallayout>
|
</literallayout><simpara></simpara>
{title#}</para></formalpara>
endif::doctype-manpage[]
endif::docbook-xsl-172[]
endif::backend-docbook[]
ifdef::doctype-manpage[]

7
Documentation/blame-options.txt
View File

@@ -49,6 +49,13 @@ of lines before or after the line given by <start>.
Show the result incrementally in a format designed for
machine consumption.
--encoding=<encoding>::
Specifies the encoding used to output author names
and commit summaries. Setting it to `none` makes blame
output unconverted data. For more information see the
discussion about encoding in the linkgit:git-log[1]
manual page.
--contents <file>::
When <rev> is not specified, the command annotates the
changes starting backwards from the working tree copy.

255
Documentation/config.txt
View File

@@ -117,6 +117,17 @@ core.fileMode::
the working copy are ignored; useful on broken filesystems like FAT.
See linkgit:git-update-index[1]. True by default.
core.ignoreCygwinFSTricks::
This option is only used by Cygwin implementation of Git. If false,
the Cygwin stat() and lstat() functions are used. This may be useful
if your repository consists of a few separate directories joined in
one hierarchy using Cygwin mount. If true, Git uses native Win32 API
whenever it is possible and falls back to Cygwin functions only to
handle symbol links. The native mode is more than twice faster than
normal Cygwin l/stat() functions. True by default, unless core.filemode
is true, in which case ignoreCygwinFSTricks is ignored as Cygwin's
POSIX emulation is required to support core.filemode.
core.trustctime::
If false, the ctime differences between the index and the
working copy are ignored; useful when the inode change time
@@ -363,8 +374,17 @@ core.pager::
variable. Note that git sets the `LESS` environment
variable to `FRSX` if it is unset when it runs the
pager. One can change these settings by setting the
`LESS` variable to some other value or by giving the
`core.pager` option a value such as "`less -+FRSX`".
`LESS` variable to some other value. Alternately,
these settings can be overridden on a project or
global basis by setting the `core.pager` option.
Setting `core.pager` has no affect on the `LESS`
environment variable behaviour above, so if you want
to override git's default settings this way, you need
to be explicit. For example, to disable the S option
in a backward compatible manner, set `core.pager`
to "`less -+$LESS -FRX`". This will be passed to the
shell by git, which will translate the final command to
"`LESS=FRSX less -+FRSX -FRX`".
core.whitespace::
A comma separated list of common whitespace problems to
@@ -393,6 +413,15 @@ data writes properly, but can be useful for filesystems that do not use
journalling (traditional UNIX filesystems) or that only journal metadata
and not file contents (OS X's HFS+, or Linux ext3 with "data=writeback").
core.preloadindex::
Enable parallel index preload for operations like 'git diff'
+
This can speed up operations like 'git diff' and 'git status' especially
on filesystems like NFS that have weak caching semantics and thus
relatively high IO latencies. With this set to 'true', git will do the
index comparison to the filesystem data in parallel, allowing
overlapping IO's.
alias.*::
Command aliases for the linkgit:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
@@ -552,9 +581,6 @@ color.status.<slot>::
to red). The values of these variables may be specified as in
color.branch.<slot>.
commit.template::
Specify a file to use as the template for new commit messages.
color.ui::
When set to `always`, always use colors in all git commands which
are capable of colored output. When false (or `never`), never. When
@@ -562,6 +588,9 @@ color.ui::
terminal. When more specific variables of color.* are set, they always
take precedence over this setting. Defaults to false.
commit.template::
Specify a file to use as the template for new commit messages.
diff.autorefreshindex::
When using 'git-diff' to compare with work tree
files, do not consider stat-only change as changed.
@@ -581,6 +610,22 @@ diff.external::
you want to use an external diff program only on a subset of
your files, you might want to use linkgit:gitattributes[5] instead.
diff.mnemonicprefix::
If set, 'git-diff' uses a prefix pair that is different from the
standard "a/" and "b/" depending on what is being compared. When
this configuration is in effect, reverse diff output also swaps
the order of the prefixes:
'git-diff';;
compares the (i)ndex and the (w)ork tree;
'git-diff HEAD';;
compares a (c)ommit and the (w)ork tree;
'git diff --cached';;
compares a (c)ommit and the (i)ndex;
'git-diff HEAD:file1 file2';;
compares an (o)bject and a (w)ork tree entity;
'git diff --no-index a b';;
compares two non-git things (1) and (2).
diff.renameLimit::
The number of files to consider when performing the copy/rename
detection; equivalent to the 'git-diff' option '-l'.
@@ -590,6 +635,10 @@ diff.renames::
will enable basic rename detection. If set to "copies" or
"copy", it will detect copies, as well.
diff.suppress-blank-empty::
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
fetch.unpackLimit::
If the number of objects fetched over the git native
transfer is below this
@@ -602,10 +651,11 @@ fetch.unpackLimit::
`transfer.unpackLimit` is used instead.
format.numbered::
A boolean which can enable sequence numbers in patch subjects.
Setting this option to "auto" will enable it only if there is
more than one patch. See --numbered option in
linkgit:git-format-patch[1].
A boolean which can enable or disable sequence numbers in patch
subjects. It defaults to "auto" which enables it only if there
is more than one patch. It can be enabled or disabled for all
messages by setting it to "true" or "false". See --numbered
option in linkgit:git-format-patch[1].
format.headers::
Additional email headers to include in a patch to be submitted
@@ -673,18 +723,6 @@ gc.rerereunresolved::
kept for this many days when 'git-rerere gc' is run.
The default is 15 days. See linkgit:git-rerere[1].
rerere.autoupdate::
When set to true, `git-rerere` updates the index with the
resulting contents after it cleanly resolves conflicts using
previously recorded resolution. Defaults to false.
rerere.enabled::
Activate recording of resolved conflicts, so that identical
conflict hunks can be resolved automatically, should they
be encountered again. linkgit:git-rerere[1] command is by
default enabled if you create `rr-cache` directory under
`$GIT_DIR`, but can be disabled by setting this option to false.
gitcvs.enabled::
Whether the CVS server interface is enabled for this repository.
See linkgit:git-cvsserver[1].
@@ -755,6 +793,14 @@ gui.diffcontext::
Specifies how many context lines should be used in calls to diff
made by the linkgit:git-gui[1]. The default is "5".
gui.encoding::
Specifies the default encoding to use for displaying of
file contents in linkgit:git-gui[1] and linkgit:gitk[1].
It can be overridden by setting the 'encoding' attribute
for relevant files (see linkgit:gitattributes[5]).
If this option is not set, the tools default to the
locale encoding.
gui.matchtrackingbranch::
Determines if new branches created with linkgit:git-gui[1] should
default to tracking remote branches with matching names or
@@ -777,6 +823,73 @@ gui.spellingdictionary::
the linkgit:git-gui[1]. When set to "none" spell checking is turned
off.
gui.fastcopyblame::
If true, 'git gui blame' uses '-C' instead of '-C -C' for original
location detection. It makes blame significantly faster on huge
repositories at the expense of less thorough copy detection.
gui.copyblamethreshold::
Specifies the threshold to use in 'git gui blame' original location
detection, measured in alphanumeric characters. See the
linkgit:git-blame[1] manual for more information on copy detection.
gui.blamehistoryctx::
Specifies the radius of history context in days to show in
linkgit:gitk[1] for the selected commit, when the `Show History
Context` menu item is invoked from 'git gui blame'. If this
variable is set to zero, the whole history is shown.
guitool.<name>.cmd::
Specifies the shell command line to execute when the corresponding item
of the linkgit:git-gui[1] `Tools` menu is invoked. This option is
mandatory for every tool. The command is executed from the root of
the working directory, and in the environment it receives the name of
the tool as 'GIT_GUITOOL', the name of the currently selected file as
'FILENAME', and the name of the current branch as 'CUR_BRANCH' (if
the head is detached, 'CUR_BRANCH' is empty).
guitool.<name>.needsfile::
Run the tool only if a diff is selected in the GUI. It guarantees
that 'FILENAME' is not empty.
guitool.<name>.noconsole::
Run the command silently, without creating a window to display its
output.
guitool.<name>.norescan::
Don't rescan the working directory for changes after the tool
finishes execution.
guitool.<name>.confirm::
Show a confirmation dialog before actually running the tool.
guitool.<name>.argprompt::
Request a string argument from the user, and pass it to the tool
through the 'ARGS' environment variable. Since requesting an
argument implies confirmation, the 'confirm' option has no effect
if this is enabled. If the option is set to 'true', 'yes', or '1',
the dialog uses a built-in generic prompt; otherwise the exact
value of the variable is used.
guitool.<name>.revprompt::
Request a single valid revision from the user, and set the
'REVISION' environment variable. In other aspects this option
is similar to 'argprompt', and can be used together with it.
guitool.<name>.revunmerged::
Show only unmerged branches in the 'revprompt' subdialog.
This is useful for tools similar to merge or rebase, but not
for things like checkout or reset.
guitool.<name>.title::
Specifies the title to use for the prompt dialog. The default
is the tool name.
guitool.<name>.prompt::
Specifies the general prompt string to display at the top of
the dialog, before subsections for 'argprompt' and 'revprompt'.
The default value includes the actual command.
help.browser::
Specify the browser that will be used to display help in the
'web' format. See linkgit:git-help[1].
@@ -786,6 +899,15 @@ help.format::
Values 'man', 'info', 'web' and 'html' are supported. 'man' is
the default. 'web' and 'html' are the same.
help.autocorrect::
Automatically correct and execute mistyped commands after
waiting for the given number of deciseconds (0.1 sec). If more
than one command can be deduced from the entered text, nothing
will be executed. If the value of this option is negative,
the corrected command will be executed immediately. If the
value is 0 - the command will be just shown but not executed.
This is the default.
http.proxy::
Override the HTTP proxy, normally configured using the 'http_proxy'
environment variable (see linkgit:curl[1]). This can be overridden
@@ -843,6 +965,10 @@ i18n.logOutputEncoding::
Character encoding the commit messages are converted to when
running 'git-log' and friends.
imap::
The configuration variables in the 'imap' section are described
in linkgit:git-imap-send[1].
instaweb.browser::
Specify the program that will be used to browse your working
repository in gitweb. See linkgit:git-instaweb[1].
@@ -878,8 +1004,6 @@ man.viewer::
Specify the programs that may be used to display help in the
'man' format. See linkgit:git-help[1].
include::merge-config.txt[]
man.<tool>.cmd::
Specify the command to invoke the specified man viewer. The
specified command is evaluated in shell with the man page
@@ -889,6 +1013,8 @@ man.<tool>.path::
Override the path for the given tool that may be used to
display help in the 'man' format. See linkgit:git-help[1].
include::merge-config.txt[]
mergetool.<tool>.path::
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
@@ -997,6 +1123,41 @@ pull.octopus::
pull.twohead::
The default merge strategy to use when pulling a single branch.
receive.fsckObjects::
If it is set to true, git-receive-pack will check all received
objects. It will abort in the case of a malformed object or a
broken link. The result of an abort are only dangling objects.
Defaults to false.
receive.unpackLimit::
If the number of objects received in a push is below this
limit then the objects will be unpacked into loose object
files. However if the number of received objects equals or
exceeds this limit then the received pack will be stored as
a pack, after adding any missing delta bases. Storing the
pack from a push can make the push operation complete faster,
especially on slow filesystems. If not set, the value of
`transfer.unpackLimit` is used instead.
receive.denyDeletes::
If set to true, git-receive-pack will deny a ref update that deletes
the ref. Use this to prevent such a ref deletion via a push.
receive.denyCurrentBranch::
If set to true or "refuse", receive-pack will deny a ref update
to the currently checked out branch of a non-bare repository.
Such a push is potentially dangerous because it brings the HEAD
out of sync with the index and working tree. If set to "warn",
print a warning of such a push to stderr, but allow the push to
proceed. If set to false or "ignore", allow such pushes with no
message. Defaults to "warn".
receive.denyNonFastForwards::
If set to true, git-receive-pack will deny a ref update which is
not a fast forward. Use this to prevent such an update via a push,
even if that push is forced. This configuration variable is
set when initializing a shared repository.
remote.<name>.url::
The URL of a remote repository. See linkgit:git-fetch[1] or
linkgit:git-push[1].
@@ -1046,6 +1207,18 @@ repack.usedeltabaseoffset::
"false" and repack. Access from old git versions over the
native protocol are unaffected by this option.
rerere.autoupdate::
When set to true, `git-rerere` updates the index with the
resulting contents after it cleanly resolves conflicts using
previously recorded resolution. Defaults to false.
rerere.enabled::
Activate recording of resolved conflicts, so that identical
conflict hunks can be resolved automatically, should they
be encountered again. linkgit:git-rerere[1] command is by
default enabled if you create `rr-cache` directory under
`$GIT_DIR`, but can be disabled by setting this option to false.
showbranch.default::
The default set of branches for linkgit:git-show-branch[1].
See linkgit:git-show-branch[1].
@@ -1082,6 +1255,11 @@ tar.umask::
archiving user's umask will be used instead. See umask(2) and
linkgit:git-archive[1].
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.
The default value is 100.
url.<base>.insteadOf::
Any URL that starts with this value will be rewritten to
start, instead, with <base>. In cases where some site serves a
@@ -1110,37 +1288,6 @@ user.signingkey::
unchanged to gpg's --local-user parameter, so you may specify a key
using any method that gpg supports.
imap::
The configuration variables in the 'imap' section are described
in linkgit:git-imap-send[1].
receive.fsckObjects::
If it is set to true, git-receive-pack will check all received
objects. It will abort in the case of a malformed object or a
broken link. The result of an abort are only dangling objects.
Defaults to false.
receive.unpackLimit::
If the number of objects received in a push is below this
limit then the objects will be unpacked into loose object
files. However if the number of received objects equals or
exceeds this limit then the received pack will be stored as
a pack, after adding any missing delta bases. Storing the
pack from a push can make the push operation complete faster,
especially on slow filesystems. If not set, the value of
`transfer.unpackLimit` is used instead.
receive.denyNonFastForwards::
If set to true, git-receive-pack will deny a ref update which is
not a fast forward. Use this to prevent such an update via a push,
even if that push is forced. This configuration variable is
set when initializing a shared repository.
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.
The default value is 100.
web.browser::
Specify a web browser that may be used by some commands.
Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]

16
Documentation/diff-format.txt
View File

@@ -46,6 +46,22 @@ That is, from the left to the right:
. path for "dst"; only exists for C or R.
. an LF or a NUL when '-z' option is used, to terminate the record.
Possible status letters are:
- A: addition of a file
- C: copy of a file into a new one
- D: deletion of a file
- M: modification of the contents or mode of a file
- R: renaming of a file
- T: change in the type of the file
- U: file is unmerged (you must complete the merge before it can
be committed)
- X: "unknown" change type (most probably a bug, please report it)
Status letters C and R are always followed by a score (denoting the
percentage of similarity between the source and target of the move or
copy), and are the only ones to be so.
<sha1> is shown as all 0's if a file is new on the filesystem
and it is out of sync with the index.

6
Documentation/diff-generate-patch.txt
View File

@@ -143,15 +143,15 @@ different from it.
A `-` character in the column N means that the line appears in
fileN but it does not appear in the result. A `+` character
in the column N means that the line appears in the last file,
in the column N means that the line appears in the result,
and fileN does not have that line (in other words, the line was
added, from the point of view of that parent).
In the above example output, the function signature was changed
from both files (hence two `-` removals from both file1 and
file2, plus `++` to mean one line that was added does not appear
in either file1 nor file2). Also two other lines are the same
from file1 but do not appear in file2 (hence prefixed with ` +`).
in either file1 nor file2). Also eight other lines are the same
from file1 but do not appear in file2 (hence prefixed with `{plus}`).
When shown by `git diff-tree -c`, it compares the parents of a
merge commit with the merge result (i.e. file1..fileN are the

12
Documentation/diff-options.txt
View File

@@ -65,6 +65,9 @@ endif::git-format-patch[]
can be set with "--dirstat=limit". Changes in a child directory is not
counted for the parent directory, unless "--cumulative" is used.
--dirstat-by-file[=limit]::
Same as --dirstat, but counts changed files instead of lines.
--summary::
Output a condensed summary of extended header information
such as creations, renames and mode changes.
@@ -106,9 +109,9 @@ endif::git-format-patch[]
--exit-code.
--full-index::
Instead of the first handful characters, show full
object name of pre- and post-image blob on the "index"
line when generating a patch format output.
Instead of the first handful of characters, show the full
pre- and post-image blob object names on the "index"
line when generating patch format output.
--binary::
In addition to --full-index, output "binary diff" that
@@ -134,7 +137,8 @@ endif::git-format-patch[]
--diff-filter=[ACDMRTUXB*]::
Select only files that are Added (`A`), Copied (`C`),
Deleted (`D`), Modified (`M`), Renamed (`R`), have their
type (mode) changed (`T`), are Unmerged (`U`), are
type (i.e. regular file, symlink, submodule, ...) changed (`T`),
are Unmerged (`U`), are
Unknown (`X`), or have had their pairing Broken (`B`).
Any combination of the filter characters may be used.
When `*` (All-or-none) is added to the combination, all

13
Documentation/git-add.txt
View File

@@ -9,8 +9,8 @@ SYNOPSIS
--------
[verse]
'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
[--all | [--update | -u]] [--refresh] [--ignore-errors] [--]
<filepattern>...
[--all | [--update | -u]] [--intent-to-add | -N]
[--refresh] [--ignore-errors] [--] <filepattern>...
DESCRIPTION
-----------
@@ -92,6 +92,15 @@ OPTIONS
and add all untracked files that are not ignored by '.gitignore'
mechanism.
-N::
--intent-to-add::
Record only the fact that the path will be added later. An entry
for the path is placed in the index with no content. This is
useful for, among other things, showing the unstaged content of
such files with 'git diff' and committing them with 'git commit
-a'.
--refresh::
Don't add the file(s), but only refresh their stat()
information in the index.

14
Documentation/git-apply.txt
View File

@@ -14,7 +14,8 @@ SYNOPSIS
[--allow-binary-replacement | --binary] [--reject] [-z]
[-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached]
[--whitespace=<nowarn|warn|fix|error|error-all>]
[--exclude=PATH] [--directory=<root>] [--verbose] [<patch>...]
[--exclude=PATH] [--include=PATH] [--directory=<root>]
[--verbose] [<patch>...]
DESCRIPTION
-----------
@@ -137,6 +138,17 @@ discouraged.
be useful when importing patchsets, where you want to exclude certain
files or directories.
--include=<path-pattern>::
Apply changes to files matching the given path pattern. This can
be useful when importing patchsets, where you want to include certain
files or directories.
+
When --exclude and --include patterns are used, they are examined in the
order they appear on the command line, and the first match determines if a
patch to each path is used. A patch to a path that does not match any
include/exclude pattern is used by default if there is no include pattern
on the command line, and ignored if there is any include pattern.
--whitespace=<action>::
When applying a patch, detect a new or modified line that has
whitespace errors. What are considered whitespace errors is

27
Documentation/git-bisect.txt
View File

@@ -19,14 +19,14 @@ on the subcommand:
git bisect start [<bad> [<good>...]] [--] [<paths>...]
git bisect bad [<rev>]
git bisect good [<rev>...]
git bisect skip [<rev>...]
git bisect skip [(<rev>|<range>)...]
git bisect reset [<branch>]
git bisect visualize
git bisect replay <logfile>
git bisect log
git bisect run <cmd>...
This command uses 'git-rev-list --bisect' to help drive the
This command uses 'git rev-list --bisect' to help drive the
binary search process to find which change introduced a bug, given an
old "good" commit object name and a later "bad" commit object name.
@@ -101,7 +101,7 @@ $ git bisect visualize
to see the currently remaining suspects in 'gitk'. `visualize` is a bit
too long to type and `view` is provided as a synonym.
If 'DISPLAY' environment variable is not set, 'git-log' is used
If 'DISPLAY' environment variable is not set, 'git log' is used
instead. You can even give command line options such as `-p` and
`--stat`.
@@ -164,6 +164,25 @@ But computing the commit to test may be slower afterwards and git may
eventually not be able to tell the first bad among a bad and one or
more "skip"ped commits.
You can even skip a range of commits, instead of just one commit,
using the "'<commit1>'..'<commit2>'" notation. For example:
------------
$ git bisect skip v2.5..v2.6
------------
would mean that no commit between `v2.5` excluded and `v2.6` included
can be tested.
Note that if you want to also skip the first commit of a range you can
use something like:
------------
$ git bisect skip v2.5 v2.5..v2.6
------------
and the commit pointed to by `v2.5` will be skipped too.
Cutting down bisection by giving more parameters to bisect start
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -215,7 +234,7 @@ tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
work around other problem this bisection is not interested in")
applied to the revision being tested.
To cope with such a situation, after the inner 'git-bisect' finds the
To cope with such a situation, after the inner 'git bisect' finds the
next revision to test, with the "run" script, you can apply that tweak
before compiling, run the real test, and after the test decides if the
revision (possibly with the needed tweaks) passed the test, rewind the

61
Documentation/git-check-attr.txt
View File

@@ -3,12 +3,14 @@ git-check-attr(1)
NAME
----
git-check-attr - Display gitattributes information.
git-check-attr - Display gitattributes information
SYNOPSIS
--------
[verse]
'git check-attr' attr... [--] pathname...
'git check-attr' --stdin [-z] attr... < <list-of-paths>
DESCRIPTION
-----------
@@ -17,11 +19,68 @@ For every pathname, this command will list if each attr is 'unspecified',
OPTIONS
-------
--stdin::
Read file names from stdin instead of from the command-line.
-z::
Only meaningful with `--stdin`; paths are separated with
NUL character instead of LF.
\--::
Interpret all preceding arguments as attributes, and all following
arguments as path names. If not supplied, only the first argument will
be treated as an attribute.
OUTPUT
------
The output is of the form:
<path> COLON SP <attribute> COLON SP <info> LF
Where <path> is the path of a file being queried, <attribute> is an attribute
being queried and <info> can be either:
'unspecified';; when the attribute is not defined for the path.
'unset';; when the attribute is defined to false.
'set';; when the attribute is defined to true.
<value>;; when a value has been assigned to the attribute.
EXAMPLES
--------
In the examples, the following '.gitattributes' file is used:
---------------
*.java diff=java -crlf myAttr
NoMyAttr.java !myAttr
README caveat=unspecified
---------------
* Listing a single attribute:
---------------
$ git check-attr diff org/example/MyClass.java
org/example/MyClass.java: diff: java
---------------
* Listing multiple attributes for a file:
---------------
$ git check-attr crlf diff myAttr -- org/example/MyClass.java
org/example/MyClass.java: crlf: unset
org/example/MyClass.java: diff: java
org/example/MyClass.java: myAttr: set
---------------
* Listing attribute for multiple files:
---------------
$ git check-attr myAttr -- org/example/MyClass.java org/example/NoMyAttr.java
org/example/MyClass.java: myAttr: set
org/example/NoMyAttr.java: myAttr: unspecified
---------------
* Not all values are equally unambiguous:
---------------
$ git check-attr caveat README
README: caveat: unspecified
---------------
SEE ALSO
--------

59
Documentation/git-checkout.txt
View File

@@ -8,8 +8,8 @@ git-checkout - Checkout a branch or paths to the working tree
SYNOPSIS
--------
[verse]
'git checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
'git checkout' [<tree-ish>] [--] <paths>...
'git checkout' [-q] [-f] [--track | --no-track] [-b <new_branch> [-l]] [-m] [<branch>]
'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
DESCRIPTION
-----------
@@ -21,16 +21,26 @@ specified, <new_branch>. Using -b will cause <new_branch> to
be created; in this case you can use the --track or --no-track
options, which will be passed to `git branch`.
As a convenience, --track will default to create a branch whose
name is constructed from the specified branch name by stripping
the first namespace level.
When <paths> are given, this command does *not* switch
branches. It updates the named paths in the working tree from
the index file (i.e. it runs `git checkout-index -f -u`), or
from a named commit. In
this case, the `-f` and `-b` options are meaningless and giving
the index file, or from a named <tree-ish> (most often a commit). In
this case, the `-b` options is meaningless and giving
either of them results in an error. <tree-ish> argument can be
used to specify a specific tree-ish (i.e. commit, tag or tree)
to update the index for the given paths before updating the
working tree.
The index may contain unmerged entries after a failed merge. By
default, if you try to check out such an entry from the index, the
checkout operation will fail and nothing will be checked out.
Using -f will ignore these unmerged entries. The contents from a
specific side of the merge can be checked out of the index by
using --ours or --theirs. With -m, changes made to the working tree
file can be discarded to recreate the original conflicted merge result.
OPTIONS
-------
@@ -38,8 +48,17 @@ OPTIONS
Quiet, suppress feedback messages.
-f::
Proceed even if the index or the working tree differs
from HEAD. This is used to throw away local changes.
When switching branches, proceed even if the index or the
working tree differs from HEAD. This is used to throw away
local changes.
+
When checking out paths from the index, do not fail upon unmerged
entries; instead, unmerged entries are ignored.
--ours::
--theirs::
When checking out paths from the index, check out stage #2
('ours') or #3 ('theirs') for unmerged paths.
-b::
Create a new branch named <new_branch> and start it at
@@ -59,6 +78,17 @@ OPTIONS
'git-checkout' and 'git-branch' to always behave as if '--no-track' were
given. Set it to `always` if you want this behavior when the
start-point is either a local or remote branch.
+
If no '-b' option was given, the name of the new branch will be
derived from the remote branch, by attempting to guess the name
of the branch on remote system. If "remotes/" or "refs/remotes/"
are prefixed, it is stripped away, and then the part up to the
next slash (which would be the nickname of the remote) is removed.
This would tell us to use "hack" as the local branch when branching
off of "origin/hack" (or "remotes/origin/hack", or even
"refs/remotes/origin/hack"). If the given name has no slash, or the above
guessing results in an empty name, the guessing is aborted. You can
explicitly give a name with '-b' in such a case.
--no-track::
Ignore the branch.autosetupmerge configuration variable.
@@ -69,7 +99,9 @@ OPTIONS
based sha1 expressions such as "<branchname>@\{yesterday}".
-m::
If you have local modifications to one or more files that
--merge::
When switching branches,
if you have local modifications to one or more files that
are different between the current branch and the branch to
which you are switching, the command refuses to switch
branches in order to preserve your modifications in context.
@@ -81,6 +113,16 @@ When a merge conflict happens, the index entries for conflicting
paths are left unmerged, and you need to resolve the conflicts
and mark the resolved paths with `git add` (or `git rm` if the merge
should result in deletion of the path).
+
When checking out paths from the index, this option lets you recreate
the conflicted merge in the specified paths.
--conflict=<style>::
The same as --merge option above, but changes the way the
conflicting hunks are presented, overriding the
merge.conflictstyle configuration variable. Possible values are
"merge" (default) and "diff3" (in addition to what is shown by
"merge" style, shows the original contents).
<new_branch>::
Name for the new branch.
@@ -190,7 +232,6 @@ the `-m` option, you would see something like this:
------------
$ git checkout -m mytopic
Auto-merging frotz
merge: warning: conflicts during merge
ERROR: Merge conflict in frotz
fatal: merge program failed
------------

13
Documentation/git-cherry-pick.txt
View File

@@ -55,13 +55,12 @@ OPTIONS
-n::
--no-commit::
Usually the command automatically creates a commit with
a commit log message stating which commit was
cherry-picked. This flag applies the change necessary
to cherry-pick the named commit to your working tree
and the index, but does not make the commit. In addition,
when this option is used, your index does not have to match
the HEAD commit. The cherry-pick is done against the
Usually the command automatically creates a commit.
This flag applies the change necessary to cherry-pick
the named commit to your working tree and the index,
but does not make the commit. In addition, when this
option is used, your index does not have to match the
HEAD commit. The cherry-pick is done against the
beginning state of your index.
+
This is useful when cherry-picking more than one commits'

5
Documentation/git-clone.txt
View File

@@ -90,6 +90,11 @@ then the cloned repository will become corrupt.
Operate quietly. This flag is also passed to the `rsync'
command when given.
--verbose::
-v::
Display the progressbar, even in case the standard output is not
a terminal.
--no-checkout::
-n::
No checkout of HEAD is performed after the clone is complete.

18
Documentation/git-commit.txt
View File

@@ -29,7 +29,8 @@ The content to be added can be specified in several ways:
3. by listing files as arguments to the 'commit' command, in which
case the commit will ignore changes staged in the index, and instead
record the current content of the listed files;
record the current content of the listed files (which must already
be known to git);
4. by using the -a switch with the 'commit' command to automatically
"add" changes from all known files (i.e. all files that are already
@@ -75,8 +76,10 @@ OPTIONS
read the message from the standard input.
--author=<author>::
Override the author name used in the commit. Use
`A U Thor <author@example.com>` format.
Override the author name used in the commit. You can use the
standard `A U Thor <author@example.com>` format. Otherwise,
an existing commit that matches the given string and its author
name is used.
-m <msg>::
--message=<msg>::
@@ -92,7 +95,8 @@ OPTIONS
-s::
--signoff::
Add Signed-off-by line at the end of the commit message.
Add Signed-off-by line by the committer at the end of the commit
log message.
-n::
--no-verify::
@@ -142,6 +146,10 @@ It is a rough equivalent for:
------
but can be used to amend a merge commit.
--
+
You should understand the implications of rewriting history if you
amend a commit that has already been published. (See the "RECOVERING
FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
-i::
--include::
@@ -158,7 +166,7 @@ but can be used to amend a merge commit.
'git-commit' if any paths are given on the command line,
in which case this option can be omitted.
If this option is specified together with '--amend', then
no paths need be specified, which can be used to amend
no paths need to be specified, which can be used to amend
the last commit without committing changes that have
already been staged.

2
Documentation/git-config.txt
View File

@@ -279,7 +279,7 @@ If you want to know all the values for a multivar, do:
% git config --get-all core.gitproxy
------------
If you like to live dangerous, you can replace *all* core.gitproxy by a
If you like to live dangerously, you can replace *all* core.gitproxy by a
new one with
------------

5
Documentation/git-count-objects.txt
View File

@@ -21,8 +21,9 @@ OPTIONS
--verbose::
In addition to the number of loose objects and disk
space consumed, it reports the number of in-pack
objects, number of packs, and number of objects that can be
removed by running `git prune-packed`.
objects, number of packs, disk space consumed by those packs,
and number of objects that can be removed by running
`git prune-packed`.
Author

22
Documentation/git-daemon.txt
View File

@@ -9,8 +9,9 @@ SYNOPSIS
--------
[verse]
'git daemon' [--verbose] [--syslog] [--export-all]
[--timeout=n] [--init-timeout=n] [--strict-paths]
[--base-path=path] [--user-path | --user-path=path]
[--timeout=n] [--init-timeout=n] [--max-connections=n]
[--strict-paths] [--base-path=path] [--base-path-relaxed]
[--user-path | --user-path=path]
[--interpolated-path=pathtemplate]
[--reuseaddr] [--detach] [--pid-file=file]
[--enable=service] [--disable=service]
@@ -99,15 +100,19 @@ OPTIONS
it takes for the server to process the sub-request and time spent
waiting for next client's request.
--max-connections::
Maximum number of concurrent clients, defaults to 32. Set it to
zero for no limit.
--syslog::
Log to syslog instead of stderr. Note that this option does not imply
--verbose, thus by default only error conditions will be logged.
--user-path::
--user-path=path::
Allow ~user notation to be used in requests. When
Allow {tilde}user notation to be used in requests. When
specified with no parameter, requests to
git://host/~alice/foo is taken as a request to access
git://host/{tilde}alice/foo is taken as a request to access
'foo' repository in the home directory of user `alice`.
If `--user-path=path` is specified, the same request is
taken as a request to access `path/foo` repository in
@@ -265,6 +270,15 @@ selectively enable/disable services per repository::
----------------------------------------------------------------
ENVIRONMENT
-----------
'git-daemon' will set REMOTE_ADDR to the IP address of the client
that connected to it, if the IP address is available. REMOTE_ADDR will
be available in the environment of hooks called when
services are performed.
Author
------
Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki

9
Documentation/git-describe.txt
View File

@@ -18,6 +18,9 @@ shown. Otherwise, it suffixes the tag name with the number of
additional commits on top of the tagged object and the
abbreviated object name of the most recent commit.
By default (without --all or --tags) `git describe` only shows
annotated tags. For more information about creating annotated tags
see the -a and -s options to linkgit:git-tag[1].
OPTIONS
-------
@@ -26,11 +29,13 @@ OPTIONS
--all::
Instead of using only the annotated tags, use any ref
found in `.git/refs/`.
found in `.git/refs/`. This option enables matching
any known branch, remote branch, or lightweight tag.
--tags::
Instead of using only the annotated tags, use any tag
found in `.git/refs/tags`.
found in `.git/refs/tags`. This option enables matching
a lightweight (non-annotated) tag.
--contains::
Instead of finding the tag that predates the commit, find

21
Documentation/git-diff-tree.txt
View File

@@ -43,19 +43,28 @@ include::diff-options.txt[]
show tree entry itself as well as subtrees. Implies -r.
--root::
When '--root' is specified the initial commit will be showed as a big
When '--root' is specified the initial commit will be shown as a big
creation event. This is equivalent to a diff against the NULL tree.
--stdin::
When '--stdin' is specified, the command does not take
<tree-ish> arguments from the command line. Instead, it
reads either one <commit> or a list of <commit>
separated with a single space from its standard input.
reads lines containing either two <tree>, one <commit>, or a
list of <commit> from its standard input. (Use a single space
as separator.)
+
When a single commit is given on one line of such input, it compares
the commit with its parents. The following flags further affects its
behavior. The remaining commits, when given, are used as if they are
When two trees are given, it compares the first tree with the second.
When a single commit is given, it compares the commit with its
parents. The remaining commits, when given, are used as if they are
parents of the first commit.
+
When comparing two trees, the ID of both trees (separated by a space
and terminated by a newline) is printed before the difference. When
comparing commits, the ID of the first (or only) commit, followed by a
newline, is printed.
+
The following flags further affect the behavior when comparing
commits (but not trees).
-m::
By default, 'git-diff-tree --stdin' does not show

1
Documentation/git-diff.txt
View File

@@ -33,6 +33,7 @@ forced by --no-index.
commit relative to the named <commit>. Typically you
would want comparison with the latest commit, so if you
do not give <commit>, it defaults to HEAD.
--staged is a synonym of --cached.
'git diff' [--options] <commit> [--] [<path>...]::

8
Documentation/git-fast-export.txt
View File

@@ -15,7 +15,7 @@ DESCRIPTION
This program dumps the given revisions in a form suitable to be piped
into 'git-fast-import'.
You can use it as a human readable bundle replacement (see
You can use it as a human-readable bundle replacement (see
linkgit:git-bundle[1]), or as a kind of an interactive
'git-filter-branch'.
@@ -65,6 +65,12 @@ If the backend uses a similar \--import-marks file, this allows for
incremental bidirectional exporting of the repository by keeping the
marks the same across runs.
--fake-missing-tagger::
Some old repositories have tags without a tagger. The
fast-import protocol was pretty strict about that, and did not
allow that. So fake a tagger to be able to fast-import the
output.
EXAMPLES
--------

4
Documentation/git-filter-branch.txt
View File

@@ -36,7 +36,9 @@ the objects and will not converge with the original branch. You will not
be able to easily push and distribute the rewritten branch on top of the
original branch. Please do not use this command if you do not know the
full implications, and avoid using it anyway, if a simple single commit
would suffice to fix your problem.
would suffice to fix your problem. (See the "RECOVERING FROM UPSTREAM
REBASE" section in linkgit:git-rebase[1] for further information about
rewriting published history.)
Always verify that the rewritten version is correct: The original refs,
if different from the rewritten ones, will be stored in the namespace

1
Documentation/git-for-each-ref.txt
View File

@@ -74,6 +74,7 @@ For all objects, the following names can be used:
refname::
The name of the ref (the part after $GIT_DIR/).
For a non-ambiguous short name of the ref append `:short`.
objecttype::
The type of the object (`blob`, `tree`, `commit`, `tag`).

11
Documentation/git-format-patch.txt
View File

@@ -46,7 +46,8 @@ applies to that command line and you do not get "everything
since the beginning of the time". If you want to format
everything since project inception to one commit, say "git
format-patch \--root <commit>" to make it clear that it is the
latter case.
latter case. If you want to format a single commit, you can do
this with "git format-patch -1 <commit>".
By default, each output file is numbered sequentially from 1, and uses the
first line of the commit message (massaged for pathname safety) as
@@ -58,8 +59,10 @@ output, unless the --stdout option is specified.
If -o is specified, output files are created in <dir>. Otherwise
they are created in the current working directory.
If -n is specified, instead of "[PATCH] Subject", the first line
is formatted as "[PATCH n/m] Subject".
By default, the subject of a single patch is "[PATCH] First Line" and
the subject when multiple patches are output is "[PATCH n/m] First
Line". To force 1/1 to be added for a single patch, use -n. To omit
patch numbers from the subject, use -N
If given --thread, 'git-format-patch' will generate In-Reply-To and
References headers to make the second and subsequent patch mails appear
@@ -81,7 +84,7 @@ include::diff-options.txt[]
-n::
--numbered::
Name output in '[PATCH n/m]' format.
Name output in '[PATCH n/m]' format, even with a single patch.
-N::
--no-numbered::

3
Documentation/git-fsck.txt
View File

@@ -79,7 +79,8 @@ that aren't readable from any of the specified head nodes.
So for example
git fsck --unreachable HEAD $(cat .git/refs/heads/*)
git fsck --unreachable HEAD \
$(git for-each-ref --format="%(objectname)" refs/heads)
will do quite a _lot_ of verification on the tree. There are a few
extra validity tests to be added (make sure that tree objects are

6
Documentation/git-grep.txt
View File

@@ -15,6 +15,7 @@ SYNOPSIS
[-E | --extended-regexp] [-G | --basic-regexp]
[-F | --fixed-strings] [-n]
[-l | --files-with-matches] [-L | --files-without-match]
[-z | --null]
[-c | --count] [--all-match]
[-A <post-context>] [-B <pre-context>] [-C <context>]
[-f <file>] [-e] <pattern>
@@ -94,6 +95,11 @@ OPTIONS
For better compatibility with 'git-diff', --name-only is a
synonym for --files-with-matches.
-z::
--null::
Output \0 instead of the character that normally follows a
file name.
-c::
--count::
Instead of showing every matched line, show the number of

19
Documentation/git-gui.txt
View File

@@ -65,9 +65,28 @@ git gui blame v0.99.8 Makefile::
example the file is read from the object database and not
the working directory.
git gui blame --line=100 Makefile::
Loads annotations as described above and automatically
scrolls the view to center on line '100'.
git gui citool::
Make one commit and return to the shell when it is complete.
This command returns a non-zero exit code if the window was
closed in any way other than by making a commit.
git gui citool --amend::
Automatically enter the 'Amend Last Commit' mode of
the interface.
git gui citool --nocommit::
Behave as normal citool, but instead of making a commit
simply terminate with a zero exit code. It still checks
that the index does not contain any unmerged entries, so
you can use it as a GUI version of linkgit:git-mergetool[1]
git citool::

20
Documentation/git-hash-object.txt
View File

@@ -8,7 +8,9 @@ git-hash-object - Compute object ID and optionally creates a blob from a file
SYNOPSIS
--------
'git hash-object' [-t <type>] [-w] [--stdin | --stdin-paths] [--] <file>...
[verse]
'git hash-object' [-t <type>] [-w] [--path=<file>|--no-filters] [--stdin] [--] <file>...
'git hash-object' [-t <type>] [-w] --stdin-paths < <list-of-paths>
DESCRIPTION
-----------
@@ -35,6 +37,22 @@ OPTIONS
--stdin-paths::
Read file names from stdin instead of from the command-line.
--path::
Hash object as it were located at the given path. The location of
file does not directly influence on the hash value, but path is
used to determine what git filters should be applied to the object
before it can be placed to the object database, and, as result of
applying filters, the actual blob put into the object database may
differ from the given file. This option is mainly useful for hashing
temporary files located outside of the working directory or files
read from stdin.
--no-filters::
Hash the contents as is, ignoring any input filter that would
have been chosen by the attributes mechanism, including crlf
conversion. If the file is read from standard input then this
is always implied, unless the --path option is given.
Author
------
Written by Junio C Hamano <gitster@pobox.com>

4
Documentation/git-help.txt
View File

@@ -112,7 +112,9 @@ For example, this configuration:
will try to use konqueror first. But this may fail (for example if
DISPLAY is not set) and in that case emacs' woman mode will be tried.
If everything fails the 'man' program will be tried anyway.
If everything fails, or if no viewer is configured, the viewer specified
in the GIT_MAN_VIEWER environment variable will be tried. If that
fails too, the 'man' program will be tried anyway.
man.<tool>.path
~~~~~~~~~~~~~~~

80
Documentation/git-imap-send.txt
View File

@@ -3,7 +3,7 @@ git-imap-send(1)
NAME
----
git-imap-send - Dump a mailbox from stdin into an imap folder
git-imap-send - Send a collection of patches from stdin to an IMAP folder
SYNOPSIS
@@ -13,9 +13,9 @@ SYNOPSIS
DESCRIPTION
-----------
This command uploads a mailbox generated with git-format-patch
into an imap drafts folder. This allows patches to be sent as
other email is sent with mail clients that cannot read mailbox
This command uploads a mailbox generated with 'git-format-patch'
into an IMAP drafts folder. This allows patches to be sent as
other email is when using mail clients that cannot read mailbox
files directly.
Typical usage is something like:
@@ -26,21 +26,75 @@ git format-patch --signoff --stdout --attach origin | git imap-send
CONFIGURATION
-------------
'git-imap-send' requires the following values in the repository
configuration file (shown with examples):
To use the tool, imap.folder and either imap.tunnel or imap.host must be set
to appropriate values.
Variables
~~~~~~~~~
imap.folder::
The folder to drop the mails into, which is typically the Drafts
folder. For example: "INBOX.Drafts", "INBOX/Drafts" or
"[Gmail]/Drafts". Required to use imap-send.
imap.tunnel::
Command used to setup a tunnel to the IMAP server through which
commands will be piped instead of using a direct network connection
to the server. Required when imap.host is not set to use imap-send.
imap.host::
A URL identifying the server. Use a `imap://` prefix for non-secure
connections and a `imaps://` prefix for secure connections.
Ignored when imap.tunnel is set, but required to use imap-send
otherwise.
imap.user::
The username to use when logging in to the server.
imap.password::
The password to use when logging in to the server.
imap.port::
An integer port number to connect to on the server.
Defaults to 143 for imap:// hosts and 993 for imaps:// hosts.
Ignored when imap.tunnel is set.
imap.sslverify::
A boolean to enable/disable verification of the server certificate
used by the SSL/TLS connection. Default is `true`. Ignored when
imap.tunnel is set.
Examples
~~~~~~~~
Using tunnel mode:
..........................
[imap]
Folder = "INBOX.Drafts"
folder = "INBOX.Drafts"
tunnel = "ssh -q -C user@example.com /usr/bin/imapd ./Maildir 2> /dev/null"
..........................
[imap]
Tunnel = "ssh -q user@server.com /usr/bin/imapd ./Maildir 2> /dev/null"
Using direct mode:
.........................
[imap]
Host = imap.server.com
User = bob
Pass = pwd
Port = 143
folder = "INBOX.Drafts"
host = imap://imap.example.com
user = bob
pass = p4ssw0rd
..........................
Using direct mode with SSL:
.........................
[imap]
folder = "INBOX.Drafts"
host = imaps://imap.example.com
user = bob
pass = p4ssw0rd
port = 123
sslverify = false
..........................

13
Documentation/git-log.txt
View File

@@ -8,7 +8,7 @@ git-log - Show commit logs
SYNOPSIS
--------
'git log' <option>...
'git log' [<options>] [<since>..<until>] [[\--] <path>...]
DESCRIPTION
-----------
@@ -40,6 +40,10 @@ include::diff-options.txt[]
--decorate::
Print out the ref names of any commits that are shown.
--source::
Print out the ref name given on the command line by which each
commit was reached.
--full-diff::
Without this flag, "git log -p <path>..." shows commits that
touch the specified paths, and diffs about the same specified
@@ -57,8 +61,11 @@ include::diff-options.txt[]
Note that only message is considered, if also a diff is shown
its size is not included.
<path>...::
Show only commits that affect any of the specified paths.
[\--] <path>...::
Show only commits that affect any of the specified paths. To
prevent confusion with options and branch names, paths may need
to be prefixed with "\-- " to separate them from options or
refnames.
include::rev-list-options.txt[]

2
Documentation/git-mailinfo.txt
View File

@@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
Reading a single e-mail message from the standard input, and
Reads a single e-mail message from the standard input, and
writes the commit log message in <msg> file, and the patches in
<patch> file. The author name, e-mail and e-mail subject are
written out to the standard output to be used by 'git-am'

76
Documentation/git-merge-base.txt
View File

@@ -8,26 +8,80 @@ git-merge-base - Find as good common ancestors as possible for a merge
SYNOPSIS
--------
'git merge-base' [--all] <commit> <commit>
'git merge-base' [--all] <commit> <commit>...
DESCRIPTION
-----------
'git-merge-base' finds as good a common ancestor as possible between
the two commits. That is, given two commits A and B, `git merge-base A
B` will output a commit which is reachable from both A and B through
the parent relationship.
'git-merge-base' finds best common ancestor(s) between two commits to use
in a three-way merge. One common ancestor is 'better' than another common
ancestor if the latter is an ancestor of the former. A common ancestor
that does not have any better common ancestor is a 'best common
ancestor', i.e. a 'merge base'. Note that there can be more than one
merge base for a pair of commits.
Given a selection of equally good common ancestors it should not be
relied on to decide in any particular way.
The 'git-merge-base' algorithm is still in flux - use the source...
Among the two commits to compute the merge base from, one is specified by
the first commit argument on the command line; the other commit is a
(possibly hypothetical) commit that is a merge across all the remaining
commits on the command line. As the most common special case, specifying only
two commits on the command line means computing the merge base between
the given two commits.
OPTIONS
-------
--all::
Output all common ancestors for the two commits instead of
just one.
Output all merge bases for the commits, instead of just one.
DISCUSSION
----------
Given two commits 'A' and 'B', `git merge-base A B` will output a commit
which is reachable from both 'A' and 'B' through the parent relationship.
For example, with this topology:
o---o---o---B
/
---o---1---o---o---o---A
the merge base between 'A' and 'B' is '1'.
Given three commits 'A', 'B' and 'C', `git merge-base A B C` will compute the
merge base between 'A' and a hypothetical commit 'M', which is a merge
between 'B' and 'C'. For example, with this topology:
o---o---o---o---C
/
/ o---o---o---B
/ /
---2---1---o---o---o---A
the result of `git merge-base A B C` is '1'. This is because the
equivalent topology with a merge commit 'M' between 'B' and 'C' is:
o---o---o---o---o
/ \
/ o---o---o---o---M
/ /
---2---1---o---o---o---A
and the result of `git merge-base A M` is '1'. Commit '2' is also a
common ancestor between 'A' and 'M', but '1' is a better common ancestor,
because '2' is an ancestor of '1'. Hence, '2' is not a merge base.
When the history involves criss-cross merges, there can be more than one
'best' common ancestor for two commits. For example, with this topology:
---1---o---A
\ /
X
/ \
---2---o---o---B
both '1' and '2' are merge-bases of A and B. Neither one is better than
the other (both are 'best' merge bases). When the `--all` option is not given,
it is unspecified which best one is output.
Author
------

12
Documentation/git-merge-file.txt
View File

@@ -15,17 +15,17 @@ SYNOPSIS
DESCRIPTION
-----------
'git-file-merge' incorporates all changes that lead from the `<base-file>`
'git-merge-file' incorporates all changes that lead from the `<base-file>`
to `<other-file>` into `<current-file>`. The result ordinarily goes into
`<current-file>`. 'git-merge-file' is useful for combining separate changes
to an original. Suppose `<base-file>` is the original, and both
`<current-file>` and `<other-file>` are modifications of `<base-file>`.
Then 'git-merge-file' combines both changes.
`<current-file>` and `<other-file>` are modifications of `<base-file>`,
then 'git-merge-file' combines both changes.
A conflict occurs if both `<current-file>` and `<other-file>` have changes
in a common segment of lines. If a conflict is found, 'git-merge-file'
normally outputs a warning and brackets the conflict with <<<<<<< and
>>>>>>> lines. A typical conflict will look like this:
normally outputs a warning and brackets the conflict with lines containing
<<<<<<< and >>>>>>> markers. A typical conflict will look like this:
<<<<<<< A
lines in file A
@@ -60,7 +60,7 @@ OPTIONS
`<current-file>`.
-q::
Quiet; do not warn about conflicts.
Quiet; do not warn about conflicts.
EXAMPLES

6
Documentation/git-merge-index.txt
View File

@@ -29,11 +29,11 @@ OPTIONS
Instead of stopping at the first failed merge, do all of them
in one shot - continue with merging even when previous merges
returned errors, and only return the error code after all the
merges are over.
merges.
-q::
Do not complain about failed merge program (the merge program
failure usually indicates conflicts during merge). This is for
Do not complain about a failed merge program (a merge program
failure usually indicates conflicts during the merge). This is for
porcelains which might want to emit custom messages.
If 'git-merge-index' is called with multiple <file>s (or -a) then it

6
Documentation/git-merge-tree.txt
View File

@@ -14,14 +14,14 @@ DESCRIPTION
-----------
Reads three treeish, and output trivial merge results and
conflicting stages to the standard output. This is similar to
what three-way read-tree -m does, but instead of storing the
what three-way 'git read-tree -m' does, but instead of storing the
results in the index, the command outputs the entries to the
standard output.
This is meant to be used by higher level scripts to compute
merge results outside index, and stuff the results back into the
merge results outside of the index, and stuff the results back into the
index. For this reason, the output from the command omits
entries that match <branch1> tree.
entries that match the <branch1> tree.
Author
------

111
Documentation/git-merge.txt
View File

@@ -69,20 +69,20 @@ Three kinds of merge can happen:
simplest case, called "Already up-to-date."
* `HEAD` is already contained in the merged commit. This is the
most common case especially when involved through 'git pull':
you are tracking an upstream repository, committed no local
most common case especially when invoked from 'git pull':
you are tracking an upstream repository, have committed no local
changes and now you want to update to a newer upstream revision.
Your `HEAD` (and the index) is updated to at point the merged
Your `HEAD` (and the index) is updated to point at the merged
commit, without creating an extra merge commit. This is
called "Fast-forward".
* Both the merged commit and `HEAD` are independent and must be
tied together by a merge commit that has them both as its parents.
tied together by a merge commit that has both of them as its parents.
The rest of this section describes this "True merge" case.
The chosen merge strategy merges the two commits into a single
new source tree.
When things cleanly merge, these things happen:
When things merge cleanly, this is what happens:
1. The results are updated both in the index file and in your
working tree;
@@ -91,16 +91,16 @@ When things cleanly merge, these things happen:
4. The `HEAD` pointer gets advanced.
Because of 2., we require that the original state of the index
file to match exactly the current `HEAD` commit; otherwise we
file matches exactly the current `HEAD` commit; otherwise we
will write out your local changes already registered in your
index file along with the merge result, which is not good.
Because 1. involves only the paths different between your
Because 1. involves only those paths differing between your
branch and the remote branch you are pulling from during the
merge (which is typically a fraction of the whole tree), you can
have local modifications in your working tree as long as they do
not overlap with what the merge updates.
When there are conflicts, these things happen:
When there are conflicts, the following happens:
1. `HEAD` stays the same.
@@ -111,28 +111,105 @@ When there are conflicts, these things happen:
versions; stage1 stores the version from the common ancestor,
stage2 from `HEAD`, and stage3 from the remote branch (you
can inspect the stages with `git ls-files -u`). The working
tree files have the result of "merge" program; i.e. 3-way
merge result with familiar conflict markers `<<< === >>>`.
tree files contain the result of the "merge" program; i.e. 3-way
merge results with familiar conflict markers `<<< === >>>`.
4. No other changes are done. In particular, the local
modifications you had before you started merge will stay the
same and the index entries for them stay as they were,
i.e. matching `HEAD`.
HOW CONFLICTS ARE PRESENTED
---------------------------
During a merge, the working tree files are updated to reflect the result
of the merge. Among the changes made to the common ancestor's version,
non-overlapping ones (that is, you changed an area of the file while the
other side left that area intact, or vice versa) are incorporated in the
final result verbatim. When both sides made changes to the same area,
however, git cannot randomly pick one side over the other, and asks you to
resolve it by leaving what both sides did to that area.
By default, git uses the same style as that is used by "merge" program
from the RCS suite to present such a conflicted hunk, like this:
------------
Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.
------------
The area where a pair of conflicting changes happened is marked with markers
"`<<<<<<<`", "`=======`", and "`>>>>>>>`". The part before the "`=======`"
is typically your side, and the part afterwards is typically their side.
The default format does not show what the original said in the conflicting
area. You cannot tell how many lines are deleted and replaced with
Barbie's remark on your side. The only thing you can tell is that your
side wants to say it is hard and you'd prefer to go shopping, while the
other side wants to claim it is easy.
An alternative style can be used by setting the "merge.conflictstyle"
configuration variable to "diff3". In "diff3" style, the above conflict
may look like this:
------------
Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
|||||||
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.
------------
In addition to the "`<<<<<<<`", "`=======`", and "`>>>>>>>`" markers, it uses
another "`|||||||`" marker that is followed by the original text. You can
tell that the original just stated a fact, and your side simply gave in to
that statement and gave up, while the other side tried to have a more
positive attitude. You can sometimes come up with a better resolution by
viewing the original.
HOW TO RESOLVE CONFLICTS
------------------------
After seeing a conflict, you can do two things:
* Decide not to merge. The only clean-up you need are to reset
* Decide not to merge. The only clean-ups you need are to reset
the index file to the `HEAD` commit to reverse 2. and to clean
up working tree changes made by 2. and 3.; 'git-reset --hard' can
be used for this.
* Resolve the conflicts. `git diff` would report only the
conflicting paths because of the above 2. and 3.
Edit the working tree files into a desirable shape
('git mergetool' can ease this task), 'git-add' or 'git-rm'
them, to make the index file contain what the merge result
should be, and run 'git-commit' to commit the result.
* Resolve the conflicts. Git will mark the conflicts in
the working tree. Edit the files into shape and
'git-add' them to the index. Use 'git-commit' to seal the deal.
You can work through the conflict with a number of tools:
* Use a mergetool. 'git mergetool' to launch a graphical
mergetool which will work you through the merge.
* Look at the diffs. 'git diff' will show a three-way diff,
highlighting changes from both the HEAD and remote versions.
* Look at the diffs on their own. 'git log --merge -p <path>'
will show diffs first for the HEAD version and then the
remote version.
* Look at the originals. 'git show :1:filename' shows the
common ancestor, 'git show :2:filename' shows the HEAD
version and 'git show :3:filename' shows the remote version.
SEE ALSO
--------

4
Documentation/git-mergetool.txt
View File

@@ -38,7 +38,7 @@ can configure the absolute path to kdiff3 by setting
`mergetool.kdiff3.path`. Otherwise, 'git-mergetool' assumes the
tool is available in PATH.
+
Instead of running one of the known merge tool programs
Instead of running one of the known merge tool programs,
'git-mergetool' can be customized to run an alternative program
by specifying the command line to invoke in a configuration
variable `mergetool.<tool>.cmd`.
@@ -55,7 +55,7 @@ of the file to which the merge tool should write the result of the
merge resolution.
+
If the custom merge tool correctly indicates the success of a
merge resolution with its exit code then the configuration
merge resolution with its exit code, then the configuration
variable `mergetool.<tool>.trustExitCode` can be set to `true`.
Otherwise, 'git-mergetool' will prompt the user to indicate the
success of the resolution after the custom tool has exited.

7
Documentation/git-pack-objects.txt
View File

@@ -109,6 +109,11 @@ base-name::
The default is unlimited, unless the config variable
`pack.packSizeLimit` is set.
--honor-pack-keep::
This flag causes an object already in a local pack that
has a .keep file to be ignored, even if it appears in the
standard input.
--incremental::
This flag causes an object already in a pack ignored
even if it appears in the standard input.
@@ -116,7 +121,7 @@ base-name::
--local::
This flag is similar to `--incremental`; instead of
ignoring all packed objects, it only ignores objects
that are packed and not in the local object store
that are packed and/or not in the local object store
(i.e. borrowed from an alternate).
--non-empty::

5
Documentation/git-prune.txt
View File

@@ -8,7 +8,7 @@ git-prune - Prune all unreachable objects from the object database
SYNOPSIS
--------
'git-prune' [-n] [--expire <expire>] [--] [<head>...]
'git-prune' [-n] [-v] [--expire <expire>] [--] [<head>...]
DESCRIPTION
-----------
@@ -34,6 +34,9 @@ OPTIONS
Do not remove anything; just report what it would
remove.
-v::
Report all removed objects.
\--::
Do not interpret any more arguments as options.

24
Documentation/git-push.txt
View File

@@ -9,8 +9,8 @@ git-push - Update remote refs along with associated objects
SYNOPSIS
--------
[verse]
'git push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
[--repo=all] [-f | --force] [-v | --verbose]
'git push' [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [-v | --verbose]
[<repository> <refspec>...]
DESCRIPTION
@@ -101,9 +101,23 @@ nor in any Push line of the corresponding remotes file---see below).
This flag disables the check. This can cause the
remote repository to lose commits; use it with care.
--repo=<repo>::
When no repository is specified the command defaults to
"origin"; this overrides it.
--repo=<repository>::
This option is only relevant if no <repository> argument is
passed in the invocation. In this case, 'git-push' derives the
remote name from the current branch: If it tracks a remote
branch, then that remote repository is pushed to. Otherwise,
the name "origin" is used. For this latter case, this option
can be used to override the name "origin". In other words,
the difference between these two commands
+
--------------------------
git push public #1
git push --repo=public #2
--------------------------
+
is that #1 always pushes to "public" whereas #2 pushes to "public"
only if the current branch does not track a remote branch. This is
useful if you write an alias or script around 'git-push'.
--thin::
--no-thin::

2
Documentation/git-read-tree.txt
View File

@@ -212,7 +212,7 @@ output after two-tree merge.
Case #3 is slightly tricky and needs explanation. The result from this
rule logically should be to remove the path if the user staged the removal
of the path and then swiching to a new branch. That however will prevent
of the path and then switching to a new branch. That however will prevent
the initial checkout from happening, so the rule is modified to use M (new
tree) only when the contents of the index is empty. Otherwise the removal
of the path is kept as long as $H and $M are the same.

146
Documentation/git-rebase.txt
View File

@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
[-s <strategy> | --strategy=<strategy>]
[-s <strategy> | --strategy=<strategy>] [--no-verify]
[-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
[--onto <newbase>] <upstream> [<branch>]
'git rebase' --continue | --skip | --abort
@@ -92,7 +92,7 @@ branch to another, to pretend that you forked the topic branch
from the latter branch, using `rebase --onto`.
First let's assume your 'topic' is based on branch 'next'.
For example feature developed in 'topic' depends on some
For example, a feature developed in 'topic' depends on some
functionality which is found in 'next'.
------------
@@ -103,9 +103,9 @@ functionality which is found in 'next'.
o---o---o topic
------------
We would want to make 'topic' forked from branch 'master',
for example because the functionality 'topic' branch depend on
got merged into more stable 'master' branch, like this:
We want to make 'topic' forked from branch 'master'; for example,
because the functionality on which 'topic' depends was merged into the
more stable 'master' branch. We want our tree to look like this:
------------
o---o---o---o---o master
@@ -232,6 +232,9 @@ OPTIONS
--verbose::
Display a diffstat of what changed upstream since the last rebase.
--no-verify::
This option bypasses the pre-rebase hook. See also linkgit:githooks[5].
-C<n>::
Ensure at least <n> lines of surrounding context match before
and after each change. When fewer lines of surrounding
@@ -250,18 +253,16 @@ OPTIONS
-p::
--preserve-merges::
Instead of ignoring merges, try to recreate them. This option
only works in interactive mode.
Instead of ignoring merges, try to recreate them.
include::merge-strategies.txt[]
NOTES
-----
When you rebase a branch, you are changing its history in a way that
will cause problems for anyone who already has a copy of the branch
in their repository and tries to pull updates from you. You should
understand the implications of using 'git-rebase' on a repository that
you share.
You should understand the implications of using 'git-rebase' on a
repository that you share. See also RECOVERING FROM UPSTREAM REBASE
below.
When the git-rebase command is run, it will first execute a "pre-rebase"
hook if one exists. You can use this hook to do sanity checks and
@@ -396,6 +397,127 @@ consistent (they compile, pass the testsuite, etc.) you should use
after each commit, test, and amend the commit if fixes are necessary.
RECOVERING FROM UPSTREAM REBASE
-------------------------------
Rebasing (or any other form of rewriting) a branch that others have
based work on is a bad idea: anyone downstream of it is forced to
manually fix their history. This section explains how to do the fix
from the downstream's point of view. The real fix, however, would be
to avoid rebasing the upstream in the first place.
To illustrate, suppose you are in a situation where someone develops a
'subsystem' branch, and you are working on a 'topic' that is dependent
on this 'subsystem'. You might end up with a history like the
following:
------------
o---o---o---o---o---o---o---o---o master
\
o---o---o---o---o subsystem
\
*---*---* topic
------------
If 'subsystem' is rebased against 'master', the following happens:
------------
o---o---o---o---o---o---o---o master
\ \
o---o---o---o---o o'--o'--o'--o'--o' subsystem
\
*---*---* topic
------------
If you now continue development as usual, and eventually merge 'topic'
to 'subsystem', the commits from 'subsystem' will remain duplicated forever:
------------
o---o---o---o---o---o---o---o master
\ \
o---o---o---o---o o'--o'--o'--o'--o'--M subsystem
\ /
*---*---*-..........-*--* topic
------------
Such duplicates are generally frowned upon because they clutter up
history, making it harder to follow. To clean things up, you need to
transplant the commits on 'topic' to the new 'subsystem' tip, i.e.,
rebase 'topic'. This becomes a ripple effect: anyone downstream from
'topic' is forced to rebase too, and so on!
There are two kinds of fixes, discussed in the following subsections:
Easy case: The changes are literally the same.::
This happens if the 'subsystem' rebase was a simple rebase and
had no conflicts.
Hard case: The changes are not the same.::
This happens if the 'subsystem' rebase had conflicts, or used
`\--interactive` to omit, edit, or squash commits; or if the
upstream used one of `commit \--amend`, `reset`, or
`filter-branch`.
The easy case
~~~~~~~~~~~~~
Only works if the changes (patch IDs based on the diff contents) on
'subsystem' are literally the same before and after the rebase
'subsystem' did.
In that case, the fix is easy because 'git-rebase' knows to skip
changes that are already present in the new upstream. So if you say
(assuming you're on 'topic')
------------
$ git rebase subsystem
------------
you will end up with the fixed history
------------
o---o---o---o---o---o---o---o master
\
o'--o'--o'--o'--o' subsystem
\
*---*---* topic
------------
The hard case
~~~~~~~~~~~~~
Things get more complicated if the 'subsystem' changes do not exactly
correspond to the ones before the rebase.
NOTE: While an "easy case recovery" sometimes appears to be successful
even in the hard case, it may have unintended consequences. For
example, a commit that was removed via `git rebase
\--interactive` will be **resurrected**!
The idea is to manually tell 'git-rebase' "where the old 'subsystem'
ended and your 'topic' began", that is, what the old merge-base
between them was. You will have to find a way to name the last commit
of the old 'subsystem', for example:
* With the 'subsystem' reflog: after 'git-fetch', the old tip of
'subsystem' is at `subsystem@\{1}`. Subsequent fetches will
increase the number. (See linkgit:git-reflog[1].)
* Relative to the tip of 'topic': knowing that your 'topic' has three
commits, the old tip of 'subsystem' must be `topic~3`.
You can then transplant the old `subsystem..topic` to the new tip by
saying (for the reflog case, and assuming you are on 'topic' already):
------------
$ git rebase --onto subsystem subsystem@{1}
------------
The ripple effect of a "hard case" recovery is especially bad:
'everyone' downstream from 'topic' will now have to perform a "hard
case" recovery too!
Authors
------
Written by Junio C Hamano <gitster@pobox.com> and

4
Documentation/git-receive-pack.txt
View File

@@ -86,7 +86,7 @@ post-receive Hook
-----------------
After all refs were updated (or attempted to be updated), if any
ref update was successful, and if $GIT_DIR/hooks/post-receive
file exists and is executable, it will be invoke once with no
file exists and is executable, it will be invoked once with no
parameters. The standard input of the hook will be one line
for each successfully updated ref:
@@ -133,7 +133,7 @@ post-update Hook
----------------
After all other processing, if at least one ref was updated, and
if $GIT_DIR/hooks/post-update file exists and is executable, then
post-update will called with the list of refs that have been updated.
post-update will be called with the list of refs that have been updated.
This can be used to implement any repository wide cleanup tasks.
The exit code from this hook invocation is ignored; the only thing

4
Documentation/git-reflog.txt
View File

@@ -28,7 +28,7 @@ updated. This command is to manage the information recorded in it.
The subcommand "expire" is used to prune older reflog entries.
Entries older than `expire` time, or entries older than
`expire-unreachable` time and are not reachable from the current
`expire-unreachable` time and not reachable from the current
tip, are removed from the reflog. This is typically not used
directly by the end users -- instead, see linkgit:git-gc[1].
@@ -71,7 +71,7 @@ them.
which in turn defaults to 90 days.
--expire-unreachable=<time>::
Entries older than this time and are not reachable from
Entries older than this time and not reachable from
the current tip of the branch are pruned. Without the
option it is taken from configuration
`gc.reflogExpireUnreachable`, which in turn defaults to

10
Documentation/git-remote.txt
View File

@@ -11,6 +11,7 @@ SYNOPSIS
[verse]
'git remote' [-v | --verbose]
'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
'git remote rename' <old> <new>
'git remote rm' <name>
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
@@ -61,6 +62,15 @@ only makes sense in bare repositories. If a remote uses mirror
mode, furthermore, `git push` will always behave as if `\--mirror`
was passed.
'rename'::
Rename the remote named <old> to <new>. All remote tracking branches and
configuration settings for the remote are updated.
+
In case <old> and <new> are the same, and <old> is a file under
`$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to
the configuration file format.
'rm'::
Remove the remote named <name>. All remote tracking branches and

11
Documentation/git-repack.txt
View File

@@ -38,12 +38,11 @@ OPTIONS
dangling.
-A::
Same as `-a`, but any unreachable objects in a previous
pack become loose, unpacked objects, instead of being
left in the old pack. Unreachable objects are never
intentionally added to a pack, even when repacking.
When used with '-d', this option
prevents unreachable objects from being immediately
Same as `-a`, unless '-d' is used. Then any unreachable
objects in a previous pack become loose, unpacked objects,
instead of being left in the old pack. Unreachable objects
are never intentionally added to a pack, even when repacking.
This option prevents unreachable objects from being immediately
deleted by way of being left in the old pack and then
removed. Instead, the loose unreachable objects
will be pruned according to normal expiry rules

8
Documentation/git-reset.txt
View File

@@ -82,7 +82,9 @@ $ git reset --hard HEAD~3 <1>
+
<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad
and you do not want to ever see them again. Do *not* do this if
you have already given these commits to somebody else.
you have already given these commits to somebody else. (See the
"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for
the implications of doing so.)
Undo a commit, making it a topic branch::
+
@@ -128,7 +130,7 @@ Undo a merge or pull::
$ git pull <1>
Auto-merging nitfol
CONFLICT (content): Merge conflict in nitfol
Automatic merge failed/prevented; fix up by hand
Automatic merge failed; fix conflicts and then commit the result.
$ git reset --hard <2>
$ git pull . topic/branch <3>
Updating from 41223... to 13134...
@@ -175,6 +177,8 @@ $ git reset <3>
<3> At this point the index file still has all the WIP changes you
committed as 'snapshot WIP'. This updates the index to show your
WIP files as uncommitted.
+
See also linkgit:git-stash[1].
Reset a single file in the index::
+

6
Documentation/git-rev-list.txt
View File

@@ -32,9 +32,9 @@ SYNOPSIS
[ \--cherry-pick ]
[ \--encoding[=<encoding>] ]
[ \--(author|committer|grep)=<pattern> ]
[ \--regexp-ignore-case | \-i ]
[ \--extended-regexp | \-E ]
[ \--fixed-strings | \-F ]
[ \--regexp-ignore-case | -i ]
[ \--extended-regexp | -E ]
[ \--fixed-strings | -F ]
[ \--date={local|relative|default|iso|rfc|short} ]
[ [\--objects | \--objects-edge] [ \--unpacked ] ]
[ \--pretty | \--header ]

8
Documentation/git-revert.txt
View File

@@ -44,6 +44,14 @@ OPTIONS
option specifies the parent number (starting from 1) of
the mainline and allows revert to reverse the change
relative to the specified parent.
+
Reverting a merge commit declares that you will never want the tree changes
brought in by the merge. As a result, later merges will only bring in tree
changes introduced by commits that are not ancestors of the previously
reverted merge. This may or may not be what you want.
+
See the link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for
more details.
--no-edit::
With this option, 'git-revert' will not start the commit

272
Documentation/git-send-email.txt
View File

@@ -8,8 +8,7 @@ git-send-email - Send a collection of patches as emails
SYNOPSIS
--------
'git send-email' [options] <file|directory> [... file|directory]
'git send-email' [options] <file|directory|rev-list options>...
DESCRIPTION
@@ -20,12 +19,16 @@ The header of the email is configurable by command line options. If not
specified on the command line, the user will be prompted with a ReadLine
enabled interface to provide the necessary information.
OPTIONS
-------
The options available are:
Composing
~~~~~~~~~
--bcc::
Specify a "Bcc:" value for each email.
Specify a "Bcc:" value for each email. Default is the value of
'sendemail.bcc'.
+
The --bcc option must be repeated for each user you want on the bcc list.
@@ -34,25 +37,23 @@ The --bcc option must be repeated for each user you want on the bcc list.
+
The --cc option must be repeated for each user you want on the cc list.
--cc-cmd::
Specify a command to execute once per patch file which
should generate patch file specific "Cc:" entries.
Output of this command must be single email address per line.
Default is the value of 'sendemail.cccmd' configuration value.
--chain-reply-to::
--no-chain-reply-to::
If this is set, each email will be sent as a reply to the previous
email sent. If disabled with "--no-chain-reply-to", all emails after
the first will be sent as replies to the first email sent. When using
this, it is recommended that the first file given be an overview of the
entire patch series.
Default is the value of the 'sendemail.chainreplyto' configuration
value; if that is unspecified, default to --chain-reply-to.
--annotate::
Review each patch you're about to send in an editor. The setting
'sendemail.multiedit' defines if this will spawn one editor per patch
or one for all of them at once.
--compose::
Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
introductory message for the patch series.
+
When '--compose' is used, git send-email gets less interactive will use the
values of the headers you set there. If the body of the email (what you type
after the headers and a blank line) only contains blank (or GIT: prefixed)
lines, the summary won't be sent, but git-send-email will still use the
Headers values if you don't removed them.
+
If it wasn't able to see a header in the summary it will ask you about it
interactively after quitting your editor.
--from::
Specify the sender of the emails. This will default to
@@ -66,22 +67,47 @@ The --cc option must be repeated for each user you want on the cc list.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
--signed-off-by-cc::
--no-signed-off-by-cc::
If this is set, add emails found in Signed-off-by: or Cc: lines to the
cc list.
Default is the value of 'sendemail.signedoffcc' configuration value;
if that is unspecified, default to --signed-off-by-cc.
--subject::
Specify the initial subject of the email thread.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
--quiet::
Make git-send-email less verbose. One line per email should be
all that is output.
--to::
Specify the primary recipient of the emails generated. Generally, this
will be the upstream maintainer of the project involved. Default is the
value of the 'sendemail.to' configuration value; if that is unspecified,
this will be prompted for.
+
The --to option must be repeated for each user you want on the to list.
--identity::
A configuration identity. When given, causes values in the
'sendemail.<identity>' subsection to take precedence over
values in the 'sendemail' section. The default identity is
the value of 'sendemail.identity'.
Sending
~~~~~~~
--envelope-sender::
Specify the envelope sender used to send the emails.
This is useful if your default address is not the address that is
subscribed to a list. If you use the sendmail binary, you must have
suitable privileges for the -f parameter. Default is the value of
the 'sendemail.envelopesender' configuration variable; if that is
unspecified, choosing the envelope sender is left to your MTA.
--smtp-encryption::
Specify the encryption to use, either 'ssl' or 'tls'. Any other
value reverts to plain SMTP. Default is the value of
'sendemail.smtpencryption'.
--smtp-pass::
Password for SMTP-AUTH. The argument is optional: If no
argument is specified, then the empty string is used as
the password. Default is the value of 'sendemail.smtppass',
however '--smtp-pass' always overrides this value.
+
Furthermore, passwords need not be specified in configuration files
or on the command line. If a username has been specified (with
'--smtp-user' or a 'sendemail.smtpuser'), but no password has been
specified (with '--smtp-pass' or 'sendemail.smtppass'), then the
user is prompted for a password while the input is masked for privacy.
--smtp-server::
If set, specifies the outgoing SMTP server to use (e.g.
@@ -96,61 +122,44 @@ The --cc option must be repeated for each user you want on the cc list.
--smtp-server-port::
Specifies a port different from the default port (SMTP
servers typically listen to smtp port 25 and ssmtp port
465).
--smtp-user::
Username for SMTP-AUTH. In place of this option, the following
configuration variables can be specified:
+
--
* sendemail.smtpuser
* sendemail.<identity>.smtpuser (see sendemail.identity).
--
+
However, --smtp-user always overrides these variables.
+
If a username is not specified (with --smtp-user or a
configuration variable), then authentication is not attempted.
--smtp-pass::
Password for SMTP-AUTH. The argument is optional: If no
argument is specified, then the empty string is used as
the password.
+
In place of this option, the following configuration variables
can be specified:
+
--
* sendemail.smtppass
* sendemail.<identity>.smtppass (see sendemail.identity).
--
+
However, --smtp-pass always overrides these variables.
+
Furthermore, passwords need not be specified in configuration files
or on the command line. If a username has been specified (with
--smtp-user or a configuration variable), but no password has been
specified (with --smtp-pass or a configuration variable), then the
user is prompted for a password while the input is masked for privacy.
--smtp-encryption::
Specify the encryption to use, either 'ssl' or 'tls'. Any other
value reverts to plain SMTP. Default is the value of
'sendemail.smtpencryption'.
465). This can be set with 'sendemail.smtpserverport'.
--smtp-ssl::
Legacy alias for '--smtp-encryption=ssl'.
Legacy alias for '--smtp-encryption ssl'.
--subject::
Specify the initial subject of the email thread.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
--smtp-user::
Username for SMTP-AUTH. Default is the value of 'sendemail.smtpuser';
if a username is not specified (with '--smtp-user' or 'sendemail.smtpuser'),
then authentication is not attempted.
--suppress-from::
--no-suppress-from::
If this is set, do not add the From: address to the cc: list.
Default is the value of 'sendemail.suppressfrom' configuration value;
if that is unspecified, default to --no-suppress-from.
Automating
~~~~~~~~~~
--cc-cmd::
Specify a command to execute once per patch file which
should generate patch file specific "Cc:" entries.
Output of this command must be single email address per line.
Default is the value of 'sendemail.cccmd' configuration value.
--[no-]chain-reply-to::
If this is set, each email will be sent as a reply to the previous
email sent. If disabled with "--no-chain-reply-to", all emails after
the first will be sent as replies to the first email sent. When using
this, it is recommended that the first file given be an overview of the
entire patch series. Default is the value of the 'sendemail.chainreplyto'
configuration value; if that is unspecified, default to --chain-reply-to.
--identity::
A configuration identity. When given, causes values in the
'sendemail.<identity>' subsection to take precedence over
values in the 'sendemail' section. The default identity is
the value of 'sendemail.identity'.
--[no-]signed-off-by-cc::
If this is set, add emails found in Signed-off-by: or Cc: lines to the
cc list. Default is the value of 'sendemail.signedoffbycc' configuration
value; if that is unspecified, default to --signed-off-by-cc.
--suppress-cc::
Specify an additional category of recipients to suppress the
@@ -163,44 +172,49 @@ user is prompted for a password while the input is masked for privacy.
if that is unspecified, default to 'self' if --suppress-from is
specified, as well as 'sob' if --no-signed-off-cc is specified.
--thread::
--no-thread::
--[no-]suppress-from::
If this is set, do not add the From: address to the cc: list.
Default is the value of 'sendemail.suppressfrom' configuration
value; if that is unspecified, default to --no-suppress-from.
--[no-]thread::
If this is set, the In-Reply-To header will be set on each email sent.
If disabled with "--no-thread", no emails will have the In-Reply-To
header set.
Default is the value of the 'sendemail.thread' configuration value;
if that is unspecified, default to --thread.
header set. Default is the value of the 'sendemail.thread' configuration
value; if that is unspecified, default to --thread.
Administering
~~~~~~~~~~~~~
--dry-run::
Do everything except actually send the emails.
--envelope-sender::
Specify the envelope sender used to send the emails.
This is useful if your default address is not the address that is
subscribed to a list. If you use the sendmail binary, you must have
suitable privileges for the -f parameter.
Default is the value of the 'sendemail.envelopesender' configuration
variable; if that is unspecified, choosing the envelope sender is left
to your MTA.
--quiet::
Make git-send-email less verbose. One line per email should be
all that is output.
--to::
Specify the primary recipient of the emails generated.
Generally, this will be the upstream maintainer of the
project involved.
Default is the value of the 'sendemail.to' configuration value;
if that is unspecified, this will be prompted for.
--[no-]validate::
Perform sanity checks on patches.
Currently, validation means the following:
--[no-]format-patch::
When an argument may be understood either as a reference or as a file name,
choose to understand it as a format-patch argument ('--format-patch')
or as a file name ('--no-format-patch'). By default, when such a conflict
occurs, git send-email will fail.
+
The --to option must be repeated for each user you want on the to list.
--
* Warn of patches that contain lines longer than 998 characters; this
is due to SMTP limits as described by http://www.ietf.org/rfc/rfc2821.txt.
--
+
Default is the value of 'sendemail.validate'; if this is not set,
default to '--validate'.
CONFIGURATION
-------------
sendemail.identity::
The default configuration identity. When specified,
'sendemail.<identity>.<item>' will have higher precedence than
'sendemail.<item>'. This is useful to declare multiple SMTP
identities and to hoist sensitive authentication information
out of the repository and into the global configuration file.
sendemail.aliasesfile::
To avoid typing long email addresses, point this to one or more
@@ -210,38 +224,12 @@ sendemail.aliasfiletype::
Format of the file(s) specified in sendemail.aliasesfile. Must be
one of 'mutt', 'mailrc', 'pine', or 'gnus'.
sendemail.to::
Email address (or alias) to always send to.
sendemail.multiedit::
If true (default), a single editor instance will be spawned to edit
files you have to edit (patches when '--annotate' is used, and the
summary when '--compose' is used). If false, files will be edited one
after the other, spawning a new editor each time.
sendemail.cccmd::
Command to execute to generate per patch file specific "Cc:"s.
sendemail.bcc::
Email address (or alias) to always bcc.
sendemail.chainreplyto::
Boolean value specifying the default to the '--chain_reply_to'
parameter.
sendemail.smtpserver::
Default SMTP server to use.
sendemail.smtpserverport::
Default SMTP server port to use.
sendemail.smtpuser::
Default SMTP-AUTH username.
sendemail.smtppass::
Default SMTP-AUTH password.
sendemail.smtpencryption::
Default encryption method. Use 'ssl' for SSL (and specify an
appropriate port), or 'tls' for TLS. Takes precedence over
'smtpssl' if both are specified.
sendemail.smtpssl::
Legacy boolean that sets 'smtpencryption=ssl' if enabled.
Author
------
@@ -250,10 +238,12 @@ Written by Ryan Anderson <ryan@michonline.com>
git-send-email is originally based upon
send_lots_of_email.pl by Greg Kroah-Hartman.
Documentation
--------------
Documentation by Ryan Anderson
GIT
---
Part of the linkgit:git[1] suite

4
Documentation/git-show-branch.txt
View File

@@ -30,7 +30,7 @@ OPTIONS
-------
<rev>::
Arbitrary extended SHA1 expression (see linkgit:git-rev-parse[1])
that typically names a branch HEAD or a tag.
that typically names a branch head or a tag.
<glob>::
A glob pattern that matches branch or tag names under
@@ -172,7 +172,7 @@ only the primary branches. In addition, if you happen to be on
your topic branch, it is shown as well.
------------
$ git show-branch --reflog='10,1 hour ago' --list master
$ git show-branch --reflog="10,1 hour ago" --list master
------------
shows 10 reflog entries going back from the tip as of 1 hour ago.

19
Documentation/git-stage.txt Normal file
View File

@@ -0,0 +1,19 @@
git-stage(1)
==============
NAME
----
git-stage - Add file contents to the staging area
SYNOPSIS
--------
[verse]
'git stage' args...
DESCRIPTION
-----------
This is a synonym for linkgit:git-add[1]. Please refer to the
documentation of that command.

28
Documentation/git-submodule.txt
View File

@@ -14,6 +14,8 @@ SYNOPSIS
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [--] [<path>...]
'git submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
'git submodule' [--quiet] foreach <command>
'git submodule' [--quiet] sync [--] [<path>...]
DESCRIPTION
@@ -85,7 +87,7 @@ use by subsequent users cloning the superproject. If the URL is
given relative to the superproject's repository, the presumption
is the superproject and submodule repositories will be kept
together in the same relative location, and only the
superproject's URL need be provided: git-submodule will correctly
superproject's URL needs to be provided: git-submodule will correctly
locate the submodule using the relative URL in .gitmodules.
status::
@@ -123,6 +125,30 @@ summary::
in the submodule between the given super project commit and the
index or working tree (switched by --cached) are shown.
foreach::
Evaluates an arbitrary shell command in each checked out submodule.
The command has access to the variables $path and $sha1:
$path is the name of the submodule directory relative to the
superproject, and $sha1 is the commit as recorded in the superproject.
Any submodules defined in the superproject but not checked out are
ignored by this command. Unless given --quiet, foreach prints the name
of each submodule before evaluating the command.
A non-zero return from the command in any submodule causes
the processing to terminate. This can be overridden by adding '|| :'
to the end of the command.
+
As an example, "git submodule foreach 'echo $path `git rev-parse HEAD`' will
show the path and currently checked out commit for each submodule.
sync::
Synchronizes submodules' remote URL configuration setting
to the value specified in .gitmodules. This is useful when
submodule URLs change upstream and you need to update your local
repositories accordingly.
+
"git submodule sync" synchronizes all submodules while
"git submodule sync -- A" synchronizes submodule "A" only.
OPTIONS
-------
-q::

36
Documentation/git-svn.txt
View File

@@ -109,7 +109,7 @@ COMMANDS
This works similarly to `svn update` or 'git-pull' except that
it preserves linear history with 'git-rebase' instead of
'git-merge' for ease of dcommiting with 'git-svn'.
'git-merge' for ease of dcommitting with 'git-svn'.
This accepts all options that 'git-svn fetch' and 'git-rebase'
accept. However, '--fetch-all' only fetches from the current
@@ -149,6 +149,22 @@ and have no uncommitted changes.
is very strongly discouraged.
--
'branch'::
Create a branch in the SVN repository.
-m;;
--message;;
Allows to specify the commit message.
-t;;
--tag;;
Create a tag by using the tags_subdir instead of the branches_subdir
specified during git svn init.
'tag'::
Create a tag in the SVN repository. This is a shorthand for
'branch -t'.
'log'::
This should make it easy to look up svn log messages when svn
users refer to -r/--revision numbers.
@@ -372,7 +388,8 @@ Passed directly to 'git-rebase' when using 'dcommit' if a
-n::
--dry-run::
This can be used with the 'dcommit' and 'rebase' commands.
This can be used with the 'dcommit', 'rebase', 'branch' and 'tag'
commands.
For 'dcommit', print out the series of git arguments that would show
which diffs would be committed to SVN.
@@ -381,6 +398,9 @@ For 'rebase', display the local branch associated with the upstream svn
repository associated with the current branch and the URL of svn
repository that will be fetched from.
For 'branch' and 'tag', display the urls that will be used for copying when
creating the branch or tag.
--
ADVANCED OPTIONS
@@ -473,7 +493,7 @@ Tracking and contributing to the trunk of a Subversion-managed project:
------------------------------------------------------------------------
# Clone a repo (like git clone):
git svn clone http://svn.foo.org/project/trunk
git svn clone http://svn.example.com/project/trunk
# Enter the newly cloned directory:
cd trunk
# You should be on master branch, double-check with git-branch
@@ -495,9 +515,11 @@ Tracking and contributing to an entire Subversion-managed project
------------------------------------------------------------------------
# Clone a repo (like git clone):
git svn clone http://svn.foo.org/project -T trunk -b branches -t tags
git svn clone http://svn.example.com/project -T trunk -b branches -t tags
# View all branches and tags you have cloned:
git branch -r
# Create a new branch in SVN
git svn branch waldo
# Reset your master to trunk (or any other branch, replacing 'trunk'
# with the appropriate name):
git reset --hard remotes/trunk
@@ -514,7 +536,7 @@ have each person clone that repository with 'git-clone':
------------------------------------------------------------------------
# Do the initial import on a server
ssh server "cd /pub && git svn clone http://svn.foo.org/project
ssh server "cd /pub && git svn clone http://svn.example.com/project
# Clone locally - make sure the refs/remotes/ space matches the server
mkdir project
cd project
@@ -522,8 +544,10 @@ have each person clone that repository with 'git-clone':
git remote add origin server:/pub/project
git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git fetch
# Create a local branch from one of the branches just fetched
git checkout -b master FETCH_HEAD
# Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
git svn init http://svn.foo.org/project
git svn init http://svn.example.com/project
# Pull the latest changes from Subversion
git svn rebase
------------------------------------------------------------------------

8
Documentation/git-update-index.txt
View File

@@ -55,7 +55,7 @@ OPTIONS
default behavior is to error out. This option makes
'git-update-index' continue anyway.
--ignore-submodules:
--ignore-submodules::
Do not try to update submodules. This option is only respected
when passed before --refresh.
@@ -78,9 +78,9 @@ OPTIONS
--assume-unchanged::
--no-assume-unchanged::
When these flags are specified, the object name recorded
When these flags are specified, the object names recorded
for the paths are not updated. Instead, these options
sets and unsets the "assume unchanged" bit for the
set and unset the "assume unchanged" bit for the
paths. When the "assume unchanged" bit is on, git stops
checking the working tree files for possible
modifications, so you need to manually unset the bit to
@@ -122,7 +122,7 @@ you will need to handle the situation manually.
'git-update-index' refuses an attempt to add `path/file`.
Similarly if a file `path/file` exists, a file `path`
cannot be added. With --replace flag, existing entries
that conflicts with the entry being added are
that conflict with the entry being added are
automatically removed with warning messages.
--stdin::

1
Documentation/git-web--browse.txt
View File

@@ -26,6 +26,7 @@ The following browsers (or commands) are currently supported:
* lynx
* dillo
* open (this is the default under Mac OS X GUI)
* start (this is the default under MinGW)
Custom commands may also be specified.

17
Documentation/git.txt
View File

@@ -43,16 +43,21 @@ unreleased) version of git, that is available from 'master'
branch of the `git.git` repository.
Documentation for older releases are available here:
* link:v1.6.0.2/git.html[documentation for release 1.6.0.2]
* link:v1.6.0.6/git.html[documentation for release 1.6.0.6]
* release notes for
link:RelNotes-1.6.0.6.txt[1.6.0.6],
link:RelNotes-1.6.0.5.txt[1.6.0.5],
link:RelNotes-1.6.0.4.txt[1.6.0.4],
link:RelNotes-1.6.0.3.txt[1.6.0.3],
link:RelNotes-1.6.0.2.txt[1.6.0.2],
link:RelNotes-1.6.0.1.txt[1.6.0.1],
link:RelNotes-1.6.0.txt[1.6.0].
* link:v1.5.6.5/git.html[documentation for release 1.5.6.5]
* link:v1.5.6.6/git.html[documentation for release 1.5.6.6]
* release notes for
link:RelNotes-1.5.6.6.txt[1.5.6.6],
link:RelNotes-1.5.6.5.txt[1.5.6.5],
link:RelNotes-1.5.6.4.txt[1.5.6.4],
link:RelNotes-1.5.6.3.txt[1.5.6.3],
@@ -60,18 +65,22 @@ Documentation for older releases are available here:
link:RelNotes-1.5.6.1.txt[1.5.6.1],
link:RelNotes-1.5.6.txt[1.5.6].
* link:v1.5.5.4/git.html[documentation for release 1.5.5.4]
* link:v1.5.5.6/git.html[documentation for release 1.5.5.6]
* release notes for
link:RelNotes-1.5.5.6.txt[1.5.5.6],
link:RelNotes-1.5.5.5.txt[1.5.5.5],
link:RelNotes-1.5.5.4.txt[1.5.5.4],
link:RelNotes-1.5.5.3.txt[1.5.5.3],
link:RelNotes-1.5.5.2.txt[1.5.5.2],
link:RelNotes-1.5.5.1.txt[1.5.5.1],
link:RelNotes-1.5.5.txt[1.5.5].
* link:v1.5.4.5/git.html[documentation for release 1.5.4.5]
* link:v1.5.4.7/git.html[documentation for release 1.5.4.7]
* release notes for
link:RelNotes-1.5.4.7.txt[1.5.4.7],
link:RelNotes-1.5.4.6.txt[1.5.4.6],
link:RelNotes-1.5.4.5.txt[1.5.4.5],
link:RelNotes-1.5.4.4.txt[1.5.4.4],
link:RelNotes-1.5.4.3.txt[1.5.4.3],

105
Documentation/gitattributes.txt
View File

@@ -163,8 +163,8 @@ few exceptions. Even though...
`ident`
^^^^^^^
When the attribute `ident` is set to a path, git replaces
`$Id$` in the blob object with `$Id:`, followed by
When the attribute `ident` is set for a path, git replaces
`$Id$` in the blob object with `$Id:`, followed by the
40-character hexadecimal blob object name, followed by a dollar
sign `$` upon checkout. Any byte sequence that begins with
`$Id:` and ends with `$` in the worktree file is replaced
@@ -213,10 +213,15 @@ with `crlf`, and then `ident` and fed to `filter`.
Generating diff text
~~~~~~~~~~~~~~~~~~~~
The attribute `diff` affects if 'git-diff' generates textual
patch for the path or just says `Binary files differ`. It also
can affect what line is shown on the hunk header `@@ -k,l +n,m @@`
line.
`diff`
^^^^^^
The attribute `diff` affects how 'git' generates diffs for particular
files. It can tell git whether to generate a textual patch for the path
or to treat the path as a binary file. It can also affect what line is
shown on the hunk header `@@ -k,l +n,m @@` line, tell git to use an
external command to generate the diff, or ask git to convert binary
files to a text format before generating the diff.
Set::
@@ -227,7 +232,8 @@ Set::
Unset::
A path to which the `diff` attribute is unset will
generate `Binary files differ`.
generate `Binary files differ` (or a binary patch, if
binary patches are enabled).
Unspecified::
@@ -238,21 +244,21 @@ Unspecified::
String::
Diff is shown using the specified custom diff driver.
The driver program is given its input using the same
calling convention as used for GIT_EXTERNAL_DIFF
program. This name is also used for custom hunk header
selection.
Diff is shown using the specified diff driver. Each driver may
specify one or more options, as described in the following
section. The options for the diff driver "foo" are defined
by the configuration variables in the "diff.foo" section of the
git config file.
Defining a custom diff driver
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Defining an external diff driver
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The definition of a diff driver is done in `gitconfig`, not
`gitattributes` file, so strictly speaking this manual page is a
wrong place to talk about it. However...
To define a custom diff driver `jcdiff`, add a section to your
To define an external diff driver `jcdiff`, add a section to your
`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:
----------------------------------------------------------------
@@ -288,13 +294,13 @@ for paths.
*.tex diff=tex
------------------------
Then, you would define a "diff.tex.funcname" configuration to
Then, you would define a "diff.tex.xfuncname" configuration to
specify a regular expression that matches a line that you would
want to appear as the hunk header "TEXT", like this:
------------------------
[diff "tex"]
funcname = "^\\(\\\\\\(sub\\)*section{.*\\)$"
xfuncname = "^(\\\\(sub)*section\\{.*)$"
------------------------
Note. A single level of backslashes are eaten by the
@@ -311,18 +317,66 @@ patterns are available:
- `bibtex` suitable for files with BibTeX coded references.
- `html` suitable for HTML/XHTML documents.
- `java` suitable for source code in the Java language.
- `objc` suitable for source code in the Objective-C language.
- `pascal` suitable for source code in the Pascal/Delphi language.
- `php` suitable for source code in the PHP language.
- `python` suitable for source code in the Python language.
- `ruby` suitable for source code in the Ruby language.
- `tex` suitable for source code for LaTeX documents.
Performing text diffs of binary files
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sometimes it is desirable to see the diff of a text-converted
version of some binary files. For example, a word processor
document can be converted to an ASCII text representation, and
the diff of the text shown. Even though this conversion loses
some information, the resulting diff is useful for human
viewing (but cannot be applied directly).
The `textconv` config option is used to define a program for
performing such a conversion. The program should take a single
argument, the name of a file to convert, and produce the
resulting text on stdout.
For example, to show the diff of the exif information of a
file instead of the binary information (assuming you have the
exif tool installed):
------------------------
[diff "jpg"]
textconv = exif
------------------------
NOTE: The text conversion is generally a one-way conversion;
in this example, we lose the actual image contents and focus
just on the text data. This means that diffs generated by
textconv are _not_ suitable for applying. For this reason,
only `git diff` and the `git log` family of commands (i.e.,
log, whatchanged, show) will perform text conversion. `git
format-patch` will never generate this output. If you want to
send somebody a text-converted diff of a binary file (e.g.,
because it quickly conveys the changes you have made), you
should generate it separately and send it as a comment _in
addition to_ the usual binary diff that you might send.
Performing a three-way merge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
`merge`
^^^^^^^
The attribute `merge` affects how three versions of a file is
merged when a file-level merge is necessary during `git merge`,
and other programs such as `git revert` and `git cherry-pick`.
@@ -481,6 +535,23 @@ in the file. E.g. the string `$Format:%H$` will be replaced by the
commit hash.
Viewing files in GUI tools
~~~~~~~~~~~~~~~~~~~~~~~~~~
`encoding`
^^^^^^^^^^
The value of this attribute specifies the character encoding that should
be used by GUI tools (e.g. linkgit:gitk[1] and linkgit:git-gui[1]) to
display the contents of the relevant file. Note that due to performance
considerations linkgit:gitk[1] does not use this attribute unless you
manually enable per-file encodings in its options.
If this attribute is not set or has an invalid value, the value of the
`gui.encoding` configuration variable is used instead
(See linkgit:git-config[1]).
USING ATTRIBUTE MACROS
----------------------

26
Documentation/gitcore-tutorial.txt
View File

@@ -899,7 +899,7 @@ file, which had no differences in the `mybranch` branch), and say:
----------------
Auto-merging hello
CONFLICT (content): Merge conflict in hello
Automatic merge failed; fix up by hand
Automatic merge failed; fix conflicts and then commit the result.
----------------
It tells you that it did an "Automatic merge", which
@@ -993,14 +993,14 @@ would be different)
----------------
Updating from ae3a2da... to a80b4aa....
Fast forward
Fast forward (no commit created; -m option ignored)
example | 1 +
hello | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
----------------
Because your branch did not contain anything more than what are
already merged into the `master` branch, the merge operation did
Because your branch did not contain anything more than what had
already been merged into the `master` branch, the merge operation did
not actually do a merge. Instead, it just updated the top of
the tree of your branch to that of the `master` branch. This is
often called 'fast forward' merge.
@@ -1265,9 +1265,8 @@ file, using 3-way merge. This is done by giving
------------
$ git merge-index git-merge-one-file hello
Auto-merging hello.
merge: warning: conflicts during merge
ERROR: Merge conflict in hello.
Auto-merging hello
ERROR: Merge conflict in hello
fatal: merge program failed
------------
@@ -1353,7 +1352,7 @@ $ GIT_DIR=my-git.git git init
------------
Make sure this directory is available for others you want your
changes to be pulled by via the transport of your choice. Also
changes to be pulled via the transport of your choice. Also
you need to make sure that you have the 'git-receive-pack'
program on the `$PATH`.
@@ -1447,7 +1446,7 @@ public repository you might want to repack & prune often, or
never.
If you run `git repack` again at this point, it will say
"Nothing to pack". Once you continue your development and
"Nothing new to pack.". Once you continue your development and
accumulate the changes, running `git repack` again will create a
new pack, that contains objects created since you packed your
repository the last time. We recommend that you pack your project
@@ -1512,7 +1511,7 @@ You can repack this private repository whenever you feel like.
6. Push your changes to the public repository, and announce it
to the public.
7. Every once in a while, "git-repack" the public repository.
7. Every once in a while, 'git-repack' the public repository.
Go back to step 5. and continue working.
@@ -1690,8 +1689,11 @@ to follow, not easier.
SEE ALSO
--------
linkgit:gittutorial[7], linkgit:gittutorial-2[7],
linkgit:everyday[7], linkgit:gitcvs-migration[7],
linkgit:gittutorial[7],
linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
GIT

6
Documentation/gitglossary.txt
View File

@@ -16,8 +16,10 @@ include::glossary-content.txt[]
SEE ALSO
--------
linkgit:gittutorial[7], linkgit:gittutorial-2[7],
linkgit:everyday[7], linkgit:gitcvs-migration[7],
linkgit:gittutorial[7],
linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]
GIT

17
Documentation/githooks.txt
View File

@@ -20,6 +20,10 @@ directory to trigger action at certain points. When
all disabled. To enable a hook, rename it by removing its `.sample`
suffix.
NOTE: It is also a requirement for a given hook to be executable.
However - in a freshly initialized repository - the `.sample` files are
executable by default.
This document describes the currently defined hooks.
applypatch-msg
@@ -87,12 +91,12 @@ default log message, and before the editor is started.
It takes one to three parameters. The first is the name of the file
that the commit log message. The second is the source of the commit
message, and can be: `message` (if a `\-m` or `\-F` option was
given); `template` (if a `\-t` option was given or the
message, and can be: `message` (if a `-m` or `-F` option was
given); `template` (if a `-t` option was given or the
configuration option `commit.template` is set); `merge` (if the
commit is a merge or a `.git/MERGE_MSG` file exists); `squash`
(if a `.git/SQUASH_MSG` file exists); or `commit`, followed by
a commit SHA1 (if a `\-c`, `\-C` or `\--amend` option was given).
a commit SHA1 (if a `-c`, `-C` or `\--amend` option was given).
If the exit status is non-zero, 'git-commit' will abort.
@@ -130,6 +134,13 @@ parameter, and is invoked after a commit is made.
This hook is meant primarily for notification, and cannot affect
the outcome of 'git-commit'.
pre-rebase
----------
This hook is called by 'git-rebase' and can be used to prevent a branch
from getting rebased.
post-checkout
-----------

9
Documentation/gitk.txt
View File

@@ -21,7 +21,7 @@ git repository.
OPTIONS
-------
To control which revisions to shown, the command takes options applicable to
To control which revisions to show, the command takes options applicable to
the 'git-rev-list' command (see linkgit:git-rev-list[1]).
This manual page describes only the most
frequently used options.
@@ -56,6 +56,11 @@ frequently used options.
Use this instead of explicitly specifying <revs> if the set of
commits to show may vary between refreshes.
--select-commit=<ref>::
Automatically select the specified commit after loading the graph.
Default behavior is equivalent to specifying '--select-commit=HEAD'.
<revs>::
Limit the revisions to show. This can be either a single revision
@@ -75,7 +80,7 @@ Examples
--------
gitk v2.6.12.. include/scsi drivers/scsi::
Show as the changes since version 'v2.6.12' that changed any
Show the changes since version 'v2.6.12' that changed any
file in the include/scsi or drivers/scsi subdirectories
gitk --since="2 weeks ago" \-- gitk::

3
Documentation/gitrepository-layout.txt
View File

@@ -134,7 +134,8 @@ hooks::
Hooks are customization scripts used by various git
commands. A handful of sample hooks are installed when
'git-init' is run, but all of them are disabled by
default. To enable, they need to be made executable.
default. To enable, the `.sample` suffix has to be
removed from the filename by renaming.
Read linkgit:githooks[5] for more details about
each hook.

16
Documentation/gittutorial-2.txt
View File

@@ -32,22 +32,27 @@ Initialized empty Git repository in .git/
$ echo 'hello world' > file.txt
$ git add .
$ git commit -a -m "initial commit"
Created initial commit 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
[master (root-commit)] created 54196cc: "initial commit"
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file.txt
$ echo 'hello world!' >file.txt
$ git commit -a -m "add emphasis"
Created commit c4d59f390b9cfd4318117afde11d601c1085f241
[master] created c4d59f3: "add emphasis"
1 files changed, 1 insertions(+), 1 deletions(-)
------------------------------------------------
What are the 40 digits of hex that git responded to the commit with?
What are the 7 digits of hex that git responded to the commit with?
We saw in part one of the tutorial that commits have names like this.
It turns out that every object in the git history is stored under
such a 40-digit hex name. That name is the SHA1 hash of the object's
a 40-digit hex name. That name is the SHA1 hash of the object's
contents; among other things, this ensures that git will never store
the same data twice (since identical data is given an identical SHA1
name), and that the contents of a git object will never change (since
that would change the object's name as well).
that would change the object's name as well). The 7 char hex strings
here are simply the abbreviation of such 40 character long strings.
Abbreviations can be used everywhere where the 40 character strings
can be used, so long as they are unambiguous.
It is expected that the content of the commit object you created while
following the example above generates a different SHA1 hash than
@@ -420,6 +425,7 @@ linkgit:gittutorial[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]

10
Documentation/gittutorial.txt
View File

@@ -26,6 +26,15 @@ First, note that you can get documentation for a command such as
$ man git-log
------------------------------------------------
or:
------------------------------------------------
$ git help log
------------------------------------------------
With the latter, you can use the manual viewer of your choice; see
linkgit:git-help[1] for more information.
It is a good idea to introduce yourself to git with your name and
public email address before doing any operation. The easiest
way to do so is:
@@ -653,6 +662,7 @@ linkgit:gittutorial-2[7],
linkgit:gitcvs-migration[7],
linkgit:gitcore-tutorial[7],
linkgit:gitglossary[7],
linkgit:git-help[1],
link:everyday.html[Everyday git],
link:user-manual.html[The Git User's Manual]

364
Documentation/gitworkflows.txt Normal file
View File

@@ -0,0 +1,364 @@
gitworkflows(7)
===============
NAME
----
gitworkflows - An overview of recommended workflows with git
SYNOPSIS
--------
git *
DESCRIPTION
-----------
This document attempts to write down and motivate some of the workflow
elements used for `git.git` itself. Many ideas apply in general,
though the full workflow is rarely required for smaller projects with
fewer people involved.
We formulate a set of 'rules' for quick reference, while the prose
tries to motivate each of them. Do not always take them literally;
you should value good reasons for your actions higher than manpages
such as this one.
SEPARATE CHANGES
----------------
As a general rule, you should try to split your changes into small
logical steps, and commit each of them. They should be consistent,
working independently of any later commits, pass the test suite, etc.
This makes the review process much easier, and the history much more
useful for later inspection and analysis, for example with
linkgit:git-blame[1] and linkgit:git-bisect[1].
To achieve this, try to split your work into small steps from the very
beginning. It is always easier to squash a few commits together than
to split one big commit into several. Don't be afraid of making too
small or imperfect steps along the way. You can always go back later
and edit the commits with `git rebase \--interactive` before you
publish them. You can use `git stash save \--keep-index` to run the
test suite independent of other uncommitted changes; see the EXAMPLES
section of linkgit:git-stash[1].
MANAGING BRANCHES
-----------------
There are two main tools that can be used to include changes from one
branch on another: linkgit:git-merge[1] and
linkgit:git-cherry-pick[1].
Merges have many advantages, so we try to solve as many problems as
possible with merges alone. Cherry-picking is still occasionally
useful; see "Merging upwards" below for an example.
Most importantly, merging works at the branch level, while
cherry-picking works at the commit level. This means that a merge can
carry over the changes from 1, 10, or 1000 commits with equal ease,
which in turn means the workflow scales much better to a large number
of contributors (and contributions). Merges are also easier to
understand because a merge commit is a "promise" that all changes from
all its parents are now included.
There is a tradeoff of course: merges require a more careful branch
management. The following subsections discuss the important points.
Graduation
~~~~~~~~~~
As a given feature goes from experimental to stable, it also
"graduates" between the corresponding branches of the software.
`git.git` uses the following 'integration branches':
* 'maint' tracks the commits that should go into the next "maintenance
release", i.e., update of the last released stable version;
* 'master' tracks the commits that should go into the next release;
* 'next' is intended as a testing branch for topics being tested for
stability for master.
There is a fourth official branch that is used slightly differently:
* 'pu' (proposed updates) is an integration branch for things that are
not quite ready for inclusion yet (see "Integration Branches"
below).
Each of the four branches is usually a direct descendant of the one
above it.
Conceptually, the feature enters at an unstable branch (usually 'next'
or 'pu'), and "graduates" to 'master' for the next release once it is
considered stable enough.
Merging upwards
~~~~~~~~~~~~~~~
The "downwards graduation" discussed above cannot be done by actually
merging downwards, however, since that would merge 'all' changes on
the unstable branch into the stable one. Hence the following:
.Merge upwards
[caption="Rule: "]
=====================================
Always commit your fixes to the oldest supported branch that require
them. Then (periodically) merge the integration branches upwards into each
other.
=====================================
This gives a very controlled flow of fixes. If you notice that you
have applied a fix to e.g. 'master' that is also required in 'maint',
you will need to cherry-pick it (using linkgit:git-cherry-pick[1])
downwards. This will happen a few times and is nothing to worry about
unless you do it very frequently.
Topic branches
~~~~~~~~~~~~~~
Any nontrivial feature will require several patches to implement, and
may get extra bugfixes or improvements during its lifetime.
Committing everything directly on the integration branches leads to many
problems: Bad commits cannot be undone, so they must be reverted one
by one, which creates confusing histories and further error potential
when you forget to revert part of a group of changes. Working in
parallel mixes up the changes, creating further confusion.
Use of "topic branches" solves these problems. The name is pretty
self explanatory, with a caveat that comes from the "merge upwards"
rule above:
.Topic branches
[caption="Rule: "]
=====================================
Make a side branch for every topic (feature, bugfix, ...). Fork it off
at the oldest integration branch that you will eventually want to merge it
into.
=====================================
Many things can then be done very naturally:
* To get the feature/bugfix into an integration branch, simply merge
it. If the topic has evolved further in the meantime, merge again.
(Note that you do not necessarily have to merge it to the oldest
integration branch first. For example, you can first merge a bugfix
to 'next', give it some testing time, and merge to 'maint' when you
know it is stable.)
* If you find you need new features from the branch 'other' to continue
working on your topic, merge 'other' to 'topic'. (However, do not
do this "just habitually", see below.)
* If you find you forked off the wrong branch and want to move it
"back in time", use linkgit:git-rebase[1].
Note that the last point clashes with the other two: a topic that has
been merged elsewhere should not be rebased. See the section on
RECOVERING FROM UPSTREAM REBASE in linkgit:git-rebase[1].
We should point out that "habitually" (regularly for no real reason)
merging an integration branch into your topics -- and by extension,
merging anything upstream into anything downstream on a regular basis
-- is frowned upon:
.Merge to downstream only at well-defined points
[caption="Rule: "]
=====================================
Do not merge to downstream except with a good reason: upstream API
changes affect your branch; your branch no longer merges to upstream
cleanly; etc.
=====================================
Otherwise, the topic that was merged to suddenly contains more than a
single (well-separated) change. The many resulting small merges will
greatly clutter up history. Anyone who later investigates the history
of a file will have to find out whether that merge affected the topic
in development. An upstream might even inadvertently be merged into a
"more stable" branch. And so on.
Throw-away integration
~~~~~~~~~~~~~~~~~~~~~~
If you followed the last paragraph, you will now have many small topic
branches, and occasionally wonder how they interact. Perhaps the
result of merging them does not even work? But on the other hand, we
want to avoid merging them anywhere "stable" because such merges
cannot easily be undone.
The solution, of course, is to make a merge that we can undo: merge
into a throw-away branch.
.Throw-away integration branches
[caption="Rule: "]
=====================================
To test the interaction of several topics, merge them into a
throw-away branch. You must never base any work on such a branch!
=====================================
If you make it (very) clear that this branch is going to be deleted
right after the testing, you can even publish this branch, for example
to give the testers a chance to work with it, or other developers a
chance to see if their in-progress work will be compatible. `git.git`
has such an official throw-away integration branch called 'pu'.
DISTRIBUTED WORKFLOWS
---------------------
After the last section, you should know how to manage topics. In
general, you will not be the only person working on the project, so
you will have to share your work.
Roughly speaking, there are two important workflows: merge and patch.
The important difference is that the merge workflow can propagate full
history, including merges, while patches cannot. Both workflows can
be used in parallel: in `git.git`, only subsystem maintainers use
the merge workflow, while everyone else sends patches.
Note that the maintainer(s) may impose restrictions, such as
"Signed-off-by" requirements, that all commits/patches submitted for
inclusion must adhere to. Consult your project's documentation for
more information.
Merge workflow
~~~~~~~~~~~~~~
The merge workflow works by copying branches between upstream and
downstream. Upstream can merge contributions into the official
history; downstream base their work on the official history.
There are three main tools that can be used for this:
* linkgit:git-push[1] copies your branches to a remote repository,
usually to one that can be read by all involved parties;
* linkgit:git-fetch[1] that copies remote branches to your repository;
and
* linkgit:git-pull[1] that does fetch and merge in one go.
Note the last point. Do 'not' use 'git-pull' unless you actually want
to merge the remote branch.
Getting changes out is easy:
.Push/pull: Publishing branches/topics
[caption="Recipe: "]
=====================================
`git push <remote> <branch>` and tell everyone where they can fetch
from.
=====================================
You will still have to tell people by other means, such as mail. (Git
provides the linkgit:git-request-pull[1] to send preformatted pull
requests to upstream maintainers to simplify this task.)
If you just want to get the newest copies of the integration branches,
staying up to date is easy too:
.Push/pull: Staying up to date
[caption="Recipe: "]
=====================================
Use `git fetch <remote>` or `git remote update` to stay up to date.
=====================================
Then simply fork your topic branches from the stable remotes as
explained earlier.
If you are a maintainer and would like to merge other people's topic
branches to the integration branches, they will typically send a
request to do so by mail. Such a request looks like
-------------------------------------
Please pull from
<url> <branch>
-------------------------------------
In that case, 'git-pull' can do the fetch and merge in one go, as
follows.
.Push/pull: Merging remote topics
[caption="Recipe: "]
=====================================
`git pull <url> <branch>`
=====================================
Occasionally, the maintainer may get merge conflicts when he tries to
pull changes from downstream. In this case, he can ask downstream to
do the merge and resolve the conflicts themselves (perhaps they will
know better how to resolve them). It is one of the rare cases where
downstream 'should' merge from upstream.
Patch workflow
~~~~~~~~~~~~~~
If you are a contributor that sends changes upstream in the form of
emails, you should use topic branches as usual (see above). Then use
linkgit:git-format-patch[1] to generate the corresponding emails
(highly recommended over manually formatting them because it makes the
maintainer's life easier).
.format-patch/am: Publishing branches/topics
[caption="Recipe: "]
=====================================
* `git format-patch -M upstream..topic` to turn them into preformatted
patch files
* `git send-email --to=<recipient> <patches>`
=====================================
See the linkgit:git-format-patch[1] and linkgit:git-send-email[1]
manpages for further usage notes.
If the maintainer tells you that your patch no longer applies to the
current upstream, you will have to rebase your topic (you cannot use a
merge because you cannot format-patch merges):
.format-patch/am: Keeping topics up to date
[caption="Recipe: "]
=====================================
`git pull --rebase <url> <branch>`
=====================================
You can then fix the conflicts during the rebase. Presumably you have
not published your topic other than by mail, so rebasing it is not a
problem.
If you receive such a patch series (as maintainer, or perhaps as a
reader of the mailing list it was sent to), save the mails to files,
create a new topic branch and use 'git-am' to import the commits:
.format-patch/am: Importing patches
[caption="Recipe: "]
=====================================
`git am < patch`
=====================================
One feature worth pointing out is the three-way merge, which can help
if you get conflicts: `git am -3` will use index information contained
in patches to figure out the merge base. See linkgit:git-am[1] for
other options.
SEE ALSO
--------
linkgit:gittutorial[7],
linkgit:git-push[1],
linkgit:git-pull[1],
linkgit:git-merge[1],
linkgit:git-rebase[1],
linkgit:git-format-patch[1],
linkgit:git-send-email[1],
linkgit:git-am[1]
GIT
---
Part of the linkgit:git[1] suite.

3
Documentation/glossary-content.txt
View File

@@ -183,7 +183,8 @@ to point at the new commit.
and potentially aborted, and allow for a post-notification after the
operation is done. The hook scripts are found in the
`$GIT_DIR/hooks/` directory, and are enabled by simply
making them executable.
removing the `.sample` suffix from the filename. In earlier versions
of git you had to make them executable.
[[def_index]]index::
A collection of files with stat information, whose contents are stored

79
Documentation/howto/rebase-and-edit.txt
View File

@@ -1,79 +0,0 @@
Date: Sat, 13 Aug 2005 22:16:02 -0700 (PDT)
From: Linus Torvalds <torvalds@osdl.org>
To: Steve French <smfrench@austin.rr.com>
cc: git@vger.kernel.org
Subject: Re: sending changesets from the middle of a git tree
Abstract: In this article, Linus demonstrates how a broken commit
in a sequence of commits can be removed by rewinding the head and
reapplying selected changes.
On Sat, 13 Aug 2005, Linus Torvalds wrote:
> That's correct. Same things apply: you can move a patch over, and create a
> new one with a modified comment, but basically the _old_ commit will be
> immutable.
Let me clarify.
You can entirely _drop_ old branches, so commits may be immutable, but
nothing forces you to keep them. Of course, when you drop a commit, you'll
always end up dropping all the commits that depended on it, and if you
actually got somebody else to pull that commit you can't drop it from
_their_ repository, but undoing things is not impossible.
For example, let's say that you've made a mess of things: you've committed
three commits "old->a->b->c", and you notice that "a" was broken, but you
want to save "b" and "c". What you can do is
# Create a branch "broken" that is the current code
# for reference
git branch broken
# Reset the main branch to three parents back: this
# effectively undoes the three top commits
git reset HEAD^^^
git checkout -f
# Check the result visually to make sure you know what's
# going on
gitk --all
# Re-apply the two top ones from "broken"
#
# First "parent of broken" (aka b):
git-diff-tree -p broken^ | git-apply --index
git commit --reedit=broken^
# Then "top of broken" (aka c):
git-diff-tree -p broken | git-apply --index
git commit --reedit=broken
and you've now re-applied (and possibly edited the comments) the two
commits b/c, and commit "a" is basically gone (it still exists in the
"broken" branch, of course).
Finally, check out the end result again:
# Look at the new commit history
gitk --all
to see that everything looks sensible.
And then, you can just remove the broken branch if you decide you really
don't want it:
# remove 'broken' branch
git branch -d broken
# Prune old objects if you're really really sure
git prune
And yeah, I'm sure there are other ways of doing this. And as usual, the
above is totally untested, and I just wrote it down in this email, so if
I've done something wrong, you'll have to figure it out on your own ;)
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

179
Documentation/howto/revert-a-faulty-merge.txt Normal file
View File

@@ -0,0 +1,179 @@
Date: Fri, 19 Dec 2008 00:45:19 -0800
From: Linus Torvalds <torvalds@linux-foundation.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: Odd merge behaviour involving reverts
Abstract: Sometimes a branch that was already merged to the mainline
is later found to be faulty. Linus and Junio give guidance on
recovering from such a premature merge and continuing development
after the offending branch is fixed.
Message-ID: <7vocz8a6zk.fsf@gitster.siamese.dyndns.org>
References: <alpine.LFD.2.00.0812181949450.14014@localhost.localdomain>
Alan <alan@clueserver.org> said:
I have a master branch. We have a branch off of that that some
developers are doing work on. They claim it is ready. We merge it
into the master branch. It breaks something so we revert the merge.
They make changes to the code. they get it to a point where they say
it is ok and we merge again.
When examined, we find that code changes made before the revert are
not in the master branch, but code changes after are in the master
branch.
and asked for help recovering from this situation.
The history immediately after the "revert of the merge" would look like
this:
---o---o---o---M---x---x---W
/
---A---B
where A and B are on the side development that was not so good, M is the
merge that brings these premature changes into the mainline, x are changes
unrelated to what the side branch did and already made on the mainline,
and W is the "revert of the merge M" (doesn't W look M upside down?).
IOW, "diff W^..W" is similar to "diff -R M^..M".
Such a "revert" of a merge can be made with:
$ git revert -m 1 M
After the develpers of the side branch fixes their mistakes, the history
may look like this:
---o---o---o---M---x---x---W---x
/
---A---B-------------------C---D
where C and D are to fix what was broken in A and B, and you may already
have some other changes on the mainline after W.
If you merge the updated side branch (with D at its tip), none of the
changes made in A nor B will be in the result, because they were reverted
by W. That is what Alan saw.
Linus explains the situation:
Reverting a regular commit just effectively undoes what that commit
did, and is fairly straightforward. But reverting a merge commit also
undoes the _data_ that the commit changed, but it does absolutely
nothing to the effects on _history_ that the merge had.
So the merge will still exist, and it will still be seen as joining
the two branches together, and future merges will see that merge as
the last shared state - and the revert that reverted the merge brought
in will not affect that at all.
So a "revert" undoes the data changes, but it's very much _not_ an
"undo" in the sense that it doesn't undo the effects of a commit on
the repository history.
So if you think of "revert" as "undo", then you're going to always
miss this part of reverts. Yes, it undoes the data, but no, it doesn't
undo history.
In such a situation, you would want to first revert the previous revert,
which would make the history look like this:
---o---o---o---M---x---x---W---x---Y
/
---A---B-------------------C---D
where Y is the revert of W. Such a "revert of the revert" can be done
with:
$ git revert W
This history would (ignoring possible conflicts between what W and W..Y
changed) be equivalent to not having W nor Y at all in the history:
---o---o---o---M---x---x-------x----
/
---A---B-------------------C---D
and merging the side branch again will not have conflict arising from an
earlier revert and revert of the revert.
---o---o---o---M---x---x-------x-------*
/ /
---A---B-------------------C---D
Of course the changes made in C and D still can conflict with what was
done by any of the x, but that is just a normal merge conflict.
On the other hand, if the developers of the side branch discarded their
faulty A and B, and redone the changes on top of the updated mainline
after the revert, the history would have looked like this:
---o---o---o---M---x---x---W---x---x
/ \
---A---B A'--B'--C'
If you reverted the revert in such a case as in the previous example:
---o---o---o---M---x---x---W---x---x---Y---*
/ \ /
---A---B A'--B'--C'
where Y is the revert of W, A' and B'are rerolled A and B, and there may
also be a further fix-up C' on the side branch. "diff Y^..Y" is similar
to "diff -R W^..W" (which in turn means it is similar to "diff M^..M"),
and "diff A'^..C'" by definition would be similar but different from that,
because it is a rerolled series of the earlier change. There will be a
lot of overlapping changes that result in conflicts. So do not do "revert
of revert" blindly without thinking..
---o---o---o---M---x---x---W---x---x
/ \
---A---B A'--B'--C'
In the history with rebased side branch, W (and M) are behind the merge
base of the updated branch and the tip of the mainline, and they should
merge without the past faulty merge and its revert getting in the way.
To recap, these are two very different scenarios, and they want two very
different resolution strategies:
- If the faulty side branch was fixed by adding corrections on top, then
doing a revert of the previous revert would be the right thing to do.
- If the faulty side branch whose effects were discarded by an earlier
revert of a merge was rebuilt from scratch (i.e. rebasing and fixing,
as you seem to have interpreted), then re-merging the result without
doing anything else fancy would be the right thing to do.
However, there are things to keep in mind when reverting a merge (and
reverting such a revert).
For example, think about what reverting a merge (and then reverting the
revert) does to bisectability. Ignore the fact that the revert of a revert
is undoing it - just think of it as a "single commit that does a lot".
Because that is what it does.
When you have a problem you are chasing down, and you hit a "revert this
merge", what you're hitting is essentially a single commit that contains
all the changes (but obviously in reverse) of all the commits that got
merged. So it's debugging hell, because now you don't have lots of small
changes that you can try to pinpoint which _part_ of it changes.
But does it all work? Sure it does. You can revert a merge, and from a
purely technical angle, git did it very naturally and had no real
troubles. It just considered it a change from "state before merge" to
"state after merge", and that was it. Nothing complicated, nothing odd,
nothing really dangerous. Git will do it without even thinking about it.
So from a technical angle, there's nothing wrong with reverting a merge,
but from a workflow angle it's something that you generally should try to
avoid.
If at all possible, for example, if you find a problem that got merged
into the main tree, rather than revert the merge, try _really_ hard to
bisect the problem down into the branch you merged, and just fix it, or
try to revert the individual commit that caused it.
Yes, it's more complex, and no, it's not always going to work (sometimes
the answer is: "oops, I really shouldn't have merged it, because it wasn't
ready yet, and I really need to undo _all_ of the merge"). So then you
really should revert the merge, but when you want to re-do the merge, you
now need to do it by reverting the revert.

10
Documentation/i18n.txt
View File

@@ -7,11 +7,11 @@ At the core level, git is character encoding agnostic.
to be what lstat(2) and creat(2) accepts. There is no such
thing as pathname encoding translation.
- The contents of the blob objects are uninterpreted sequence
- The contents of the blob objects are uninterpreted sequences
of bytes. There is no encoding translation at the core
level.
- The commit log messages are uninterpreted sequence of non-NUL
- The commit log messages are uninterpreted sequences of non-NUL
bytes.
Although we encourage that the commit log messages are encoded
@@ -37,9 +37,9 @@ of `i18n.commitencoding` in its `encoding` header. This is to
help other people who look at them later. Lack of this header
implies that the commit log message is encoded in UTF-8.
. 'git-log', 'git-show' and friends looks at the `encoding`
header of a commit object, and tries to re-code the log
message into UTF-8 unless otherwise specified. You can
. 'git-log', 'git-show', 'git-blame' and friends look at the
`encoding` header of a commit object, and try to re-code the
log message into UTF-8 unless otherwise specified. You can
specify the desired output encoding with
`i18n.logoutputencoding` in `.git/config` file, like this:
+

18
Documentation/merge-config.txt
View File

@@ -1,6 +1,10 @@
merge.stat::
Whether to print the diffstat between ORIG_HEAD and the merge result
at the end of the merge. True by default.
merge.conflictstyle::
Specify the style in which conflicted hunks are written out to
working tree files upon merge. The default is "merge", which
shows a `<<<<<<<` conflict marker, changes made by one side,
a `=======` marker, changes made by the other side, and then
a `>>>>>>>` marker. An alternate style, "diff3", adds a `|||||||`
marker and the original text before the `=======` marker.
merge.log::
Whether to include summaries of merged commits in newly created
@@ -11,6 +15,10 @@ merge.renameLimit::
during a merge; if not specified, defaults to the value of
diff.renameLimit.
merge.stat::
Whether to print the diffstat between ORIG_HEAD and the merge result
at the end of the merge. True by default.
merge.tool::
Controls which merge resolution program is used by
linkgit:git-mergetool[1]. Valid built-in values are: "kdiff3",
@@ -24,10 +32,10 @@ merge.verbosity::
message if conflicts were detected. Level 1 outputs only
conflicts, 2 outputs conflicts and file changes. Level 5 and
above outputs debugging information. The default is level 2.
Can be overridden by 'GIT_MERGE_VERBOSITY' environment variable.
Can be overridden by the 'GIT_MERGE_VERBOSITY' environment variable.
merge.<driver>.name::
Defines a human readable name for a custom low-level
Defines a human-readable name for a custom low-level
merge driver. See linkgit:gitattributes[5] for details.
merge.<driver>.driver::

10
Documentation/merge-options.txt
View File

@@ -1,10 +1,18 @@
-q::
--quiet::
Operate quietly.
-v::
--verbose::
Be verbose.
--stat::
Show a diffstat at the end of the merge. The diffstat is also
controlled by the configuration option merge.stat.
-n::
--no-stat::
Do not show diffstat at the end of the merge.
Do not show a diffstat at the end of the merge.
--summary::
--no-summary::

7
Documentation/pretty-formats.txt
View File

@@ -30,7 +30,7 @@ This is designed to be as compact as possible.
commit <sha1>
Author: <author>
Date: <author date>
Date: <author date>
<title line>
@@ -49,9 +49,9 @@ This is designed to be as compact as possible.
* 'fuller'
commit <sha1>
Author: <author>
Author: <author>
AuthorDate: <author date>
Commit: <committer>
Commit: <committer>
CommitDate: <committer date>
<title line>
@@ -116,6 +116,7 @@ The placeholders are:
- '%cr': committer date, relative
- '%ct': committer date, UNIX timestamp
- '%ci': committer date, ISO 8601 format
- '%d': ref names, like the --decorate option of linkgit:git-log[1]
- '%e': encoding
- '%s': subject
- '%b': body

123
Documentation/rev-list-options.txt
View File

@@ -174,6 +174,10 @@ endif::git-rev-list[]
Limit the commits output to ones with log message that
matches the specified pattern (regular expression).
--all-match::
Limit the commits output to ones that match all given --grep,
--author and --committer instead of ones that match at least one.
-i::
--regexp-ignore-case::
@@ -218,6 +222,21 @@ endif::git-rev-list[]
Pretend as if all the refs in `$GIT_DIR/refs/` are listed on the
command line as '<commit>'.
--branches::
Pretend as if all the refs in `$GIT_DIR/refs/heads` are listed
on the command line as '<commit>'.
--tags::
Pretend as if all the refs in `$GIT_DIR/refs/tags` are listed
on the command line as '<commit>'.
--remotes::
Pretend as if all the refs in `$GIT_DIR/refs/remotes` are listed
on the command line as '<commit>'.
ifdef::git-rev-list[]
--stdin::
@@ -281,8 +300,52 @@ See also linkgit:git-reflog[1].
History Simplification
~~~~~~~~~~~~~~~~~~~~~~
When optional paths are given, 'git-rev-list' simplifies commits with
various strategies, according to the options you have selected.
Sometimes you are only interested in parts of the history, for example the
commits modifying a particular <path>. But there are two parts of
'History Simplification', one part is selecting the commits and the other
is how to do it, as there are various strategies to simplify the history.
The following options select the commits to be shown:
<paths>::
Commits modifying the given <paths> are selected.
--simplify-by-decoration::
Commits that are referred by some branch or tag are selected.
Note that extra commits can be shown to give a meaningful history.
The following options affect the way the simplification is performed:
Default mode::
Simplifies the history to the simplest history explaining the
final state of the tree. Simplest because it prunes some side
branches if the end result is the same (i.e. merging branches
with the same content)
--full-history::
As the default mode but does not prune some history.
--dense::
Only the selected commits are shown, plus some to have a
meaningful history.
--sparse::
All commits in the simplified history are shown.
--simplify-merges::
Additional option to '--full-history' to remove some needless
merges from the resulting history, as there are no selected
commits contributing to this merge.
A more detailed explanation follows.
Suppose you specified `foo` as the <paths>. We shall call commits
that modify `foo` !TREESAME, and the rest TREESAME. (In a diff
@@ -409,6 +472,56 @@ Note that without '\--full-history', this still simplifies merges: if
one of the parents is TREESAME, we follow only that one, so the other
sides of the merge are never walked.
Finally, there is a fourth simplification mode available:
--simplify-merges::
First, build a history graph in the same way that
'\--full-history' with parent rewriting does (see above).
+
Then simplify each commit `C` to its replacement `C'` in the final
history according to the following rules:
+
--
* Set `C'` to `C`.
+
* Replace each parent `P` of `C'` with its simplification `P'`. In
the process, drop parents that are ancestors of other parents, and
remove duplicates.
+
* If after this parent rewriting, `C'` is a root or merge commit (has
zero or >1 parents), a boundary commit, or !TREESAME, it remains.
Otherwise, it is replaced with its only parent.
--
+
The effect of this is best shown by way of comparing to
'\--full-history' with parent rewriting. The example turns into:
+
-----------------------------------------------------------------------
.-A---M---N---O
/ / /
I B D
\ / /
`---------'
-----------------------------------------------------------------------
+
Note the major differences in `N` and `P` over '\--full-history':
+
--
* `N`'s parent list had `I` removed, because it is an ancestor of the
other parent `M`. Still, `N` remained because it is !TREESAME.
+
* `P`'s parent list similarly had `I` removed. `P` was then
removed completely, because it had one parent and is TREESAME.
--
The '\--simplify-by-decoration' option allows you to view only the
big picture of the topology of the history, by omitting commits
that are not referenced by tags. Commits are marked as !TREESAME
(in other words, kept after history simplification rules described
above) if (1) they are referenced by tags, or (2) they change the
contents of the paths given on the command line. All other
commits are marked as TREESAME (subject to be simplified away).
ifdef::git-rev-list[]
Bisection Helpers
@@ -420,14 +533,14 @@ Limit output to the one commit object which is roughly halfway between
the included and excluded commits. Thus, if
-----------------------------------------------------------------------
$ git-rev-list --bisect foo ^bar ^baz
$ git rev-list --bisect foo ^bar ^baz
-----------------------------------------------------------------------
outputs 'midpoint', the output of the two commands
-----------------------------------------------------------------------
$ git-rev-list foo ^midpoint
$ git-rev-list midpoint ^bar ^baz
$ git rev-list foo ^midpoint
$ git rev-list midpoint ^bar ^baz
-----------------------------------------------------------------------
would be of roughly the same length. Finding the change which

2
Documentation/technical/api-run-command.txt
View File

@@ -30,7 +30,7 @@ Functions
start_command() followed by finish_command(). Takes a pointer
to a `struct child_process` that specifies the details.
`run_command_v_opt`, `run_command_v_opt_cd`, `run_command_v_opt_cd_env`::
`run_command_v_opt`, `run_command_v_opt_cd_env`::
Convenience functions that encapsulate a sequence of
start_command() followed by finish_command(). The argument argv

7
Documentation/technical/api-strbuf.txt
View File

@@ -205,6 +205,13 @@ In order to facilitate caching and to make it possible to give
parameters to the callback, `strbuf_expand()` passes a context pointer,
which can be used by the programmer of the callback as she sees fit.
`strbuf_expand_dict_cb`::
Used as callback for `strbuf_expand()`, expects an array of
struct strbuf_expand_dict_entry as context, i.e. pairs of
placeholder and replacement string. The array needs to be
terminated by an entry with placeholder set to NULL.
`strbuf_addf`::
Add a formatted string to the buffer.

2
Documentation/technical/racy-git.txt
View File

@@ -135,7 +135,7 @@ them, and give the same timestamp to the index file:
This will make all index entries racily clean. The linux-2.6
project, for example, there are over 20,000 files in the working
tree. On my Athron 64X2 3800+, after the above:
tree. On my Athlon 64 X2 3800+, after the above:
$ /usr/bin/time git diff-files
1.68user 0.54system 0:02.22elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k

19
Documentation/urls-remotes.txt
View File

@@ -68,13 +68,22 @@ This file should have the following format:
------------
`<url>` is required; `#<head>` is optional.
When you do not provide a refspec on the command line,
git will use the following refspec, where `<head>` defaults to `master`,
and `<repository>` is the name of this file
you provided in the command line.
Depending on the operation, git will use one of the following
refspecs, if you don't provide one on the command line.
`<branch>` is the name of this file in `$GIT_DIR/branches` and
`<head>` defaults to `master`.
git fetch uses:
------------
refs/heads/<head>:<repository>
refs/heads/<head>:refs/heads/<branch>
------------
git push uses:
------------
HEAD:refs/heads/<head>
------------

37
Documentation/user-manual.txt
View File

@@ -13,17 +13,27 @@ to build and test a particular version of a software project, search for
regressions, and so on.
People needing to do actual development will also want to read
<<Developing-with-git>> and <<sharing-development>>.
<<Developing-With-git>> and <<sharing-development>>.
Further chapters cover more specialized topics.
Comprehensive reference documentation is available through the man
pages. For a command such as "git clone <repo>", just use
pages, or linkgit:git-help[1] command. For example, for the command
"git clone <repo>", you can either use:
------------------------------------------------
$ man git-clone
------------------------------------------------
or:
------------------------------------------------
$ git help clone
------------------------------------------------
With the latter, you can use the manual viewer of your choice; see
linkgit:git-help[1] for more information.
See also <<git-quick-start>> for a brief overview of git commands,
without any explanation.
@@ -389,7 +399,7 @@ 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:git-rev-parse[1].
[[Updating-a-repository-with-git-fetch]]
[[Updating-a-repository-With-git-fetch]]
Updating a repository with git-fetch
------------------------------------
@@ -536,7 +546,7 @@ $ git bisect skip
-------------------------------------------------
In this case, though, git may not eventually be able to tell the first
bad one between some first skipped commits and a latter bad commit.
bad one between some first skipped commits and a later bad commit.
There are also ways to automate the bisecting process if you have a
test script that can tell a good from a bad commit. See
@@ -945,7 +955,7 @@ echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"
and then he just cut-and-pastes the output commands after verifying that
they look OK.
[[Finding-comments-with-given-content]]
[[Finding-comments-With-given-Content]]
Finding commits referencing a file with given content
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -962,7 +972,7 @@ Figuring out why this works is left as an exercise to the (advanced)
student. The linkgit:git-log[1], linkgit:git-diff-tree[1], and
linkgit:git-hash-object[1] man pages may prove helpful.
[[Developing-with-git]]
[[Developing-With-git]]
Developing with git
===================
@@ -1665,7 +1675,7 @@ dangling objects can arise in other situations.
Sharing development with others
===============================
[[getting-updates-with-git-pull]]
[[getting-updates-With-git-pull]]
Getting updates with git-pull
-----------------------------
@@ -1673,7 +1683,7 @@ After you clone a repository and make a few changes of your own, you
may wish to check the original repository for updates and merge them
into your own work.
We have already seen <<Updating-a-repository-with-git-fetch,how to
We have already seen <<Updating-a-repository-With-git-fetch,how to
keep remote tracking branches up to date>> with linkgit:git-fetch[1],
and how to merge two branches. So you can merge in changes from the
original repository's master branch with:
@@ -1784,7 +1794,7 @@ Public git repositories
Another way to submit changes to a project is to tell the maintainer
of that project to pull the changes from your repository using
linkgit:git-pull[1]. In the section "<<getting-updates-with-git-pull,
linkgit:git-pull[1]. In the section "<<getting-updates-With-git-pull,
Getting updates with git-pull>>" we described this as a way to get
updates from the "main" repository, but it works just as well in the
other direction.
@@ -1994,7 +2004,7 @@ $ git push ssh://yourserver.com/~you/proj.git +master
Normally whenever a branch head in a public repository is modified, it
is modified to point to a descendant of the commit that it pointed to
before. By forcing a push in this situation, you break that convention.
(See <<problems-with-rewriting-history>>.)
(See <<problems-With-rewriting-history>>.)
Nevertheless, this is a common practice for people that need a simple
way to publish a work-in-progress patch series, and it is an acceptable
@@ -2563,7 +2573,7 @@ There are numerous other tools, such as StGIT, which exist for the
purpose of maintaining a patch series. These are outside of the scope of
this manual.
[[problems-with-rewriting-history]]
[[problems-With-rewriting-history]]
Problems with rewriting history
-------------------------------
@@ -4356,7 +4366,9 @@ $ git remote show example # get details
* remote example
URL: git://example.com/project.git
Tracked remote branches
master next ...
master
next
...
$ git fetch example # update branches from example
$ git branch -r # list all remote branches
-----------------------------------------------
@@ -4560,4 +4572,3 @@ Alternates, clone -reference, etc.
More on recovery from repository corruption. See:
http://marc.theaimsgroup.com/?l=git&m=117263864820799&w=2
http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2
http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2

22
INSTALL
View File

@@ -6,7 +6,7 @@ will install the git programs in your own ~/bin/ directory. If you want
to do a global install, you can do
$ make prefix=/usr all doc info ;# as yourself
# make prefix=/usr install install-doc install-info ;# as root
# make prefix=/usr install install-doc install-html install-info ;# as root
(or prefix=/usr/local, of course). Just like any program suite
that uses $prefix, the built results have some paths encoded,
@@ -19,7 +19,7 @@ set up install paths (via config.mak.autogen), so you can write instead
$ make configure ;# as yourself
$ ./configure --prefix=/usr ;# as yourself
$ make all doc ;# as yourself
# make install install-doc ;# as root
# make install install-doc install-html;# as root
Issues of note:
@@ -89,13 +89,22 @@ Issues of note:
inclined to install the tools, the default build target
("make all") does _not_ build them.
"make doc" builds documentation in man and html formats; there are
also "make man", "make html" and "make info". Note that "make html"
requires asciidoc, but not xmlto. "make man" (and thus make doc)
requires both.
"make install-doc" installs documentation in man format only; there
are also "make install-man", "make install-html" and "make
install-info".
Building and installing the info file additionally requires
makeinfo and docbook2X. Version 0.8.3 is known to work.
The documentation is written for AsciiDoc 7, but "make
ASCIIDOC8=YesPlease doc" will let you format with AsciiDoc 8.
Alternatively, pre-formatted documentation are available in
Alternatively, pre-formatted documentation is available in
"html" and "man" branches of the git repository itself. For
example, you could:
@@ -117,6 +126,13 @@ Issues of note:
http://www.kernel.org/pub/software/scm/git/docs/
There are also "make quick-install-doc", "make quick-install-man"
and "make quick-install-html" which install preformatted man pages
and html documentation.
This does not require asciidoc/xmlto, but it only works from within
a cloned checkout of git.git with these two extra branches, and will
not work for the maintainer for obvious chicken-and-egg reasons.
It has been reported that docbook-xsl version 1.72 and 1.73 are
buggy; 1.72 misformats manual pages for callouts, and 1.73 needs
the patch in contrib/patches/docbook-xsl-manpages-charmap.patch

116
Makefile
View File

@@ -90,6 +90,8 @@ all::
#
# Define NO_MMAP if you want to avoid mmap.
#
# Define NO_PTHREADS if you do not have or do not want to use Pthreads.
#
# Define NO_PREAD if you have a problem with pread() system call (e.g.
# cygwin.dll before v1.5.22).
#
@@ -124,6 +126,9 @@ all::
# Define USE_STDEV below if you want git to care about the underlying device
# change being considered an inode change from the update-index perspective.
#
# Define NO_ST_BLOCKS_IN_STRUCT_STAT if your platform does not have st_blocks
# field that counts the on-disk footprint in 512-byte blocks.
#
# Define ASCIIDOC8 if you want to format documentation with AsciiDoc 8
#
# Define DOCBOOK_XSL_172 if you want to format man pages with DocBook XSL v1.72.
@@ -161,6 +166,7 @@ uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not')
uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
# CFLAGS and LDFLAGS are for the users to override from the command line.
@@ -226,6 +232,7 @@ INSTALL = /bin/install
RPMBUILD = rpmbuild
TCL_PATH = tclsh
TCLTK_PATH = wish
PTHREAD_LIBS = -lpthread
export TCL_PATH TCLTK_PATH
@@ -291,8 +298,8 @@ PROGRAMS += git-mktag$X
PROGRAMS += git-mktree$X
PROGRAMS += git-pack-redundant$X
PROGRAMS += git-patch-id$X
PROGRAMS += git-receive-pack$X
PROGRAMS += git-send-pack$X
PROGRAMS += git-shell$X
PROGRAMS += git-show-index$X
PROGRAMS += git-unpack-file$X
PROGRAMS += git-update-server-info$X
@@ -313,6 +320,7 @@ BUILT_INS += git-merge-subtree$X
BUILT_INS += git-peek-remote$X
BUILT_INS += git-repo-config$X
BUILT_INS += git-show$X
BUILT_INS += git-stage$X
BUILT_INS += git-status$X
BUILT_INS += git-whatchanged$X
@@ -343,6 +351,7 @@ LIB_H += cache.h
LIB_H += cache-tree.h
LIB_H += commit.h
LIB_H += compat/mingw.h
LIB_H += compat/cygwin.h
LIB_H += csum-file.h
LIB_H += decorate.h
LIB_H += delta.h
@@ -354,6 +363,8 @@ LIB_H += git-compat-util.h
LIB_H += graph.h
LIB_H += grep.h
LIB_H += hash.h
LIB_H += help.h
LIB_H += levenshtein.h
LIB_H += list-objects.h
LIB_H += ll-merge.h
LIB_H += log-tree.h
@@ -383,6 +394,7 @@ LIB_H += transport.h
LIB_H += tree.h
LIB_H += tree-walk.h
LIB_H += unpack-trees.h
LIB_H += userdiff.h
LIB_H += utf8.h
LIB_H += wt-status.h
@@ -429,7 +441,7 @@ LIB_OBJS += grep.o
LIB_OBJS += hash.o
LIB_OBJS += help.o
LIB_OBJS += ident.o
LIB_OBJS += interpolate.o
LIB_OBJS += levenshtein.o
LIB_OBJS += list-objects.o
LIB_OBJS += ll-merge.o
LIB_OBJS += lockfile.o
@@ -437,6 +449,7 @@ LIB_OBJS += log-tree.o
LIB_OBJS += mailmap.o
LIB_OBJS += match-trees.o
LIB_OBJS += merge-file.o
LIB_OBJS += merge-recursive.o
LIB_OBJS += name-hash.o
LIB_OBJS += object.o
LIB_OBJS += pack-check.o
@@ -477,6 +490,7 @@ LIB_OBJS += tree-diff.o
LIB_OBJS += tree.o
LIB_OBJS += tree-walk.o
LIB_OBJS += unpack-trees.o
LIB_OBJS += userdiff.o
LIB_OBJS += usage.o
LIB_OBJS += utf8.o
LIB_OBJS += walker.o
@@ -485,6 +499,7 @@ LIB_OBJS += write_or_die.o
LIB_OBJS += ws.o
LIB_OBJS += wt-status.o
LIB_OBJS += xdiff-interface.o
LIB_OBJS += preload-index.o
BUILTIN_OBJS += builtin-add.o
BUILTIN_OBJS += builtin-annotate.o
@@ -518,6 +533,7 @@ BUILTIN_OBJS += builtin-for-each-ref.o
BUILTIN_OBJS += builtin-fsck.o
BUILTIN_OBJS += builtin-gc.o
BUILTIN_OBJS += builtin-grep.o
BUILTIN_OBJS += builtin-help.o
BUILTIN_OBJS += builtin-init-db.o
BUILTIN_OBJS += builtin-log.o
BUILTIN_OBJS += builtin-ls-files.o
@@ -538,6 +554,7 @@ BUILTIN_OBJS += builtin-prune-packed.o
BUILTIN_OBJS += builtin-prune.o
BUILTIN_OBJS += builtin-push.o
BUILTIN_OBJS += builtin-read-tree.o
BUILTIN_OBJS += builtin-receive-pack.o
BUILTIN_OBJS += builtin-reflog.o
BUILTIN_OBJS += builtin-remote.o
BUILTIN_OBJS += builtin-rerere.o
@@ -575,9 +592,11 @@ EXTLIBS = /mingw/lib/libz.a
ifeq ($(uname_S),Linux)
NO_STRLCPY = YesPlease
THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),GNU/kFreeBSD)
NO_STRLCPY = YesPlease
THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),UnixWare)
CC = cc
@@ -626,8 +645,7 @@ ifeq ($(uname_S),Darwin)
endif
NO_STRLCPY = YesPlease
NO_MEMMEM = YesPlease
COMPAT_CFLAGS += -Icompat/regex
COMPAT_OBJS += compat/regex/regex.o
THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
@@ -637,8 +655,8 @@ ifeq ($(uname_S),SunOS)
NO_MEMMEM = YesPlease
NO_HSTRERROR = YesPlease
NO_MKDTEMP = YesPlease
OLD_ICONV = UnfortunatelyYes
ifeq ($(uname_R),5.8)
NEEDS_LIBICONV = YesPlease
NO_UNSETENV = YesPlease
NO_SETENV = YesPlease
NO_C99_FORMAT = YesPlease
@@ -677,8 +695,12 @@ ifeq ($(uname_S),FreeBSD)
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
COMPAT_CFLAGS += -Icompat/regex
COMPAT_OBJS += compat/regex/regex.o
THREADED_DELTA_SEARCH = YesPlease
ifeq ($(shell expr "$(uname_R)" : '4\.'),2)
PTHREAD_LIBS = -pthread
NO_UINTMAX_T = YesPlease
NO_STRTOUMAX = YesPlease
endif
endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
@@ -686,14 +708,15 @@ ifeq ($(uname_S),OpenBSD)
NEEDS_LIBICONV = YesPlease
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),NetBSD)
ifeq ($(shell expr "$(uname_R)" : '[01]\.'),2)
NEEDS_LIBICONV = YesPlease
endif
BASIC_CFLAGS += -I/usr/pkg/include
BASIC_LDFLAGS += -L/usr/pkg/lib
ALL_LDFLAGS += -Wl,-rpath,/usr/pkg/lib
BASIC_LDFLAGS += -L/usr/pkg/lib $(CC_LD_DYNPATH)/usr/pkg/lib
THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),AIX)
NO_STRCASESTR=YesPlease
@@ -704,8 +727,11 @@ ifeq ($(uname_S),AIX)
INTERNAL_QSORT = UnfortunatelyYes
NEEDS_LIBICONV=YesPlease
BASIC_CFLAGS += -D_LARGE_FILES
COMPAT_CFLAGS += -Icompat/regex
COMPAT_OBJS += compat/regex/regex.o
ifneq ($(shell expr "$(uname_V)" : '[1234]'),1)
THREADED_DELTA_SEARCH = YesPlease
else
NO_PTHREADS = YesPlease
endif
endif
ifeq ($(uname_S),GNU)
# GNU/Hurd
@@ -735,6 +761,9 @@ ifeq ($(uname_S),HP-UX)
NO_SYS_SELECT_H = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
endif
ifneq (,$(findstring CYGWIN,$(uname_S)))
COMPAT_OBJS += compat/cygwin.o
endif
ifneq (,$(findstring MINGW,$(uname_S)))
NO_MMAP = YesPlease
NO_PREAD = YesPlease
@@ -746,6 +775,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
NO_MEMMEM = YesPlease
NO_PTHREADS = YesPlease
NEEDS_LIBICONV = YesPlease
OLD_ICONV = YesPlease
NO_C99_FORMAT = YesPlease
@@ -758,6 +788,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
INTERNAL_QSORT = YesPlease
RUNTIME_PREFIX = YesPlease
NO_POSIX_ONLY_PROGRAMS = YesPlease
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/regex -Icompat/fnmatch
COMPAT_CFLAGS += -DSNPRINTF_SIZE_CORR=1
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
@@ -789,12 +820,14 @@ ifeq ($(uname_S),Darwin)
endif
endif
ifdef NO_R_TO_GCC_LINKER
# Some gcc does not accept and pass -R to the linker to specify
# the runtime dynamic library path.
CC_LD_DYNPATH = -Wl,-rpath=
else
CC_LD_DYNPATH = -R
ifndef CC_LD_DYNPATH
ifdef NO_R_TO_GCC_LINKER
# Some gcc does not accept and pass -R to the linker to specify
# the runtime dynamic library path.
CC_LD_DYNPATH = -Wl,-rpath,
else
CC_LD_DYNPATH = -R
endif
endif
ifdef NO_CURL
@@ -830,7 +863,6 @@ EXTLIBS += -lz
ifndef NO_POSIX_ONLY_PROGRAMS
PROGRAMS += git-daemon$X
PROGRAMS += git-imap-send$X
PROGRAMS += git-shell$X
endif
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
@@ -871,6 +903,9 @@ endif
ifdef NO_D_INO_IN_DIRENT
BASIC_CFLAGS += -DNO_D_INO_IN_DIRENT
endif
ifdef NO_ST_BLOCKS_IN_STRUCT_STAT
BASIC_CFLAGS += -DNO_ST_BLOCKS_IN_STRUCT_STAT
endif
ifdef NO_C99_FORMAT
BASIC_CFLAGS += -DNO_C99_FORMAT
endif
@@ -932,6 +967,9 @@ endif
ifdef NO_IPV6
BASIC_CFLAGS += -DNO_IPV6
endif
ifdef NO_UINTMAX_T
BASIC_CFLAGS += -Duintmax_t=uint32_t
endif
ifdef NO_SOCKADDR_STORAGE
ifdef NO_IPV6
BASIC_CFLAGS += -Dsockaddr_storage=sockaddr_in
@@ -994,9 +1032,15 @@ ifdef RUNTIME_PREFIX
COMPAT_CFLAGS += -DRUNTIME_PREFIX
endif
ifdef NO_PTHREADS
THREADED_DELTA_SEARCH =
BASIC_CFLAGS += -DNO_PTHREADS
else
EXTLIBS += $(PTHREAD_LIBS)
endif
ifdef THREADED_DELTA_SEARCH
BASIC_CFLAGS += -DTHREADED_DELTA_SEARCH
EXTLIBS += -lpthread
LIB_OBJS += thread-utils.o
endif
ifdef DIR_HAS_BSD_GROUP_SEMANTICS
@@ -1109,7 +1153,7 @@ git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
help.o: help.c common-cmds.h GIT-CFLAGS
builtin-help.o: builtin-help.c common-cmds.h GIT-CFLAGS
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) \
'-DGIT_HTML_PATH="$(htmldir_SQ_C)"' \
'-DGIT_MAN_PATH="$(mandir_SQ)"' \
@@ -1237,7 +1281,9 @@ endif
git-%$X: %.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
git-imap-send$X: imap-send.o $(LIB_FILE)
git-imap-send$X: imap-send.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)
http.o http-walker.o http-push.o transport.o: http.h
@@ -1264,6 +1310,12 @@ $(XDIFF_LIB): $(XDIFF_OBJS)
doc:
$(MAKE) -C Documentation all
man:
$(MAKE) -C Documentation man
html:
$(MAKE) -C Documentation html
info:
$(MAKE) -C Documentation info
@@ -1341,7 +1393,16 @@ check-sha1:: test-sha1$X
./test-sha1.sh
check: common-cmds.h
for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
if sparse; \
then \
for i in *.c; \
do \
sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; \
done; \
else \
echo 2>&1 "Did you mean 'make test'?"; \
exit 1; \
fi
remove-dashes:
./fixup-builtins $(BUILT_INS) $(PROGRAMS) $(SCRIPTS)
@@ -1367,7 +1428,7 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'
$(INSTALL) git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
ifndef NO_TCLTK
@@ -1391,6 +1452,9 @@ endif
install-doc:
$(MAKE) -C Documentation install
install-man:
$(MAKE) -C Documentation install-man
install-html:
$(MAKE) -C Documentation install-html
@@ -1400,6 +1464,12 @@ install-info:
quick-install-doc:
$(MAKE) -C Documentation quick-install
quick-install-man:
$(MAKE) -C Documentation quick-install-man
quick-install-html:
$(MAKE) -C Documentation quick-install-html
### Maintainer's dist rules

2
RelNotes
View File

@@ -1 +1 @@
Documentation/RelNotes-1.6.0.3.txt
Documentation/RelNotes-1.6.1.txt

15
abspath.c
View File

@@ -1,5 +1,16 @@
#include "cache.h"
/*
* Do not use this for inspecting *tracked* content. When path is a
* symlink to a directory, we do not want to say it is a directory when
* dealing with tracked content in the working tree.
*/
int is_directory(const char *path)
{
struct stat st;
return (!stat(path, &st) && S_ISDIR(st.st_mode));
}
/* We allow "recursive" symbolic links. Only within reason, though. */
#define MAXDEPTH 5
@@ -17,7 +28,7 @@ const char *make_absolute_path(const char *path)
die ("Too long path: %.*s", 60, path);
while (depth--) {
if (stat(buf, &st) || !S_ISDIR(st.st_mode)) {
if (!is_directory(buf)) {
char *last_slash = strrchr(buf, '/');
if (last_slash) {
*last_slash = '\0';
@@ -53,6 +64,8 @@ const char *make_absolute_path(const char *path)
len = readlink(buf, next_buf, PATH_MAX);
if (len < 0)
die ("Invalid symlink: %s", buf);
if (PATH_MAX <= len)
die("symbolic link too long: %s", buf);
next_buf[len] = '\0';
buf = next_buf;
buf_index = 1 - buf_index;

6
archive-tar.c
View File

@@ -124,11 +124,10 @@ static int write_tar_entry(struct archiver_args *args,
unsigned int mode, void *buffer, unsigned long size)
{
struct ustar_header header;
struct strbuf ext_header;
struct strbuf ext_header = STRBUF_INIT;
int err = 0;
memset(&header, 0, sizeof(header));
strbuf_init(&ext_header, 0);
if (!sha1) {
*header.typeflag = TYPEFLAG_GLOBAL_HEADER;
@@ -211,10 +210,9 @@ static int write_tar_entry(struct archiver_args *args,
static int write_global_extended_header(struct archiver_args *args)
{
const unsigned char *sha1 = args->commit_sha1;
struct strbuf ext_header;
struct strbuf ext_header = STRBUF_INIT;
int err;
strbuf_init(&ext_header, 0);
strbuf_append_ext_header(&ext_header, "comment", sha1_to_hex(sha1), 40);
err = write_tar_entry(args, NULL, NULL, 0, 0, ext_header.buf,
ext_header.len);

10
archive.c
View File

@@ -15,7 +15,7 @@ static char const * const archive_usage[] = {
#define USES_ZLIB_COMPRESSION 1
const struct archiver {
static const struct archiver {
const char *name;
write_archive_fn_t write_archive;
unsigned int flags;
@@ -29,11 +29,10 @@ static void format_subst(const struct commit *commit,
struct strbuf *buf)
{
char *to_free = NULL;
struct strbuf fmt;
struct strbuf fmt = STRBUF_INIT;
if (src == buf->buf)
to_free = strbuf_detach(buf, NULL);
strbuf_init(&fmt, 0);
for (;;) {
const char *b, *c;
@@ -65,10 +64,9 @@ static void *sha1_file_to_archive(const char *path, const unsigned char *sha1,
buffer = read_sha1_file(sha1, type, sizep);
if (buffer && S_ISREG(mode)) {
struct strbuf buf;
struct strbuf buf = STRBUF_INIT;
size_t size = 0;
strbuf_init(&buf, 0);
strbuf_attach(&buf, buffer, *sizep, *sizep + 1);
convert_to_working_tree(path, buf.buf, buf.len, &buf);
if (commit)
@@ -338,5 +336,7 @@ int write_archive(int argc, const char **argv, const char *prefix,
parse_treeish_arg(argv, &args, prefix);
parse_pathspec_arg(argv + 1, &args);
git_config(git_default_config, NULL);
return ar->write_archive(&args);
}

16
arm/sha1.c
View File

@@ -8,9 +8,9 @@
#include <string.h>
#include "sha1.h"
extern void sha_transform(uint32_t *hash, const unsigned char *data, uint32_t *W);
extern void arm_sha_transform(uint32_t *hash, const unsigned char *data, uint32_t *W);
void SHA1_Init(SHA_CTX *c)
void arm_SHA1_Init(arm_SHA_CTX *c)
{
c->len = 0;
c->hash[0] = 0x67452301;
@@ -20,7 +20,7 @@ void SHA1_Init(SHA_CTX *c)
c->hash[4] = 0xc3d2e1f0;
}
void SHA1_Update(SHA_CTX *c, const void *p, unsigned long n)
void arm_SHA1_Update(arm_SHA_CTX *c, const void *p, unsigned long n)
{
uint32_t workspace[80];
unsigned int partial;
@@ -32,12 +32,12 @@ void SHA1_Update(SHA_CTX *c, const void *p, unsigned long n)
if (partial) {
done = 64 - partial;
memcpy(c->buffer + partial, p, done);
sha_transform(c->hash, c->buffer, workspace);
arm_sha_transform(c->hash, c->buffer, workspace);
partial = 0;
} else
done = 0;
while (n >= done + 64) {
sha_transform(c->hash, p + done, workspace);
arm_sha_transform(c->hash, p + done, workspace);
done += 64;
}
} else
@@ -46,7 +46,7 @@ void SHA1_Update(SHA_CTX *c, const void *p, unsigned long n)
memcpy(c->buffer + partial, p + done, n - done);
}
void SHA1_Final(unsigned char *hash, SHA_CTX *c)
void arm_SHA1_Final(unsigned char *hash, arm_SHA_CTX *c)
{
uint64_t bitlen;
uint32_t bitlen_hi, bitlen_lo;
@@ -57,7 +57,7 @@ void SHA1_Final(unsigned char *hash, SHA_CTX *c)
bitlen = c->len << 3;
offset = c->len & 0x3f;
padlen = ((offset < 56) ? 56 : (64 + 56)) - offset;
SHA1_Update(c, padding, padlen);
arm_SHA1_Update(c, padding, padlen);
bitlen_hi = bitlen >> 32;
bitlen_lo = bitlen & 0xffffffff;
@@ -69,7 +69,7 @@ void SHA1_Final(unsigned char *hash, SHA_CTX *c)
bits[5] = bitlen_lo >> 16;
bits[6] = bitlen_lo >> 8;
bits[7] = bitlen_lo;
SHA1_Update(c, bits, 8);
arm_SHA1_Update(c, bits, 8);
for (i = 0; i < 5; i++) {
uint32_t v = c->hash[i];

15
arm/sha1.h
View File

@@ -7,12 +7,17 @@
#include <stdint.h>
typedef struct sha_context {
typedef struct {
uint64_t len;
uint32_t hash[5];
unsigned char buffer[64];
} SHA_CTX;
} arm_SHA_CTX;
void SHA1_Init(SHA_CTX *c);
void SHA1_Update(SHA_CTX *c, const void *p, unsigned long n);
void SHA1_Final(unsigned char *hash, SHA_CTX *c);
void arm_SHA1_Init(arm_SHA_CTX *c);
void arm_SHA1_Update(arm_SHA_CTX *c, const void *p, unsigned long n);
void arm_SHA1_Final(unsigned char *hash, arm_SHA_CTX *c);
#define git_SHA_CTX arm_SHA_CTX
#define git_SHA1_Init arm_SHA1_Init
#define git_SHA1_Update arm_SHA1_Update
#define git_SHA1_Final arm_SHA1_Final

4
arm/sha1_arm.S
View File

@@ -10,7 +10,7 @@
*/
.text
.globl sha_transform
.globl arm_sha_transform
/*
* void sha_transform(uint32_t *hash, const unsigned char *data, uint32_t *W);
@@ -18,7 +18,7 @@
* note: the "data" pointer may be unaligned.
*/
sha_transform:
arm_sha_transform:
stmfd sp!, {r4 - r8, lr}

Some files were not shown because too many files have changed in this diff Show More