зеркало из https://github.com/microsoft/git.git
Merge branch 'master' of git://repo.or.cz/alt-git into jn/autodep
* 'master' of git://repo.or.cz/alt-git: (384 commits) am: fix patch format detection for Thunderbird "Save As" emails t0022: replace non-portable literal CR tests: consolidate CR removal/addition functions commit-tree: remove unused #define t5541-http-push: make grep expression check for one line only rebase: replace antiquated sed invocation Add test-run-command to .gitignore git_connect: use use_shell instead of explicit "sh", "-c" gitweb.js: Workaround for IE8 bug Make test numbers unique Windows: Remove dependency on pthreadGC2.dll Documentation: move away misplaced 'push --upstream' description Documentation: add missing :: in config.txt pull: re-fix command line generation Documentation: merge: use MERGE_HEAD to refer to the remote branch Documentation: simplify How Merge Works Documentation: merge: add a section about fast-forward Documentation: emphasize when git merge terminates early Documentation: merge: add an overview Documentation: merge: move merge strategy list to end ... Conflicts: Makefile
This commit is contained in:
Jonathan Nieder
Коммит
225f78c817
|
|
@ -1,2 +1,3 @@
|
|||
* whitespace=!indent,trail,space
|
||||
*.[ch] whitespace=indent,trail,space
|
||||
*.sh whitespace=indent,trail,space
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
/GIT-CFLAGS
|
||||
/GIT-GUI-VARS
|
||||
/GIT-VERSION-FILE
|
||||
/bin-wrappers/
|
||||
/git
|
||||
/git-add
|
||||
/git-add--interactive
|
||||
|
|
@ -107,6 +108,10 @@
|
|||
/git-relink
|
||||
/git-remote
|
||||
/git-remote-curl
|
||||
/git-remote-http
|
||||
/git-remote-https
|
||||
/git-remote-ftp
|
||||
/git-remote-ftps
|
||||
/git-repack
|
||||
/git-replace
|
||||
/git-repo-config
|
||||
|
|
@ -157,9 +162,11 @@
|
|||
/test-delta
|
||||
/test-dump-cache-tree
|
||||
/test-genrandom
|
||||
/test-index-version
|
||||
/test-match-trees
|
||||
/test-parse-options
|
||||
/test-path-utils
|
||||
/test-run-command
|
||||
/test-sha1
|
||||
/test-sigchain
|
||||
/common-cmds.h
|
||||
|
|
|
|||
25
COPYING
25
COPYING
|
|
@ -22,8 +22,8 @@
|
|||
GNU GENERAL PUBLIC LICENSE
|
||||
Version 2, June 1991
|
||||
|
||||
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
|
||||
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
||||
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
|
||||
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ software--to make sure the software is free for all its users. This
|
|||
General Public License applies to most of the Free Software
|
||||
Foundation's software and to any other program whose authors commit to
|
||||
using it. (Some other Free Software Foundation software is covered by
|
||||
the GNU Library General Public License instead.) You can apply it to
|
||||
the GNU Lesser General Public License instead.) You can apply it to
|
||||
your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
|
|
@ -76,7 +76,7 @@ patent must be licensed for everyone's free use or not licensed at all.
|
|||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
|
||||
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
|
||||
|
|
@ -131,7 +131,7 @@ above, provided that you also meet all of these conditions:
|
|||
License. (Exception: if the Program itself is interactive but
|
||||
does not normally print such an announcement, your work based on
|
||||
the Program is not required to print an announcement.)
|
||||
|
||||
|
||||
These requirements apply to the modified work as a whole. If
|
||||
identifiable sections of that work are not derived from the Program,
|
||||
and can be reasonably considered independent and separate works in
|
||||
|
|
@ -189,7 +189,7 @@ access to copy from a designated place, then offering equivalent
|
|||
access to copy the source code from the same place counts as
|
||||
distribution of the source code, even though third parties are not
|
||||
compelled to copy the source along with the object code.
|
||||
|
||||
|
||||
4. You may not copy, modify, sublicense, or distribute the Program
|
||||
except as expressly provided under this License. Any attempt
|
||||
otherwise to copy, modify, sublicense or distribute the Program is
|
||||
|
|
@ -246,7 +246,7 @@ impose that choice.
|
|||
|
||||
This section is intended to make thoroughly clear what is believed to
|
||||
be a consequence of the rest of this License.
|
||||
|
||||
|
||||
8. If the distribution and/or use of the Program is restricted in
|
||||
certain countries either by patents or by copyrighted interfaces, the
|
||||
original copyright holder who places the Program under this License
|
||||
|
|
@ -299,7 +299,7 @@ PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
|
|||
POSSIBILITY OF SUCH DAMAGES.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
|
||||
How to Apply These Terms to Your New Programs
|
||||
|
||||
If you develop a new program, and you want it to be of the greatest
|
||||
|
|
@ -324,10 +324,9 @@ the "copyright" line and a pointer to where the full notice is found.
|
|||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, write to the Free Software
|
||||
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
||||
|
||||
You should have received a copy of the GNU General Public License along
|
||||
with this program; if not, write to the Free Software Foundation, Inc.,
|
||||
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
||||
|
||||
Also add information on how to contact you by electronic and paper mail.
|
||||
|
||||
|
|
@ -357,5 +356,5 @@ necessary. Here is a sample; alter the names:
|
|||
This General Public License does not permit incorporating your program into
|
||||
proprietary programs. If your program is a subroutine library, you may
|
||||
consider it more useful to permit linking proprietary applications with the
|
||||
library. If this is what you want to do, use the GNU Library General
|
||||
library. If this is what you want to do, use the GNU Lesser General
|
||||
Public License instead of this License.
|
||||
|
|
|
|||
|
|
@ -204,7 +204,7 @@ install-pdf: pdf
|
|||
install-html: html
|
||||
'$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir)
|
||||
|
||||
../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
|
||||
../GIT-VERSION-FILE: FORCE
|
||||
$(QUIET_SUBDIR0)../ $(QUIET_SUBDIR1) GIT-VERSION-FILE
|
||||
|
||||
-include ../GIT-VERSION-FILE
|
||||
|
|
@ -337,4 +337,4 @@ quick-install-man:
|
|||
quick-install-html:
|
||||
'$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir)
|
||||
|
||||
.PHONY: .FORCE-GIT-VERSION-FILE
|
||||
.PHONY: FORCE
|
||||
|
|
|
|||
|
|
@ -0,0 +1,191 @@
|
|||
Git v1.7.0 Release Notes
|
||||
========================
|
||||
|
||||
Notes on behaviour change
|
||||
-------------------------
|
||||
|
||||
* "git push" into a branch that is currently checked out (i.e. pointed by
|
||||
HEAD in a repository that is not bare) is refused by default.
|
||||
|
||||
Similarly, "git push $there :$killed" to delete the branch $killed
|
||||
in a remote repository $there, when $killed branch is the current
|
||||
branch pointed at by its HEAD, will be refused by default.
|
||||
|
||||
Setting the configuration variables receive.denyCurrentBranch and
|
||||
receive.denyDeleteCurrent to 'ignore' in the receiving repository
|
||||
can be used to override these safety features.
|
||||
|
||||
* "git send-email" does not make deep threads by default when sending a
|
||||
patch series with more than two messages. All messages will be sent
|
||||
as a reply to the first message, i.e. cover letter.
|
||||
|
||||
It has been possible to configure send-email to send "shallow thread"
|
||||
by setting sendemail.chainreplyto configuration variable to false. The
|
||||
only thing this release does is to change the default when you haven't
|
||||
configured that variable.
|
||||
|
||||
* "git status" is not "git commit --dry-run" anymore. This change does
|
||||
not affect you if you run the command without pathspec.
|
||||
|
||||
* "git diff" traditionally treated various "ignore whitespace" options
|
||||
only as a way to filter the patch output. "git diff --exit-code -b"
|
||||
exited with non-zero status even if all changes were about changing the
|
||||
ammount of whitespace and nothing else. and "git diff -b" showed the
|
||||
"diff --git" header line for such a change without patch text.
|
||||
|
||||
In this release, the "ignore whitespaces" options affect the semantics
|
||||
of the diff operation. A change that does not affect anything but
|
||||
whitespaces is reported with zero exit status when run with
|
||||
--exit-code, and there is no "diff --git" header for such a change.
|
||||
|
||||
|
||||
Updates since v1.6.6
|
||||
--------------------
|
||||
|
||||
(subsystems)
|
||||
|
||||
* "git fast-import" updates; adds "option" and "feature" to detect the
|
||||
mismatch between fast-import and the frontends that produce the input
|
||||
stream.
|
||||
|
||||
(portability)
|
||||
|
||||
* Some more MSVC portability patches for msysgit port.
|
||||
|
||||
* Minimum Pthreads emulation for msysgit port.
|
||||
|
||||
(performance)
|
||||
|
||||
* More performance improvement patches for msysgit port.
|
||||
|
||||
(usability, bells and whistles)
|
||||
|
||||
* More commands learned "--quiet" and "--[no-]progress" options.
|
||||
|
||||
* Various commands given by the end user (e.g. diff.type.textconv,
|
||||
and GIT_EDITOR) can be specified with command line arguments. E.g. it
|
||||
is now possible to say "[diff "utf8doc"] textconv = nkf -w".
|
||||
|
||||
* "sparse checkout" feature allows only part of the work tree to be
|
||||
checked out.
|
||||
|
||||
* HTTP transfer can use authentication scheme other than basic
|
||||
(i.e./e.g. digest).
|
||||
|
||||
* Switching from a version of superproject that used to have a submodule
|
||||
to another version of superproject that no longer has it did not remove
|
||||
the submodule directory when it should (namely, when you are not
|
||||
interested in the submodule at all and didn't clone/checkout).
|
||||
|
||||
* A new attribute conflict-marker-size can be used to change the size of
|
||||
the conflict markers from the default 7; this is useful when tracked
|
||||
contents (e.g. git-merge documentation) have strings that resemble the
|
||||
conflict markers.
|
||||
|
||||
* A new syntax "<branch>@{upstream}" can be used on the command line to
|
||||
substitute the name of the "upstream" of the branch. Missing branch
|
||||
defaults to the current branch, so "git fetch && git merge @{upstream}"
|
||||
will be equivalent to "git pull".
|
||||
|
||||
* "git branch --set-upstream" can be used to update the (surprise!) upstream
|
||||
i.e. where the branch is supposed to pull and merge from (or rebase onto).
|
||||
|
||||
* "git checkout A...B" is a way to detach HEAD at the merge base between
|
||||
A and B.
|
||||
|
||||
* "git checkout -m path" to reset the work tree file back into the
|
||||
conflicted state works even when you already ran "git add path" and
|
||||
resolved the conflicts.
|
||||
|
||||
* "git commit --date='<date>'" can be used to override the author date
|
||||
just like "git commit --author='<name> <email>'" can be used to
|
||||
override the author identity.
|
||||
|
||||
* "git commit --no-status" can be used to omit the listing of the index
|
||||
and the work tree status in the editor used to prepare the log message.
|
||||
|
||||
* "git commit" warns a bit more aggressively until you configure user.email,
|
||||
whose default value almost always is not (and fundamentally cannot be)
|
||||
what you want.
|
||||
|
||||
* "git difftool" has been extended to make it easier to integrate it
|
||||
with gitk.
|
||||
|
||||
* "git fetch --all" can now be used in place of "git remote update".
|
||||
|
||||
* "git grep" does not rely on external grep anymore.
|
||||
|
||||
* "git grep" learned "--no-index" option, to search inside contents that
|
||||
are not managed by git.
|
||||
|
||||
* "git log" and friends learned "--glob=heads/*" syntax that is a more
|
||||
flexible way to complement "--branches/--tags/--remotes".
|
||||
|
||||
* "git merge" learned to pass options specific to strategy-backends. E.g.
|
||||
|
||||
- "git merge -Xsubtree=path/to/directory" can be used to tell the subtree
|
||||
strategy how much to shift the trees explicitly.
|
||||
|
||||
- "git merge -Xtheirs" can be used to auto-merge as much as possible,
|
||||
while discarding your own changes and taking merged version in
|
||||
conflicted regions.
|
||||
|
||||
* "git push" learned "git push origin --delete branch", a syntactic sugar
|
||||
for "git push origin :branch".
|
||||
|
||||
* "git push" learned "git push --set-upstream origin forker:forkee" that
|
||||
lets you configure your "forker" branch to later pull from "forkee"
|
||||
branch at "origin".
|
||||
|
||||
* "git rebase --onto A...B" means the history is replayed on top of the
|
||||
merge base between A and B.
|
||||
|
||||
* "git rebase -i" learned new action "fixup", that squashes the change
|
||||
but does not affect existing log message.
|
||||
|
||||
* "git rebase -i" also learned --autosquash option, that is useful
|
||||
together with the new "fixup" action.
|
||||
|
||||
* "git remote" learned set-url subcommand, to update (surprise!) url
|
||||
for an existing remote nickname.
|
||||
|
||||
* "git rerere" learned "forget path" subcommand. Together with "git
|
||||
checkout -m path" it will be useful when you recorded a wrong
|
||||
resolution.
|
||||
|
||||
* Use of "git reset --merge" has become easier when resetting away a
|
||||
conflicted mess left in the work tree.
|
||||
|
||||
* "git rerere" had rerere.autoupdate configuration but there was no way
|
||||
to countermand it from the command line; --no-rerere-autoupdate option
|
||||
given to "merge", "revert", etc. fixes this.
|
||||
|
||||
* "git status" learned "-s(hort)" output format.
|
||||
|
||||
(developers)
|
||||
|
||||
* The infrastructure to build foreign SCM interface has been updated.
|
||||
|
||||
* Many more commands are now built-in.
|
||||
|
||||
Fixes since v1.6.6
|
||||
------------------
|
||||
|
||||
All of the fixes in v1.6.6.X maintenance series are included in this
|
||||
release, unless otherwise noted.
|
||||
|
||||
* "git branch -d branch" used to refuse deleting the branch even when
|
||||
the branch is fully merged to its upstream branch if it is not merged
|
||||
to the current branch. It now deletes it in such a case.
|
||||
|
||||
* When "git diff" is asked to compare the work tree with something,
|
||||
it used to consider that a checked-out submodule with uncommitted
|
||||
changes is not modified; this could cause people to forget committing
|
||||
these changes in the submodule before committing in the superproject.
|
||||
It now considers such a change as a modification.
|
||||
|
||||
--
|
||||
exec >/var/tmp/1
|
||||
O=v1.6.6.1-434-g3521c1b
|
||||
echo O=$(git describe master)
|
||||
git shortlog --no-merges $O..master ^maint
|
||||
|
|
@ -64,7 +64,7 @@ The values following the equals sign in variable assign are all either
|
|||
a string, an integer, or a boolean. Boolean values may be given as yes/no,
|
||||
0/1, true/false or on/off. Case is not significant in boolean values, when
|
||||
converting value to the canonical form using '--bool' type specifier;
|
||||
'git-config' will ensure that the output is "true" or "false".
|
||||
'git config' will ensure that the output is "true" or "false".
|
||||
|
||||
String values may be entirely or partially enclosed in double quotes.
|
||||
You need to enclose variable values in double quotes if you want to
|
||||
|
|
@ -130,6 +130,14 @@ advice.*::
|
|||
Advice shown when linkgit:git-merge[1] refuses to
|
||||
merge to avoid overwritting local changes.
|
||||
Default: true.
|
||||
resolveConflict::
|
||||
Advices shown by various commands when conflicts
|
||||
prevent the operation from being performed.
|
||||
Default: true.
|
||||
implicitIdentity::
|
||||
Advice on how to set your identity configuration when
|
||||
your information is guessed from the system username and
|
||||
domain name. Default: true.
|
||||
--
|
||||
|
||||
core.fileMode::
|
||||
|
|
@ -442,8 +450,8 @@ core.pager::
|
|||
|
||||
core.whitespace::
|
||||
A comma separated list of common whitespace problems to
|
||||
notice. 'git-diff' will use `color.diff.whitespace` to
|
||||
highlight them, and 'git-apply --whitespace=error' will
|
||||
notice. 'git diff' will use `color.diff.whitespace` to
|
||||
highlight them, and 'git apply --whitespace=error' will
|
||||
consider them as errors. You can prefix `-` to disable
|
||||
any of them (e.g. `-trailing-space`):
|
||||
+
|
||||
|
|
@ -502,8 +510,12 @@ notes should be printed.
|
|||
This setting defaults to "refs/notes/commits", and can be overridden by
|
||||
the `GIT_NOTES_REF` environment variable.
|
||||
|
||||
core.sparseCheckout::
|
||||
Enable "sparse checkout" feature. See section "Sparse checkout" in
|
||||
linkgit:git-read-tree[1] for more information.
|
||||
|
||||
add.ignore-errors::
|
||||
Tells 'git-add' to continue adding files when some files cannot be
|
||||
Tells 'git add' to continue adding files when some files cannot be
|
||||
added due to indexing errors. Equivalent to the '--ignore-errors'
|
||||
option of linkgit:git-add[1].
|
||||
|
||||
|
|
@ -525,19 +537,19 @@ executed from the top-level directory of a repository, which may
|
|||
not necessarily be the current directory.
|
||||
|
||||
apply.ignorewhitespace::
|
||||
When set to 'change', tells 'git-apply' to ignore changes in
|
||||
When set to 'change', tells 'git apply' to ignore changes in
|
||||
whitespace, in the same way as the '--ignore-space-change'
|
||||
option.
|
||||
When set to one of: no, none, never, false tells 'git-apply' to
|
||||
When set to one of: no, none, never, false tells 'git apply' to
|
||||
respect all whitespace differences.
|
||||
See linkgit:git-apply[1].
|
||||
|
||||
apply.whitespace::
|
||||
Tells 'git-apply' how to handle whitespaces, in the same way
|
||||
Tells 'git apply' how to handle whitespaces, in the same way
|
||||
as the '--whitespace' option. See linkgit:git-apply[1].
|
||||
|
||||
branch.autosetupmerge::
|
||||
Tells 'git-branch' and 'git-checkout' to set up new branches
|
||||
Tells 'git branch' and 'git checkout' to set up new branches
|
||||
so that linkgit:git-pull[1] will appropriately merge from the
|
||||
starting point branch. Note that even if this option is not set,
|
||||
this behavior can be chosen per-branch using the `--track`
|
||||
|
|
@ -548,7 +560,7 @@ branch.autosetupmerge::
|
|||
branch. This option defaults to true.
|
||||
|
||||
branch.autosetuprebase::
|
||||
When a new branch is created with 'git-branch' or 'git-checkout'
|
||||
When a new branch is created with 'git branch' or 'git checkout'
|
||||
that tracks another branch, this variable tells git to set
|
||||
up pull to rebase instead of merge (see "branch.<name>.rebase").
|
||||
When `never`, rebase is never automatically set to true.
|
||||
|
|
@ -563,24 +575,24 @@ branch.autosetuprebase::
|
|||
This option defaults to never.
|
||||
|
||||
branch.<name>.remote::
|
||||
When in branch <name>, it tells 'git-fetch' and 'git-push' which
|
||||
When in branch <name>, it tells 'git fetch' and 'git push' which
|
||||
remote to fetch from/push to. It defaults to `origin` if no remote is
|
||||
configured. `origin` is also used if you are not on any branch.
|
||||
|
||||
branch.<name>.merge::
|
||||
Defines, together with branch.<name>.remote, the upstream branch
|
||||
for the given branch. It tells 'git-fetch'/'git-pull' which
|
||||
branch to merge and can also affect 'git-push' (see push.default).
|
||||
When in branch <name>, it tells 'git-fetch' the default
|
||||
for the given branch. It tells 'git fetch'/'git pull' which
|
||||
branch to merge and can also affect 'git push' (see push.default).
|
||||
When in branch <name>, it tells 'git fetch' the default
|
||||
refspec to be marked for merging in FETCH_HEAD. The value is
|
||||
handled like the remote part of a refspec, and must match a
|
||||
ref which is fetched from the remote given by
|
||||
"branch.<name>.remote".
|
||||
The merge information is used by 'git-pull' (which at first calls
|
||||
'git-fetch') to lookup the default branch for merging. Without
|
||||
this option, 'git-pull' defaults to merge the first refspec fetched.
|
||||
The merge information is used by 'git pull' (which at first calls
|
||||
'git fetch') to lookup the default branch for merging. Without
|
||||
this option, 'git pull' defaults to merge the first refspec fetched.
|
||||
Specify multiple values to get an octopus merge.
|
||||
If you wish to setup 'git-pull' so that it merges into <name> from
|
||||
If you wish to setup 'git pull' so that it merges into <name> from
|
||||
another branch in the local repository, you can point
|
||||
branch.<name>.merge to the desired branch, and use the special setting
|
||||
`.` (a period) for branch.<name>.remote.
|
||||
|
|
@ -652,14 +664,6 @@ color.grep::
|
|||
`never`), never. When set to `true` or `auto`, use color only
|
||||
when the output is written to the terminal. Defaults to `false`.
|
||||
|
||||
color.grep.external::
|
||||
The string value of this variable is passed to an external 'grep'
|
||||
command as a command line option if match highlighting is turned
|
||||
on. If set to an empty string, no option is passed at all,
|
||||
turning off coloring for external 'grep' calls; this is the default.
|
||||
For GNU grep, set it to `--color=always` to highlight matches even
|
||||
when a pager is used.
|
||||
|
||||
color.grep.match::
|
||||
Use customized color for matches. The value of this variable
|
||||
may be specified as in color.branch.<slot>. It is passed using
|
||||
|
|
@ -673,7 +677,7 @@ color.interactive::
|
|||
colors only when the output is to the terminal. Defaults to false.
|
||||
|
||||
color.interactive.<slot>::
|
||||
Use customized color for 'git-add --interactive'
|
||||
Use customized color for 'git add --interactive'
|
||||
output. `<slot>` may be `prompt`, `header`, `help` or `error`, for
|
||||
four distinct types of normal output from interactive
|
||||
commands. The values of these variables may be specified as
|
||||
|
|
@ -712,20 +716,25 @@ color.ui::
|
|||
terminal. When more specific variables of color.* are set, they always
|
||||
take precedence over this setting. Defaults to false.
|
||||
|
||||
commit.status::
|
||||
A boolean to enable/disable inclusion of status information in the
|
||||
commit message template when using an editor to prepare the commit
|
||||
message. Defaults to true.
|
||||
|
||||
commit.template::
|
||||
Specify a file to use as the template for new commit messages.
|
||||
"{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the
|
||||
specified user's home directory.
|
||||
|
||||
diff.autorefreshindex::
|
||||
When using 'git-diff' to compare with work tree
|
||||
When using 'git diff' to compare with work tree
|
||||
files, do not consider stat-only change as changed.
|
||||
Instead, silently run `git update-index --refresh` to
|
||||
update the cached stat information for paths whose
|
||||
contents in the work tree match the contents in the
|
||||
index. This option defaults to true. Note that this
|
||||
affects only 'git-diff' Porcelain, and not lower level
|
||||
'diff' commands such as 'git-diff-files'.
|
||||
affects only 'git diff' Porcelain, and not lower level
|
||||
'diff' commands such as 'git diff-files'.
|
||||
|
||||
diff.external::
|
||||
If this config variable is set, diff generation is not
|
||||
|
|
@ -737,24 +746,24 @@ diff.external::
|
|||
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
|
||||
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';;
|
||||
`git diff`;;
|
||||
compares the (i)ndex and the (w)ork tree;
|
||||
'git-diff HEAD';;
|
||||
`git diff HEAD`;;
|
||||
compares a (c)ommit and the (w)ork tree;
|
||||
'git diff --cached';;
|
||||
`git diff --cached`;;
|
||||
compares a (c)ommit and the (i)ndex;
|
||||
'git-diff HEAD:file1 file2';;
|
||||
`git diff HEAD:file1 file2`;;
|
||||
compares an (o)bject and a (w)ork tree entity;
|
||||
'git diff --no-index a b';;
|
||||
`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'.
|
||||
detection; equivalent to the 'git diff' option '-l'.
|
||||
|
||||
diff.renames::
|
||||
Tells git to detect renames. If set to any boolean value, it
|
||||
|
|
@ -840,7 +849,7 @@ format.pretty::
|
|||
linkgit:git-whatchanged[1].
|
||||
|
||||
format.thread::
|
||||
The default threading style for 'git-format-patch'. Can be
|
||||
The default threading style for 'git format-patch'. Can be
|
||||
a boolean value, or `shallow` or `deep`. `shallow` threading
|
||||
makes every mail a reply to the head of the series,
|
||||
where the head is chosen from the cover letter, the
|
||||
|
|
@ -858,7 +867,7 @@ format.signoff::
|
|||
|
||||
gc.aggressiveWindow::
|
||||
The window size parameter used in the delta compression
|
||||
algorithm used by 'git-gc --aggressive'. This defaults
|
||||
algorithm used by 'git gc --aggressive'. This defaults
|
||||
to 10.
|
||||
|
||||
gc.auto::
|
||||
|
|
@ -878,33 +887,33 @@ gc.packrefs::
|
|||
Running `git pack-refs` in a repository renders it
|
||||
unclonable by Git versions prior to 1.5.1.2 over dumb
|
||||
transports such as HTTP. This variable determines whether
|
||||
'git gc' runs `git pack-refs`. This can be set to "nobare"
|
||||
'git gc' runs `git pack-refs`. This can be set to `nobare`
|
||||
to enable it within all non-bare repos or it can be set to a
|
||||
boolean value. The default is `true`.
|
||||
|
||||
gc.pruneexpire::
|
||||
When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.
|
||||
When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'.
|
||||
Override the grace period with this config variable. The value
|
||||
"now" may be used to disable this grace period and always prune
|
||||
unreachable objects immediately.
|
||||
|
||||
gc.reflogexpire::
|
||||
'git-reflog expire' removes reflog entries older than
|
||||
'git reflog expire' removes reflog entries older than
|
||||
this time; defaults to 90 days.
|
||||
|
||||
gc.reflogexpireunreachable::
|
||||
'git-reflog expire' removes reflog entries older than
|
||||
'git reflog expire' removes reflog entries older than
|
||||
this time and are not reachable from the current tip;
|
||||
defaults to 30 days.
|
||||
|
||||
gc.rerereresolved::
|
||||
Records of conflicted merge you resolved earlier are
|
||||
kept for this many days when 'git-rerere gc' is run.
|
||||
kept for this many days when 'git rerere gc' is run.
|
||||
The default is 60 days. See linkgit:git-rerere[1].
|
||||
|
||||
gc.rerereunresolved::
|
||||
Records of conflicted merge you have not resolved are
|
||||
kept for this many days when 'git-rerere gc' is run.
|
||||
kept for this many days when 'git rerere gc' is run.
|
||||
The default is 15 days. See linkgit:git-rerere[1].
|
||||
|
||||
gitcvs.commitmsgannotation::
|
||||
|
|
@ -1012,7 +1021,7 @@ gui.spellingdictionary::
|
|||
off.
|
||||
|
||||
gui.fastcopyblame::
|
||||
If true, 'git gui blame' uses '-C' instead of '-C -C' for original
|
||||
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.
|
||||
|
||||
|
|
@ -1136,6 +1145,12 @@ http.maxRequests::
|
|||
How many HTTP requests to launch in parallel. Can be overridden
|
||||
by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5.
|
||||
|
||||
http.minSessions::
|
||||
The number of curl sessions (counted across slots) to be kept across
|
||||
requests. They will not be ended with curl_easy_cleanup() until
|
||||
http_cleanup() is invoked. If USE_CURL_MULTI is not defined, this
|
||||
value will be capped at 1. Defaults to 1.
|
||||
|
||||
http.postBuffer::
|
||||
Maximum size in bytes of the buffer used by smart HTTP
|
||||
transports when POSTing data to the remote system.
|
||||
|
|
@ -1165,7 +1180,7 @@ i18n.commitEncoding::
|
|||
|
||||
i18n.logOutputEncoding::
|
||||
Character encoding the commit messages are converted to when
|
||||
running 'git-log' and friends.
|
||||
running 'git log' and friends.
|
||||
|
||||
imap::
|
||||
The configuration variables in the 'imap' section are described
|
||||
|
|
@ -1199,7 +1214,7 @@ interactive.singlekey::
|
|||
|
||||
log.date::
|
||||
Set default date-time mode for the log command. Setting log.date
|
||||
value is similar to using 'git-log'\'s --date option. The value is one of the
|
||||
value is similar to using 'git log'\'s --date option. The value is one of the
|
||||
following alternatives: {relative,local,default,iso,rfc,short}.
|
||||
See linkgit:git-log[1].
|
||||
|
||||
|
|
@ -1465,6 +1480,10 @@ remote.<name>.tagopt::
|
|||
Setting this value to \--no-tags disables automatic tag following when
|
||||
fetching from remote <name>
|
||||
|
||||
remote.<name>.vcs::
|
||||
Setting this to a value <vcs> will cause git to interact with
|
||||
the remote with the git-remote-<vcs> helper.
|
||||
|
||||
remotes.<group>::
|
||||
The list of remotes which are fetched by "git remote update
|
||||
<group>". See linkgit:git-remote[1].
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
DATE FORMATS
|
||||
------------
|
||||
|
||||
The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables
|
||||
ifdef::git-commit[]
|
||||
and the `--date` option
|
||||
endif::git-commit[]
|
||||
support the following date formats:
|
||||
|
||||
Git internal format::
|
||||
It is `<unix timestamp> <timezone offset>`, where `<unix
|
||||
timestamp>` is the number of seconds since the UNIX epoch.
|
||||
`<timezone offset>` is a positive or negative offset from UTC.
|
||||
For example CET (which is 2 hours ahead UTC) is `+0200`.
|
||||
|
||||
RFC 2822::
|
||||
The standard email format as described by RFC 2822, for example
|
||||
`Thu, 07 Apr 2005 22:13:13 +0200`.
|
||||
|
||||
ISO 8601::
|
||||
Time and date specified by the ISO 8601 standard, for example
|
||||
`2005-04-07T22:13:13`. The parser accepts a space instead of the
|
||||
`T` character as well.
|
||||
+
|
||||
NOTE: In addition, the date part is accepted in the following formats:
|
||||
`YYYY.MM.DD`, `MM/DD/YYYY` and `DD.MM.YYYY`.
|
||||
|
|
@ -19,7 +19,7 @@ endif::git-pull[]
|
|||
|
||||
-f::
|
||||
--force::
|
||||
When 'git-fetch' is used with `<rbranch>:<lbranch>`
|
||||
When 'git fetch' is used with `<rbranch>:<lbranch>`
|
||||
refspec, it refuses to update the local branch
|
||||
`<lbranch>` unless the remote branch `<rbranch>` it
|
||||
fetches is a descendant of `<lbranch>`. This option
|
||||
|
|
@ -61,16 +61,16 @@ endif::git-pull[]
|
|||
|
||||
-u::
|
||||
--update-head-ok::
|
||||
By default 'git-fetch' refuses to update the head which
|
||||
By default 'git fetch' refuses to update the head which
|
||||
corresponds to the current branch. This flag disables the
|
||||
check. This is purely for the internal use for 'git-pull'
|
||||
to communicate with 'git-fetch', and unless you are
|
||||
check. This is purely for the internal use for 'git pull'
|
||||
to communicate with 'git fetch', and unless you are
|
||||
implementing your own Porcelain you are not supposed to
|
||||
use it.
|
||||
|
||||
--upload-pack <upload-pack>::
|
||||
When given, and the repository to fetch from is handled
|
||||
by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
|
||||
by 'git fetch-pack', '--exec=<upload-pack>' is passed to
|
||||
the command to specify non-default path for the command
|
||||
run on the other end.
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ The `git add` command will not add ignored files by default. If any
|
|||
ignored files were explicitly specified on the command line, `git add`
|
||||
will fail with a list of ignored files. Ignored files reached by
|
||||
directory recursion or filename globbing performed by Git (quote your
|
||||
globs before the shell) will be silently ignored. The `add` command can
|
||||
globs before the shell) will be silently ignored. The 'git add' command can
|
||||
be used to add ignored files with the `-f` (force) option.
|
||||
|
||||
Please see linkgit:git-commit[1] for alternative ways to add content to a
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ OPTIONS
|
|||
|
||||
-k::
|
||||
--keep::
|
||||
Pass `-k` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
|
||||
Pass `-k` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
|
||||
|
||||
-c::
|
||||
--scissors::
|
||||
|
|
@ -53,7 +53,7 @@ OPTIONS
|
|||
|
||||
-u::
|
||||
--utf8::
|
||||
Pass `-u` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
|
||||
Pass `-u` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).
|
||||
The proposed commit log message taken from the e-mail
|
||||
is re-coded into UTF-8 encoding (configuration variable
|
||||
`i18n.commitencoding` can be used to specify project's
|
||||
|
|
@ -63,7 +63,7 @@ This was optional in prior versions of git, but now it is the
|
|||
default. You can use `--no-utf8` to override this.
|
||||
|
||||
--no-utf8::
|
||||
Pass `-n` flag to 'git-mailinfo' (see
|
||||
Pass `-n` flag to 'git mailinfo' (see
|
||||
linkgit:git-mailinfo[1]).
|
||||
|
||||
-3::
|
||||
|
|
@ -81,7 +81,7 @@ default. You can use `--no-utf8` to override this.
|
|||
-p<n>::
|
||||
--directory=<dir>::
|
||||
--reject::
|
||||
These flags are passed to the 'git-apply' (see linkgit:git-apply[1])
|
||||
These flags are passed to the 'git apply' (see linkgit:git-apply[1])
|
||||
program that applies
|
||||
the patch.
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ default. You can use `--no-utf8` to override this.
|
|||
to the screen before exiting. This overrides the
|
||||
standard message informing you to use `--resolved`
|
||||
or `--skip` to handle the failure. This is solely
|
||||
for internal use between 'git-rebase' and 'git-am'.
|
||||
for internal use between 'git rebase' and 'git am'.
|
||||
|
||||
--abort::
|
||||
Restore the original branch and abort the patching operation.
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ OPTIONS
|
|||
without using the working tree. This implies `--index`.
|
||||
|
||||
--build-fake-ancestor=<file>::
|
||||
Newer 'git-diff' output has embedded 'index information'
|
||||
Newer 'git diff' output has embedded 'index information'
|
||||
for each blob to help identify the original version that
|
||||
the patch applies to. When this flag is given, and if
|
||||
the original versions of the blobs are available locally,
|
||||
|
|
@ -83,7 +83,7 @@ the information is read from the current index instead.
|
|||
Apply the patch in reverse.
|
||||
|
||||
--reject::
|
||||
For atomicity, 'git-apply' by default fails the whole patch and
|
||||
For atomicity, 'git apply' by default fails the whole patch and
|
||||
does not touch the working tree when some of the hunks
|
||||
do not apply. This option makes it apply
|
||||
the parts of the patch that are applicable, and leave the
|
||||
|
|
@ -109,7 +109,7 @@ any of those replacements occurred.
|
|||
ever ignored.
|
||||
|
||||
--unidiff-zero::
|
||||
By default, 'git-apply' expects that the patch being
|
||||
By default, 'git apply' expects that the patch being
|
||||
applied is a unified diff with at least one line of context.
|
||||
This provides good safety measures, but breaks down when
|
||||
applying a diff generated with `--unified=0`. To bypass these
|
||||
|
|
@ -120,7 +120,7 @@ discouraged.
|
|||
|
||||
--apply::
|
||||
If you use any of the options marked "Turns off
|
||||
'apply'" above, 'git-apply' reads and outputs the
|
||||
'apply'" above, 'git apply' reads and outputs the
|
||||
requested information without actually applying the
|
||||
patch. Give this flag after those flags to also apply
|
||||
the patch.
|
||||
|
|
@ -229,7 +229,7 @@ apply.whitespace::
|
|||
|
||||
Submodules
|
||||
----------
|
||||
If the patch contains any changes to submodules then 'git-apply'
|
||||
If the patch contains any changes to submodules then 'git apply'
|
||||
treats these changes as follows.
|
||||
|
||||
If `--index` is specified (explicitly or implicitly), then the submodule
|
||||
|
|
|
|||
|
|
@ -29,17 +29,17 @@ branches that have different roots, it will refuse to run. In that case,
|
|||
edit your <archive/branch> parameters to define clearly the scope of the
|
||||
import.
|
||||
|
||||
'git-archimport' uses `tla` extensively in the background to access the
|
||||
'git archimport' uses `tla` extensively in the background to access the
|
||||
Arch repository.
|
||||
Make sure you have a recent version of `tla` available in the path. `tla` must
|
||||
know about the repositories you pass to 'git-archimport'.
|
||||
know about the repositories you pass to 'git archimport'.
|
||||
|
||||
For the initial import, 'git-archimport' expects to find itself in an empty
|
||||
For the initial import, 'git archimport' expects to find itself in an empty
|
||||
directory. To follow the development of a project that uses Arch, rerun
|
||||
'git-archimport' with the same parameters as the initial import to perform
|
||||
'git archimport' with the same parameters as the initial import to perform
|
||||
incremental imports.
|
||||
|
||||
While 'git-archimport' will try to create sensible branch names for the
|
||||
While 'git archimport' will try to create sensible branch names for the
|
||||
archives that it imports, it is also possible to specify git branch names
|
||||
manually. To do so, write a git branch name after each <archive/branch>
|
||||
parameter, separated by a colon. This way, you can shorten the Arch
|
||||
|
|
@ -84,7 +84,7 @@ OPTIONS
|
|||
|
||||
-o::
|
||||
Use this for compatibility with old-style branch names used by
|
||||
earlier versions of 'git-archimport'. Old-style branch names
|
||||
earlier versions of 'git archimport'. Old-style branch names
|
||||
were category--branch, whereas new-style branch names are
|
||||
archive,category--branch--version. In both cases, names given
|
||||
on the command-line will override the automatically-generated
|
||||
|
|
|
|||
|
|
@ -21,13 +21,13 @@ structure for the named tree, and writes it out to the standard
|
|||
output. If <prefix> is specified it is
|
||||
prepended to the filenames in the archive.
|
||||
|
||||
'git-archive' behaves differently when given a tree ID versus when
|
||||
'git archive' behaves differently when given a tree ID versus when
|
||||
given a commit ID or tag ID. In the first case the current time is
|
||||
used as the modification time of each file in the archive. In the latter
|
||||
case the commit time as recorded in the referenced commit object is
|
||||
used instead. Additionally the commit ID is stored in a global
|
||||
extended pax header if the tar format is used; it can be extracted
|
||||
using 'git-get-tar-commit-id'. In ZIP files it is stored as a file
|
||||
using 'git get-tar-commit-id'. In ZIP files it is stored as a file
|
||||
comment.
|
||||
|
||||
OPTIONS
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ last modified the line. Optionally, start annotating from the given revision.
|
|||
The command can also limit the range of lines annotated.
|
||||
|
||||
The report does not tell you anything about lines which have been deleted or
|
||||
replaced; you need to use a tool such as 'git-diff' or the "pickaxe"
|
||||
replaced; you need to use a tool such as 'git diff' or the "pickaxe"
|
||||
interface briefly mentioned in the following paragraph.
|
||||
|
||||
Apart from supporting file annotation, git also supports searching the
|
||||
|
|
@ -49,7 +49,7 @@ include::blame-options.txt[]
|
|||
file (see `-M`). The first number listed is the score.
|
||||
This is the number of alphanumeric characters detected
|
||||
as having been moved between or within files. This must be above
|
||||
a certain threshold for 'git-blame' to consider those lines
|
||||
a certain threshold for 'git blame' to consider those lines
|
||||
of code to have been moved.
|
||||
|
||||
-f::
|
||||
|
|
@ -100,7 +100,7 @@ header elements later.
|
|||
SPECIFYING RANGES
|
||||
-----------------
|
||||
|
||||
Unlike 'git-blame' and 'git-annotate' in older versions of git, the extent
|
||||
Unlike 'git blame' and 'git annotate' in older versions of git, the extent
|
||||
of the annotation can be limited to both line ranges and revision
|
||||
ranges. When you are interested in finding the origin for
|
||||
lines 40-60 for file `foo`, you can use the `-L` option like so
|
||||
|
|
@ -118,7 +118,7 @@ which limits the annotation to the body of the `hello` subroutine.
|
|||
|
||||
When you are not interested in changes older than version
|
||||
v2.6.18, or changes older than 3 weeks, you can use revision
|
||||
range specifiers similar to 'git-rev-list':
|
||||
range specifiers similar to 'git rev-list':
|
||||
|
||||
git blame v2.6.18.. -- foo
|
||||
git blame --since=3.weeks -- foo
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ SYNOPSIS
|
|||
'git branch' [--color | --no-color] [-r | -a]
|
||||
[-v [--abbrev=<length> | --no-abbrev]]
|
||||
[(--merged | --no-merged | --contains) [<commit>]]
|
||||
'git branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
|
||||
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
|
||||
'git branch' (-m | -M) [<oldbranch>] <newbranch>
|
||||
'git branch' (-d | -D) [-r] <branchname>...
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ working tree to it; use "git checkout <newbranch>" to switch to the
|
|||
new branch.
|
||||
|
||||
When a local branch is started off a remote branch, git sets up the
|
||||
branch so that 'git-pull' will appropriately merge from
|
||||
branch so that 'git pull' will appropriately merge from
|
||||
the remote branch. This behavior may be changed via the global
|
||||
`branch.autosetupmerge` configuration flag. That setting can be
|
||||
overridden by using the `--track` and `--no-track` options.
|
||||
|
|
@ -55,7 +55,7 @@ has a reflog then the reflog will also be deleted.
|
|||
|
||||
Use -r together with -d to delete remote-tracking branches. Note, that it
|
||||
only makes sense to delete remote-tracking branches if they no longer exist
|
||||
in the remote repository or if 'git-fetch' was configured not to fetch
|
||||
in the remote repository or if 'git fetch' was configured not to fetch
|
||||
them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a
|
||||
way to clean up all obsolete remote-tracking branches.
|
||||
|
||||
|
|
@ -76,7 +76,7 @@ OPTIONS
|
|||
-f::
|
||||
--force::
|
||||
Reset <branchname> to <startpoint> if <branchname> exists
|
||||
already. Without `-f` 'git-branch' refuses to change an existing branch.
|
||||
already. Without `-f` 'git branch' refuses to change an existing branch.
|
||||
|
||||
-m::
|
||||
Move/rename a branch and the corresponding reflog.
|
||||
|
|
@ -129,6 +129,12 @@ start-point is either a local or remote branch.
|
|||
Do not set up "upstream" configuration, even if the
|
||||
branch.autosetupmerge configuration variable is true.
|
||||
|
||||
--set-upstream::
|
||||
If specified branch does not exist yet or if '--force' has been
|
||||
given, acts exactly like '--track'. Otherwise sets up configuration
|
||||
like '--track' would when creating the branch, except that where
|
||||
branch points to is not changed.
|
||||
|
||||
--contains <commit>::
|
||||
Only list branches which contain the specified commit.
|
||||
|
||||
|
|
|
|||
|
|
@ -21,9 +21,9 @@ Some workflows require that one or more branches of development on one
|
|||
machine be replicated on another machine, but the two machines cannot
|
||||
be directly connected, and therefore the interactive git protocols (git,
|
||||
ssh, rsync, http) cannot be used. This command provides support for
|
||||
'git-fetch' and 'git-pull' to operate by packaging objects and references
|
||||
'git fetch' and 'git pull' to operate by packaging objects and references
|
||||
in an archive at the originating machine, then importing those into
|
||||
another repository using 'git-fetch' and 'git-pull'
|
||||
another repository using 'git fetch' and 'git pull'
|
||||
after moving the archive by some means (e.g., by sneakernet). As no
|
||||
direct connection between the repositories exists, the user must specify a
|
||||
basis for the bundle that is held by the destination repository: the
|
||||
|
|
@ -35,14 +35,14 @@ OPTIONS
|
|||
|
||||
create <file>::
|
||||
Used to create a bundle named 'file'. This requires the
|
||||
'git-rev-list' arguments to define the bundle contents.
|
||||
'git rev-list' arguments to define the bundle contents.
|
||||
|
||||
verify <file>::
|
||||
Used to check that a bundle file is valid and will apply
|
||||
cleanly to the current repository. This includes checks on the
|
||||
bundle format itself as well as checking that the prerequisite
|
||||
commits exist and are fully linked in the current repository.
|
||||
'git-bundle' prints a list of missing commits, if any, and exits
|
||||
'git bundle' prints a list of missing commits, if any, and exits
|
||||
with a non-zero status.
|
||||
|
||||
list-heads <file>::
|
||||
|
|
@ -51,15 +51,15 @@ list-heads <file>::
|
|||
printed out.
|
||||
|
||||
unbundle <file>::
|
||||
Passes the objects in the bundle to 'git-index-pack'
|
||||
Passes the objects in the bundle to 'git index-pack'
|
||||
for storage in the repository, then prints the names of all
|
||||
defined references. If a list of references is given, only
|
||||
references matching those in the list are printed. This command is
|
||||
really plumbing, intended to be called only by 'git-fetch'.
|
||||
really plumbing, intended to be called only by 'git fetch'.
|
||||
|
||||
[git-rev-list-args...]::
|
||||
A list of arguments, acceptable to 'git-rev-parse' and
|
||||
'git-rev-list', that specifies the specific objects and references
|
||||
A list of arguments, acceptable to 'git rev-parse' and
|
||||
'git rev-list', that specifies the specific objects and references
|
||||
to transport. For example, `master\~10..master` causes the
|
||||
current master reference to be packaged along with all objects
|
||||
added since its 10th ancestor commit. There is no explicit
|
||||
|
|
@ -69,16 +69,16 @@ unbundle <file>::
|
|||
|
||||
[refname...]::
|
||||
A list of references used to limit the references reported as
|
||||
available. This is principally of use to 'git-fetch', which
|
||||
available. This is principally of use to 'git fetch', which
|
||||
expects to receive only those references asked for and not
|
||||
necessarily everything in the pack (in this case, 'git-bundle' acts
|
||||
like 'git-fetch-pack').
|
||||
necessarily everything in the pack (in this case, 'git bundle' acts
|
||||
like 'git fetch-pack').
|
||||
|
||||
SPECIFYING REFERENCES
|
||||
---------------------
|
||||
|
||||
'git-bundle' will only package references that are shown by
|
||||
'git-show-ref': this includes heads, tags, and remote heads. References
|
||||
'git bundle' will only package references that are shown by
|
||||
'git show-ref': this includes heads, tags, and remote heads. References
|
||||
such as `master\~1` cannot be packaged, but are perfectly suitable for
|
||||
defining the basis. More than one reference may be packaged, and more
|
||||
than one basis can be specified. The objects packaged are those not
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ reference name expressions (see linkgit:git-rev-parse[1]):
|
|||
. A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
|
||||
value and store it in dstref" in fetch and push operations.
|
||||
It may also be used to select a specific object such as with
|
||||
'git-cat-file': "git cat-file blob v1.3.3:refs.c".
|
||||
'git cat-file': "git cat-file blob v1.3.3:refs.c".
|
||||
|
||||
. at-open-brace `@{` is used as a notation to access a reflog entry.
|
||||
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ $ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
|
|||
which will force all existing `*.h` files to be replaced with their
|
||||
cached copies. If an empty command line implied "all", then this would
|
||||
force-refresh everything in the index, which was not the point. But
|
||||
since 'git-checkout-index' accepts --stdin it would be faster to use:
|
||||
since 'git checkout-index' accepts --stdin it would be faster to use:
|
||||
|
||||
----------------
|
||||
$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
|
||||
|
|
@ -102,7 +102,7 @@ Using `--` is probably a good policy in scripts.
|
|||
Using --temp or --stage=all
|
||||
---------------------------
|
||||
When `--temp` is used (or implied by `--stage=all`)
|
||||
'git-checkout-index' will create a temporary file for each index
|
||||
'git checkout-index' will create a temporary file for each index
|
||||
entry being checked out. The index will not be updated with stat
|
||||
information. These options can be useful if the caller needs all
|
||||
stages of all unmerged entries so that the unmerged files can be
|
||||
|
|
@ -147,9 +147,9 @@ To update and refresh only the files already checked out::
|
|||
$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
|
||||
----------------
|
||||
|
||||
Using 'git-checkout-index' to "export an entire tree"::
|
||||
Using 'git checkout-index' to "export an entire tree"::
|
||||
The prefix ability basically makes it trivial to use
|
||||
'git-checkout-index' as an "export as tree" function.
|
||||
'git checkout-index' as an "export as tree" function.
|
||||
Just read the desired tree into the index, and do:
|
||||
+
|
||||
----------------
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ OPTIONS
|
|||
|
||||
-e::
|
||||
--edit::
|
||||
With this option, 'git-cherry-pick' will let you edit the commit
|
||||
With this option, 'git cherry-pick' will let you edit the commit
|
||||
message prior to committing.
|
||||
|
||||
-x::
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ DESCRIPTION
|
|||
The changeset (or "diff") of each commit between the fork-point and <head>
|
||||
is compared against each commit between the fork-point and <upstream>.
|
||||
The commits are compared with their 'patch id', obtained from
|
||||
the 'git-patch-id' program.
|
||||
the 'git patch-id' program.
|
||||
|
||||
Every commit that doesn't exist in the <upstream> branch
|
||||
has its id (sha1) reported, prefixed by a symbol. The ones that have
|
||||
|
|
@ -37,8 +37,8 @@ to and including <limit> are not reported:
|
|||
\__*__*__<limit>__-__+__> <head>
|
||||
|
||||
|
||||
Because 'git-cherry' compares the changeset rather than the commit id
|
||||
(sha1), you can use 'git-cherry' to find out if a commit you made locally
|
||||
Because 'git cherry' compares the changeset rather than the commit id
|
||||
(sha1), you can use 'git cherry' to find out if a commit you made locally
|
||||
has been applied <upstream> under a different commit id. For example,
|
||||
this will happen if you're feeding patches <upstream> via email rather
|
||||
than pushing or pulling commits directly.
|
||||
|
|
|
|||
|
|
@ -14,9 +14,9 @@ DESCRIPTION
|
|||
A Tcl/Tk based graphical interface to review modified files, stage
|
||||
them into the index, enter a commit message and record the new
|
||||
commit onto the current branch. This interface is an alternative
|
||||
to the less interactive 'git-commit' program.
|
||||
to the less interactive 'git commit' program.
|
||||
|
||||
'git-citool' is actually a standard alias for `git gui citool`.
|
||||
'git citool' is actually a standard alias for `git gui citool`.
|
||||
See linkgit:git-gui[1] for more details.
|
||||
|
||||
Author
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ OPTIONS
|
|||
-f::
|
||||
--force::
|
||||
If the git configuration specifies clean.requireForce as true,
|
||||
'git-clean' will refuse to run unless given -f or -n.
|
||||
'git clean' will refuse to run unless given -f or -n.
|
||||
|
||||
-n::
|
||||
--dry-run::
|
||||
|
|
@ -48,7 +48,7 @@ OPTIONS
|
|||
-x::
|
||||
Don't use the ignore rules. This allows removing all untracked
|
||||
files, including build products. This can be used (possibly in
|
||||
conjunction with 'git-reset') to create a pristine
|
||||
conjunction with 'git reset') to create a pristine
|
||||
working directory to test a clean build.
|
||||
|
||||
-X::
|
||||
|
|
|
|||
|
|
@ -96,13 +96,19 @@ objects from the source repository into a pack in the cloned repository.
|
|||
|
||||
--quiet::
|
||||
-q::
|
||||
Operate quietly. This flag is also passed to the `rsync'
|
||||
Operate quietly. Progress is not reported to the standard
|
||||
error stream. This flag is also passed to the `rsync'
|
||||
command when given.
|
||||
|
||||
--verbose::
|
||||
-v::
|
||||
Display the progress bar, even in case the standard output is not
|
||||
a terminal.
|
||||
Run verbosely.
|
||||
|
||||
--progress::
|
||||
Progress status is reported on the standard error stream
|
||||
by default when it is attached to a terminal, unless -q
|
||||
is specified. This flag forces progress status even if the
|
||||
standard error stream is not directed to a terminal.
|
||||
|
||||
--no-checkout::
|
||||
-n::
|
||||
|
|
|
|||
|
|
@ -70,9 +70,10 @@ is taken from the configuration items user.name and user.email, or, if not
|
|||
present, system user name and fully qualified hostname.
|
||||
|
||||
A commit comment is read from stdin. If a changelog
|
||||
entry is not provided via "<" redirection, 'git-commit-tree' will just wait
|
||||
entry is not provided via "<" redirection, 'git commit-tree' will just wait
|
||||
for one to be entered and terminated with ^D.
|
||||
|
||||
include::date-formats.txt[]
|
||||
|
||||
Diagnostics
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -11,7 +11,8 @@ SYNOPSIS
|
|||
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
|
||||
[(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]
|
||||
[--allow-empty] [--no-verify] [-e] [--author=<author>]
|
||||
[--cleanup=<mode>] [--] [[-i | -o ]<file>...]
|
||||
[--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]
|
||||
[[-i | -o ]<file>...]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
|
@ -20,11 +21,11 @@ with a log message from the user describing the changes.
|
|||
|
||||
The content to be added can be specified in several ways:
|
||||
|
||||
1. by using 'git-add' to incrementally "add" changes to the
|
||||
1. by using 'git add' to incrementally "add" changes to the
|
||||
index before using the 'commit' command (Note: even modified
|
||||
files must be "added");
|
||||
|
||||
2. by using 'git-rm' to remove files from the working tree
|
||||
2. by using 'git rm' to remove files from the working tree
|
||||
and the index, again before using the 'commit' command;
|
||||
|
||||
3. by listing files as arguments to the 'commit' command, in which
|
||||
|
|
@ -40,14 +41,14 @@ The content to be added can be specified in several ways:
|
|||
|
||||
5. by using the --interactive switch with the 'commit' command to decide one
|
||||
by one which files should be part of the commit, before finalizing the
|
||||
operation. Currently, this is done by invoking 'git-add --interactive'.
|
||||
operation. Currently, this is done by invoking 'git add --interactive'.
|
||||
|
||||
The `--dry-run` option can be used to obtain a
|
||||
summary of what is included by any of the above for the next
|
||||
commit by giving the same set of parameters (options and paths).
|
||||
|
||||
If you make a commit and then find a mistake immediately after
|
||||
that, you can recover from it with 'git-reset'.
|
||||
that, you can recover from it with 'git reset'.
|
||||
|
||||
|
||||
OPTIONS
|
||||
|
|
@ -74,6 +75,20 @@ OPTIONS
|
|||
authorship of the resulting commit now belongs of the committer.
|
||||
This also renews the author timestamp.
|
||||
|
||||
--short::
|
||||
When doing a dry-run, give the output in the short-format. See
|
||||
linkgit:git-status[1] for details. Implies `--dry-run`.
|
||||
|
||||
--porcelain::
|
||||
When doing a dry-run, give the output in a porcelain-ready
|
||||
format. See linkgit:git-status[1] for details. Implies
|
||||
`--dry-run`.
|
||||
|
||||
-z::
|
||||
When showing `short` or `porcelain` status output, terminate
|
||||
entries in the status output with NUL, instead of LF. If no
|
||||
format is given, implies the `--porcelain` output format.
|
||||
|
||||
-F <file>::
|
||||
--file=<file>::
|
||||
Take the commit message from the given file. Use '-' to
|
||||
|
|
@ -85,6 +100,9 @@ OPTIONS
|
|||
an existing commit that matches the given string and its author
|
||||
name is used.
|
||||
|
||||
--date=<date>::
|
||||
Override the author date used in the commit.
|
||||
|
||||
-m <msg>::
|
||||
--message=<msg>::
|
||||
Use the given <msg> as the commit message.
|
||||
|
|
@ -167,7 +185,7 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)
|
|||
Make a commit only from the paths specified on the
|
||||
command line, disregarding any contents that have been
|
||||
staged so far. This is the default mode of operation of
|
||||
'git-commit' if any paths are given on the command line,
|
||||
'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 to be specified, which can be used to amend
|
||||
|
|
@ -207,6 +225,17 @@ specified.
|
|||
to be committed, paths with local changes that will be left
|
||||
uncommitted and paths that are untracked.
|
||||
|
||||
--status::
|
||||
Include the output of linkgit:git-status[1] in the commit
|
||||
message template when using an editor to prepare the commit
|
||||
message. Defaults to on, but can be used to override
|
||||
configuration variable commit.status.
|
||||
|
||||
--no-status::
|
||||
Do not include the output of linkgit:git-status[1] in the
|
||||
commit message template when using an editor to prepare the
|
||||
default commit message.
|
||||
|
||||
\--::
|
||||
Do not interpret any more arguments as options.
|
||||
|
||||
|
|
@ -217,15 +246,17 @@ specified.
|
|||
these files are also staged for the next commit on top
|
||||
of what have been staged before.
|
||||
|
||||
:git-commit: 1
|
||||
include::date-formats.txt[]
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
When recording your own work, the contents of modified files in
|
||||
your working tree are temporarily stored to a staging area
|
||||
called the "index" with 'git-add'. A file can be
|
||||
called the "index" with 'git add'. A file can be
|
||||
reverted back, only in the index but not in the working tree,
|
||||
to that of the last commit with `git reset HEAD -- <file>`,
|
||||
which effectively reverts 'git-add' and prevents the changes to
|
||||
which effectively reverts 'git add' and prevents the changes to
|
||||
this file from participating in the next commit. After building
|
||||
the state to be committed incrementally with these commands,
|
||||
`git commit` (without any pathname parameter) is used to record what
|
||||
|
|
@ -281,13 +312,13 @@ $ git commit
|
|||
this second commit would record the changes to `hello.c` and
|
||||
`hello.h` as expected.
|
||||
|
||||
After a merge (initiated by 'git-merge' or 'git-pull') stops
|
||||
After a merge (initiated by 'git merge' or 'git pull') stops
|
||||
because of conflicts, cleanly merged
|
||||
paths are already staged to be committed for you, and paths that
|
||||
conflicted are left in unmerged state. You would have to first
|
||||
check which paths are conflicting with 'git-status'
|
||||
check which paths are conflicting with 'git status'
|
||||
and after fixing them manually in your working tree, you would
|
||||
stage the result as usual with 'git-add':
|
||||
stage the result as usual with 'git add':
|
||||
|
||||
------------
|
||||
$ git status | grep unmerged
|
||||
|
|
|
|||
|
|
@ -37,11 +37,12 @@ existing values that match the regexp are updated or unset. If
|
|||
you want to handle the lines that do *not* match the regex, just
|
||||
prepend a single exclamation mark in front (see also <<EXAMPLES>>).
|
||||
|
||||
The type specifier can be either '--int' or '--bool', which will make
|
||||
'git-config' ensure that the variable(s) are of the given type and
|
||||
The type specifier can be either '--int' or '--bool', to make
|
||||
'git config' ensure that the variable(s) are of the given type and
|
||||
convert the value to the canonical form (simple decimal number for int,
|
||||
a "true" or "false" string for bool). If no type specifier is passed,
|
||||
no checks or transformations are performed on the value.
|
||||
a "true" or "false" string for bool), or '--path', which does some
|
||||
path expansion (see '--path' below). If no type specifier is passed, no
|
||||
checks or transformations are performed on the value.
|
||||
|
||||
The file-option can be one of '--system', '--global' or '--file'
|
||||
which specify where the values will be read from or written to.
|
||||
|
|
@ -124,18 +125,25 @@ See also <<FILES>>.
|
|||
List all variables set in config file.
|
||||
|
||||
--bool::
|
||||
'git-config' will ensure that the output is "true" or "false"
|
||||
'git config' will ensure that the output is "true" or "false"
|
||||
|
||||
--int::
|
||||
'git-config' will ensure that the output is a simple
|
||||
'git config' will ensure that the output is a simple
|
||||
decimal number. An optional value suffix of 'k', 'm', or 'g'
|
||||
in the config file will cause the value to be multiplied
|
||||
by 1024, 1048576, or 1073741824 prior to output.
|
||||
|
||||
--bool-or-int::
|
||||
'git-config' will ensure that the output matches the format of
|
||||
'git config' will ensure that the output matches the format of
|
||||
either --bool or --int, as described above.
|
||||
|
||||
--path::
|
||||
'git-config' will expand leading '{tilde}' to the value of
|
||||
'$HOME', and '{tilde}user' to the home directory for the
|
||||
specified user. This option has no effect when setting the
|
||||
value (but you can use 'git config bla {tilde}/' from the
|
||||
command line to let your shell do the expansion).
|
||||
|
||||
-z::
|
||||
--null::
|
||||
For all options that output values and/or keys, always
|
||||
|
|
@ -173,7 +181,7 @@ FILES
|
|||
-----
|
||||
|
||||
If not set explicitly with '--file', there are three files where
|
||||
'git-config' will search for configuration options:
|
||||
'git config' will search for configuration options:
|
||||
|
||||
$GIT_DIR/config::
|
||||
Repository specific configuration file. (The filename is
|
||||
|
|
@ -190,12 +198,12 @@ $(prefix)/etc/gitconfig::
|
|||
If no further options are given, all reading options will read all of these
|
||||
files that are available. If the global or the system-wide configuration
|
||||
file are not available they will be ignored. If the repository configuration
|
||||
file is not available or readable, 'git-config' will exit with a non-zero
|
||||
file is not available or readable, 'git config' will exit with a non-zero
|
||||
error code. However, in neither case will an error message be issued.
|
||||
|
||||
All writing options will per default write to the repository specific
|
||||
configuration file. Note that this also affects options like '--replace-all'
|
||||
and '--unset'. *'git-config' will only ever change one file at a time*.
|
||||
and '--unset'. *'git config' will only ever change one file at a time*.
|
||||
|
||||
You can override these rules either by command line options or by environment
|
||||
variables. The '--global' and the '--system' options will limit the file used
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ by default.
|
|||
|
||||
Supports file additions, removals, and commits that affect binary files.
|
||||
|
||||
If the commit is a merge commit, you must tell 'git-cvsexportcommit' what
|
||||
If the commit is a merge commit, you must tell 'git cvsexportcommit' what
|
||||
parent the changeset should be done against.
|
||||
|
||||
OPTIONS
|
||||
|
|
|
|||
|
|
@ -28,9 +28,9 @@ At least version 2.1 is required.
|
|||
Please see the section <<issues,ISSUES>> for further reference.
|
||||
|
||||
You should *never* do any work of your own on the branches that are
|
||||
created by 'git-cvsimport'. By default initial import will create and populate a
|
||||
created by 'git cvsimport'. By default initial import will create and populate a
|
||||
"master" branch from the CVS repository's main branch which you're free
|
||||
to work with; after that, you need to 'git-merge' incremental imports, or
|
||||
to work with; after that, you need to 'git merge' incremental imports, or
|
||||
any CVS branches, yourself. It is advisable to specify a named remote via
|
||||
-r to separate and protect the incoming branches.
|
||||
|
||||
|
|
@ -49,13 +49,13 @@ OPTIONS
|
|||
-d <CVSROOT>::
|
||||
The root of the CVS archive. May be local (a simple path) or remote;
|
||||
currently, only the :local:, :ext: and :pserver: access methods
|
||||
are supported. If not given, 'git-cvsimport' will try to read it
|
||||
are supported. If not given, 'git cvsimport' will try to read it
|
||||
from `CVS/Root`. If no such file exists, it checks for the
|
||||
`CVSROOT` environment variable.
|
||||
|
||||
<CVS_module>::
|
||||
The CVS module you want to import. Relative to <CVSROOT>.
|
||||
If not given, 'git-cvsimport' tries to read it from
|
||||
If not given, 'git cvsimport' tries to read it from
|
||||
`CVS/Repository`.
|
||||
|
||||
-C <target-dir>::
|
||||
|
|
@ -65,14 +65,14 @@ OPTIONS
|
|||
-r <remote>::
|
||||
The git remote to import this CVS repository into.
|
||||
Moves all CVS branches into remotes/<remote>/<branch>
|
||||
akin to the way 'git-clone' uses 'origin' by default.
|
||||
akin to the way 'git clone' uses 'origin' by default.
|
||||
|
||||
-o <branch-for-HEAD>::
|
||||
When no remote is specified (via -r) the 'HEAD' branch
|
||||
from CVS is imported to the 'origin' branch within the git
|
||||
repository, as 'HEAD' already has a special meaning for git.
|
||||
When a remote is specified the 'HEAD' branch is named
|
||||
remotes/<remote>/master mirroring 'git-clone' behaviour.
|
||||
remotes/<remote>/master mirroring 'git clone' behaviour.
|
||||
Use this option if you want to import into a different
|
||||
branch.
|
||||
+
|
||||
|
|
@ -145,17 +145,17 @@ This option can be used several times to provide several detection regexes.
|
|||
|
||||
---------
|
||||
+
|
||||
'git-cvsimport' will make it appear as those authors had
|
||||
'git cvsimport' will make it appear as those authors had
|
||||
their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
|
||||
all along.
|
||||
+
|
||||
For convenience, this data is saved to `$GIT_DIR/cvs-authors`
|
||||
each time the '-A' option is provided and read from that same
|
||||
file each time 'git-cvsimport' is run.
|
||||
file each time 'git cvsimport' is run.
|
||||
+
|
||||
It is not recommended to use this feature if you intend to
|
||||
export changes back to CVS again later with
|
||||
'git-cvsexportcommit'.
|
||||
'git cvsexportcommit'.
|
||||
|
||||
-h::
|
||||
Print a short usage message and exit.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
|
|||
Usage:
|
||||
|
||||
[verse]
|
||||
'git cvsserver' [options] [pserver|server] [<directory> ...]
|
||||
'git-cvsserver' [options] [pserver|server] [<directory> ...]
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
|
@ -206,7 +206,7 @@ them write access to the directory, too.
|
|||
The database can not be reliably regenerated in a
|
||||
consistent form after the branch it is tracking has changed.
|
||||
Example: For merged branches, 'git-cvsserver' only tracks
|
||||
one branch of development, and after a 'git-merge' an
|
||||
one branch of development, and after a 'git merge' an
|
||||
incrementally updated database may track a different branch
|
||||
than a database regenerated from scratch, causing inconsistent
|
||||
CVS revision numbers. `git-cvsserver` has no way of knowing which
|
||||
|
|
@ -277,6 +277,21 @@ In `dbdriver` and `dbuser` you can use the following variables:
|
|||
If no name can be determined, the
|
||||
numeric uid is used.
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
These variables obviate the need for command-line options in some
|
||||
circumstances, allowing easier restricted usage through git-shell.
|
||||
|
||||
GIT_CVSSERVER_BASE_PATH takes the place of the argument to --base-path.
|
||||
|
||||
GIT_CVSSERVER_ROOT specifies a single-directory whitelist. The
|
||||
repository must still be configured to allow access through
|
||||
git-cvsserver, as described above.
|
||||
|
||||
When these environment variables are set, the corresponding
|
||||
command-line arguments may not be used.
|
||||
|
||||
Eclipse CVS Client Notes
|
||||
------------------------
|
||||
|
||||
|
|
@ -294,7 +309,7 @@ To get a checkout with the Eclipse CVS client:
|
|||
Protocol notes: If you are using anonymous access via pserver, just select that.
|
||||
Those using SSH access should choose the 'ext' protocol, and configure 'ext'
|
||||
access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
|
||||
"'git cvsserver'". Note that password support is not good when using 'ext',
|
||||
"`git cvsserver`". Note that password support is not good when using 'ext',
|
||||
you will definitely want to have SSH keys setup.
|
||||
|
||||
Alternatively, you can just use the non-standard extssh protocol that Eclipse
|
||||
|
|
|
|||
|
|
@ -28,36 +28,36 @@ that service if it is enabled.
|
|||
It verifies that the directory has the magic file "git-daemon-export-ok", and
|
||||
it will refuse to export any git directory that hasn't explicitly been marked
|
||||
for export this way (unless the '--export-all' parameter is specified). If you
|
||||
pass some directory paths as 'git-daemon' arguments, you can further restrict
|
||||
pass some directory paths as 'git daemon' arguments, you can further restrict
|
||||
the offers to a whitelist comprising of those.
|
||||
|
||||
By default, only `upload-pack` service is enabled, which serves
|
||||
'git-fetch-pack' and 'git-ls-remote' clients, which are invoked
|
||||
from 'git-fetch', 'git-pull', and 'git-clone'.
|
||||
'git fetch-pack' and 'git ls-remote' clients, which are invoked
|
||||
from 'git fetch', 'git pull', and 'git clone'.
|
||||
|
||||
This is ideally suited for read-only updates, i.e., pulling from
|
||||
git repositories.
|
||||
|
||||
An `upload-archive` also exists to serve 'git-archive'.
|
||||
An `upload-archive` also exists to serve 'git archive'.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
--strict-paths::
|
||||
Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
|
||||
"/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
|
||||
'git-daemon' will refuse to start when this option is enabled and no
|
||||
'git daemon' will refuse to start when this option is enabled and no
|
||||
whitelist is specified.
|
||||
|
||||
--base-path=path::
|
||||
Remap all the path requests as relative to the given path.
|
||||
This is sort of "GIT root" - if you run 'git-daemon' with
|
||||
This is sort of "GIT root" - if you run 'git daemon' with
|
||||
'--base-path=/srv/git' on example.com, then if you later try to pull
|
||||
'git://example.com/hello.git', 'git-daemon' will interpret the path
|
||||
'git://example.com/hello.git', 'git daemon' will interpret the path
|
||||
as '/srv/git/hello.git'.
|
||||
|
||||
--base-path-relaxed::
|
||||
If --base-path is enabled and repo lookup fails, with this option
|
||||
'git-daemon' will attempt to lookup without prefixing the base path.
|
||||
'git daemon' will attempt to lookup without prefixing the base path.
|
||||
This is useful for switching to --base-path usage, while still
|
||||
allowing the old paths.
|
||||
|
||||
|
|
@ -143,7 +143,7 @@ OPTIONS
|
|||
+
|
||||
Giving these options is an error when used with `--inetd`; use
|
||||
the facility of inet daemon to achieve the same before spawning
|
||||
'git-daemon' if needed.
|
||||
'git daemon' if needed.
|
||||
|
||||
--enable=service::
|
||||
--disable=service::
|
||||
|
|
@ -169,24 +169,24 @@ SERVICES
|
|||
|
||||
These services can be globally enabled/disabled using the
|
||||
command line options of this command. If a finer-grained
|
||||
control is desired (e.g. to allow 'git-archive' to be run
|
||||
control is desired (e.g. to allow 'git archive' to be run
|
||||
against only in a few selected repositories the daemon serves),
|
||||
the per-repository configuration file can be used to enable or
|
||||
disable them.
|
||||
|
||||
upload-pack::
|
||||
This serves 'git-fetch-pack' and 'git-ls-remote'
|
||||
This serves 'git fetch-pack' and 'git ls-remote'
|
||||
clients. It is enabled by default, but a repository can
|
||||
disable it by setting `daemon.uploadpack` configuration
|
||||
item to `false`.
|
||||
|
||||
upload-archive::
|
||||
This serves 'git-archive --remote'. It is disabled by
|
||||
This serves 'git archive --remote'. It is disabled by
|
||||
default, but a repository can enable it by setting
|
||||
`daemon.uploadarch` configuration item to `true`.
|
||||
|
||||
receive-pack::
|
||||
This serves 'git-send-pack' clients, allowing anonymous
|
||||
This serves 'git send-pack' clients, allowing anonymous
|
||||
push. It is disabled by default, as there is _no_
|
||||
authentication in the protocol (in other words, anybody
|
||||
can push anything into the repository, including removal
|
||||
|
|
@ -204,8 +204,8 @@ $ grep 9418 /etc/services
|
|||
git 9418/tcp # Git Version Control System
|
||||
------------
|
||||
|
||||
'git-daemon' as inetd server::
|
||||
To set up 'git-daemon' as an inetd service that handles any
|
||||
'git daemon' as inetd server::
|
||||
To set up 'git daemon' as an inetd service that handles any
|
||||
repository under the whitelisted set of directories, /pub/foo
|
||||
and /pub/bar, place an entry like the following into
|
||||
/etc/inetd all on one line:
|
||||
|
|
@ -217,8 +217,8 @@ git 9418/tcp # Git Version Control System
|
|||
------------------------------------------------
|
||||
|
||||
|
||||
'git-daemon' as inetd server for virtual hosts::
|
||||
To set up 'git-daemon' as an inetd service that handles
|
||||
'git daemon' as inetd server for virtual hosts::
|
||||
To set up 'git daemon' as an inetd service that handles
|
||||
repositories for different virtual hosts, `www.example.com`
|
||||
and `www.example.org`, place an entry like the following into
|
||||
`/etc/inetd` all on one line:
|
||||
|
|
@ -240,8 +240,8 @@ clients, a symlink from `/software` into the appropriate
|
|||
default repository could be made as well.
|
||||
|
||||
|
||||
'git-daemon' as regular daemon for virtual hosts::
|
||||
To set up 'git-daemon' as a regular, non-inetd service that
|
||||
'git daemon' as regular daemon for virtual hosts::
|
||||
To set up 'git daemon' as a regular, non-inetd service that
|
||||
handles repositories for multiple virtual hosts based on
|
||||
their IP addresses, start the daemon like this:
|
||||
+
|
||||
|
|
@ -258,7 +258,7 @@ Repositories can still be accessed by hostname though, assuming
|
|||
they correspond to these IP addresses.
|
||||
|
||||
selectively enable/disable services per repository::
|
||||
To enable 'git-archive --remote' and disable 'git-fetch' against
|
||||
To enable 'git archive --remote' and disable 'git fetch' against
|
||||
a repository, have the following in the configuration file in the
|
||||
repository (that is the file 'config' next to 'HEAD', 'refs' and
|
||||
'objects').
|
||||
|
|
@ -272,7 +272,7 @@ selectively enable/disable services per repository::
|
|||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
'git-daemon' will set REMOTE_ADDR to the IP address of the client
|
||||
'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.
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ of commits which would be displayed by "git log v1.0.4..parent".
|
|||
The hash suffix is "-g" + 7-char abbreviation for the tip commit
|
||||
of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
|
||||
|
||||
Doing a 'git-describe' on a tag-name will just show the tag name:
|
||||
Doing a 'git describe' on a tag-name will just show the tag name:
|
||||
|
||||
[torvalds@g5 git]$ git describe v1.0.4
|
||||
v1.0.4
|
||||
|
|
@ -136,13 +136,13 @@ be sufficient to disambiguate these commits.
|
|||
SEARCH STRATEGY
|
||||
---------------
|
||||
|
||||
For each committish supplied, 'git-describe' will first look for
|
||||
For each committish supplied, 'git describe' will first look for
|
||||
a tag which tags exactly that commit. Annotated tags will always
|
||||
be preferred over lightweight tags, and tags with newer dates will
|
||||
always be preferred over tags with older dates. If an exact match
|
||||
is found, its name will be output and searching will stop.
|
||||
|
||||
If an exact match was not found, 'git-describe' will walk back
|
||||
If an exact match was not found, 'git describe' will walk back
|
||||
through the commit history to locate an ancestor commit which
|
||||
has been tagged. The ancestor's tag will be output along with an
|
||||
abbreviation of the input committish's SHA1.
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ DESCRIPTION
|
|||
Compares the files in the working tree and the index. When paths
|
||||
are specified, compares only those named paths. Otherwise all
|
||||
entries in the index are compared. The output format is the
|
||||
same as for 'git-diff-index' and 'git-diff-tree'.
|
||||
same as for 'git diff-index' and 'git diff-tree'.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ include::diff-options.txt[]
|
|||
-m::
|
||||
By default, files recorded in the index but not checked
|
||||
out are reported as deleted. This flag makes
|
||||
'git-diff-index' say that all non-checked-out files are up
|
||||
'git diff-index' say that all non-checked-out files are up
|
||||
to date.
|
||||
|
||||
include::diff-format.txt[]
|
||||
|
|
@ -48,7 +48,7 @@ Cached Mode
|
|||
If '--cached' is specified, it allows you to ask:
|
||||
|
||||
show me the differences between HEAD and the current index
|
||||
contents (the ones I'd write using 'git-write-tree')
|
||||
contents (the ones I'd write using 'git write-tree')
|
||||
|
||||
For example, let's say that you have worked on your working directory, updated
|
||||
some files in the index and are ready to commit. You want to see exactly
|
||||
|
|
@ -60,7 +60,7 @@ object and compare it that way, and to do that, you just do
|
|||
Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
|
||||
done an `update-index` to make that effective in the index file.
|
||||
`git diff-files` wouldn't show anything at all, since the index file
|
||||
matches my working directory. But doing a 'git-diff-index' does:
|
||||
matches my working directory. But doing a 'git diff-index' does:
|
||||
|
||||
torvalds@ppc970:~/git> git diff-index --cached HEAD
|
||||
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
|
||||
|
|
@ -69,10 +69,10 @@ matches my working directory. But doing a 'git-diff-index' does:
|
|||
You can see easily that the above is a rename.
|
||||
|
||||
In fact, `git diff-index --cached` *should* always be entirely equivalent to
|
||||
actually doing a 'git-write-tree' and comparing that. Except this one is much
|
||||
actually doing a 'git write-tree' and comparing that. Except this one is much
|
||||
nicer for the case where you just want to check where you are.
|
||||
|
||||
So doing a 'git-diff-index --cached' is basically very useful when you are
|
||||
So doing a `git diff-index --cached` is basically very useful when you are
|
||||
asking yourself "what have I already marked for being committed, and
|
||||
what's the difference to a previous tree".
|
||||
|
||||
|
|
@ -80,20 +80,20 @@ Non-cached Mode
|
|||
---------------
|
||||
The "non-cached" mode takes a different approach, and is potentially
|
||||
the more useful of the two in that what it does can't be emulated with
|
||||
a 'git-write-tree' + 'git-diff-tree'. Thus that's the default mode.
|
||||
a 'git write-tree' + 'git diff-tree'. Thus that's the default mode.
|
||||
The non-cached version asks the question:
|
||||
|
||||
show me the differences between HEAD and the currently checked out
|
||||
tree - index contents _and_ files that aren't up-to-date
|
||||
|
||||
which is obviously a very useful question too, since that tells you what
|
||||
you *could* commit. Again, the output matches the 'git-diff-tree -r'
|
||||
you *could* commit. Again, the output matches the 'git diff-tree -r'
|
||||
output to a tee, but with a twist.
|
||||
|
||||
The twist is that if some file doesn't match the index, we don't have
|
||||
a backing store thing for it, and we use the magic "all-zero" sha1 to
|
||||
show that. So let's say that you have edited `kernel/sched.c`, but
|
||||
have not actually done a 'git-update-index' on it yet - there is no
|
||||
have not actually done a 'git update-index' on it yet - there is no
|
||||
"object" associated with the new state, and you get:
|
||||
|
||||
torvalds@ppc970:~/v2.6/linux> git diff-index HEAD
|
||||
|
|
@ -104,11 +104,11 @@ not up-to-date and may contain new stuff. The all-zero sha1 means that to
|
|||
get the real diff, you need to look at the object in the working directory
|
||||
directly rather than do an object-to-object diff.
|
||||
|
||||
NOTE: As with other commands of this type, 'git-diff-index' does not
|
||||
NOTE: As with other commands of this type, 'git diff-index' does not
|
||||
actually look at the contents of the file at all. So maybe
|
||||
`kernel/sched.c` hasn't actually changed, and it's just that you
|
||||
touched it. In either case, it's a note that you need to
|
||||
'git-update-index' it to make the index be in sync.
|
||||
'git update-index' it to make the index be in sync.
|
||||
|
||||
NOTE: You can have a mixture of files show up as "has been updated"
|
||||
and "is still dirty in the working directory" together. You can always
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Compares the content and mode of the blobs found via two tree objects.
|
|||
If there is only one <tree-ish> given, the commit is compared with its parents
|
||||
(see --stdin below).
|
||||
|
||||
Note that 'git-diff-tree' can use the tree encapsulated in a commit object.
|
||||
Note that 'git diff-tree' can use the tree encapsulated in a commit object.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
|
@ -67,25 +67,25 @@ The following flags further affect the behavior when comparing
|
|||
commits (but not trees).
|
||||
|
||||
-m::
|
||||
By default, 'git-diff-tree --stdin' does not show
|
||||
By default, 'git diff-tree --stdin' does not show
|
||||
differences for merge commits. With this flag, it shows
|
||||
differences to that commit from all of its parents. See
|
||||
also '-c'.
|
||||
|
||||
-s::
|
||||
By default, 'git-diff-tree --stdin' shows differences,
|
||||
By default, 'git diff-tree --stdin' shows differences,
|
||||
either in machine-readable form (without '-p') or in patch
|
||||
form (with '-p'). This output can be suppressed. It is
|
||||
only useful with '-v' flag.
|
||||
|
||||
-v::
|
||||
This flag causes 'git-diff-tree --stdin' to also show
|
||||
This flag causes 'git diff-tree --stdin' to also show
|
||||
the commit message before the differences.
|
||||
|
||||
include::pretty-options.txt[]
|
||||
|
||||
--no-commit-id::
|
||||
'git-diff-tree' outputs a line with the commit ID when
|
||||
'git diff-tree' outputs a line with the commit ID when
|
||||
applicable. This flag suppressed the commit ID output.
|
||||
|
||||
-c::
|
||||
|
|
|
|||
|
|
@ -157,6 +157,10 @@ $ git diff -R <2>
|
|||
rewrites (very expensive).
|
||||
<2> Output diff in reverse.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
linkgit:git-difftool[1]::
|
||||
Show changes using common diff tools
|
||||
|
||||
Author
|
||||
------
|
||||
|
|
|
|||
|
|
@ -7,13 +7,13 @@ git-difftool - Show changes using common diff tools
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git difftool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<'git diff' options>]
|
||||
'git difftool' [<options>] <commit>{0,2} [--] [<path>...]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
'git-difftool' is a git command that allows you to compare and edit files
|
||||
'git difftool' is a git command that allows you to compare and edit files
|
||||
between revisions using common diff tools. 'git difftool' is a frontend
|
||||
to 'git-diff' and accepts the same options and arguments.
|
||||
to 'git diff' and accepts the same options and arguments.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
|
@ -33,23 +33,23 @@ OPTIONS
|
|||
kdiff3, kompare, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff,
|
||||
ecmerge, diffuse, opendiff, p4merge and araxis.
|
||||
+
|
||||
If a diff tool is not specified, 'git-difftool'
|
||||
If a diff tool is not specified, 'git difftool'
|
||||
will use the configuration variable `diff.tool`. If the
|
||||
configuration variable `diff.tool` is not set, 'git-difftool'
|
||||
configuration variable `diff.tool` is not set, 'git difftool'
|
||||
will pick a suitable default.
|
||||
+
|
||||
You can explicitly provide a full path to the tool by setting the
|
||||
configuration variable `difftool.<tool>.path`. For example, you
|
||||
can configure the absolute path to kdiff3 by setting
|
||||
`difftool.kdiff3.path`. Otherwise, 'git-difftool' assumes the
|
||||
`difftool.kdiff3.path`. Otherwise, 'git difftool' assumes the
|
||||
tool is available in PATH.
|
||||
+
|
||||
Instead of running one of the known diff tools,
|
||||
'git-difftool' can be customized to run an alternative program
|
||||
'git difftool' can be customized to run an alternative program
|
||||
by specifying the command line to invoke in a configuration
|
||||
variable `difftool.<tool>.cmd`.
|
||||
+
|
||||
When 'git-difftool' is invoked with this tool (either through the
|
||||
When 'git difftool' is invoked with this tool (either through the
|
||||
`-t` or `--tool` option or the `diff.tool` configuration variable)
|
||||
the configured command line will be invoked with the following
|
||||
variables available: `$LOCAL` is set to the name of the temporary
|
||||
|
|
@ -58,16 +58,31 @@ is set to the name of the temporary file containing the contents
|
|||
of the diff post-image. `$BASE` is provided for compatibility
|
||||
with custom merge tool commands and has the same value as `$LOCAL`.
|
||||
|
||||
-x <command>::
|
||||
--extcmd=<command>::
|
||||
Specify a custom command for viewing diffs.
|
||||
'git-difftool' ignores the configured defaults and runs
|
||||
`$command $LOCAL $REMOTE` when this option is specified.
|
||||
|
||||
-g::
|
||||
--gui::
|
||||
When 'git-difftool' is invoked with the `-g` or `--gui` option
|
||||
the default diff tool will be read from the configured
|
||||
`diff.guitool` variable instead of `diff.tool`.
|
||||
|
||||
See linkgit:git-diff[1] for the full list of supported options.
|
||||
|
||||
CONFIG VARIABLES
|
||||
----------------
|
||||
'git-difftool' falls back to 'git-mergetool' config variables when the
|
||||
'git difftool' falls back to 'git mergetool' config variables when the
|
||||
difftool equivalents have not been defined.
|
||||
|
||||
diff.tool::
|
||||
The default diff tool to use.
|
||||
|
||||
diff.guitool::
|
||||
The default diff tool to use when `--gui` is specified.
|
||||
|
||||
difftool.<tool>.path::
|
||||
Override the path for the given tool. This is useful in case
|
||||
your tool is not in the PATH.
|
||||
|
|
|
|||
|
|
@ -13,18 +13,18 @@ SYNOPSIS
|
|||
DESCRIPTION
|
||||
-----------
|
||||
This program dumps the given revisions in a form suitable to be piped
|
||||
into 'git-fast-import'.
|
||||
into 'git fast-import'.
|
||||
|
||||
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'.
|
||||
'git filter-branch'.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
--progress=<n>::
|
||||
Insert 'progress' statements every <n> objects, to be shown by
|
||||
'git-fast-import' during import.
|
||||
'git fast-import' during import.
|
||||
|
||||
--signed-tags=(verbatim|warn|strip|abort)::
|
||||
Specify how to handle signed tags. Since any transformation
|
||||
|
|
@ -91,8 +91,8 @@ marks the same across runs.
|
|||
already contains the necessary objects.
|
||||
|
||||
[git-rev-list-args...]::
|
||||
A list of arguments, acceptable to 'git-rev-parse' and
|
||||
'git-rev-list', that specifies the specific objects and references
|
||||
A list of arguments, acceptable to 'git rev-parse' and
|
||||
'git rev-list', that specifies the specific objects and references
|
||||
to export. For example, `master\~10..master` causes the
|
||||
current master reference to be exported along with all objects
|
||||
added since its 10th ancestor commit.
|
||||
|
|
@ -125,7 +125,7 @@ referenced by that revision range contains the string
|
|||
Limitations
|
||||
-----------
|
||||
|
||||
Since 'git-fast-import' cannot tag trees, you will not be
|
||||
Since 'git fast-import' cannot tag trees, you will not be
|
||||
able to export the linux-2.6.git repository completely, as it contains
|
||||
a tag referencing a tree instead of a commit.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ DESCRIPTION
|
|||
This program is usually not what the end user wants to run directly.
|
||||
Most end users want to use one of the existing frontend programs,
|
||||
which parses a specific type of foreign source and feeds the contents
|
||||
stored there to 'git-fast-import'.
|
||||
stored there to 'git fast-import'.
|
||||
|
||||
fast-import reads a mixed command/data stream from standard input and
|
||||
writes one or more packfiles directly into the current repository.
|
||||
|
|
@ -24,7 +24,7 @@ updated branch and tag refs, fully updating the current repository
|
|||
with the newly imported data.
|
||||
|
||||
The fast-import backend itself can import into an empty repository (one that
|
||||
has already been initialized by 'git-init') or incrementally
|
||||
has already been initialized by 'git init') or incrementally
|
||||
update an existing populated repository. Whether or not incremental
|
||||
imports are supported from a particular foreign source depends on
|
||||
the frontend program in use.
|
||||
|
|
@ -75,6 +75,20 @@ OPTIONS
|
|||
set of marks. If a mark is defined to different values,
|
||||
the last file wins.
|
||||
|
||||
--relative-marks::
|
||||
After specifying --relative-marks= the paths specified
|
||||
with --import-marks= and --export-marks= are relative
|
||||
to an internal directory in the current repository.
|
||||
In git-fast-import this means that the paths are relative
|
||||
to the .git/info/fast-import directory. However, other
|
||||
importers may use a different location.
|
||||
|
||||
--no-relative-marks::
|
||||
Negates a previous --relative-marks. Allows for combining
|
||||
relative and non-relative marks by interweaving
|
||||
--(no-)-relative-marks= with the --(import|export)-marks=
|
||||
options.
|
||||
|
||||
--export-pack-edges=<file>::
|
||||
After creating a packfile, print a line of data to
|
||||
<file> listing the filename of the packfile and the last
|
||||
|
|
@ -82,7 +96,7 @@ OPTIONS
|
|||
This information may be useful after importing projects
|
||||
whose total object set exceeds the 4 GiB packfile limit,
|
||||
as these commits can be used as edge points during calls
|
||||
to 'git-pack-objects'.
|
||||
to 'git pack-objects'.
|
||||
|
||||
--quiet::
|
||||
Disable all non-fatal output, making fast-import silent when it
|
||||
|
|
@ -124,9 +138,9 @@ an ideal situation, given that most conversion tools are throw-away
|
|||
|
||||
Parallel Operation
|
||||
------------------
|
||||
Like 'git-push' or 'git-fetch', imports handled by fast-import are safe to
|
||||
Like 'git push' or 'git fetch', imports handled by fast-import are safe to
|
||||
run alongside parallel `git repack -a -d` or `git gc` invocations,
|
||||
or any other Git operation (including 'git-prune', as loose objects
|
||||
or any other Git operation (including 'git prune', as loose objects
|
||||
are never used by fast-import).
|
||||
|
||||
fast-import does not lock the branch or tag refs it is actively importing.
|
||||
|
|
@ -220,7 +234,7 @@ variation in formatting will cause fast-import to reject the value.
|
|||
+
|
||||
An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git
|
||||
parser is accurate, but a little on the lenient side. It is the
|
||||
same parser used by 'git-am' when applying patches
|
||||
same parser used by 'git am' when applying patches
|
||||
received from email.
|
||||
+
|
||||
Some malformed strings may be accepted as valid dates. In some of
|
||||
|
|
@ -256,7 +270,7 @@ timezone.
|
|||
This particular format is supplied as its short to implement and
|
||||
may be useful to a process that wants to create a new commit
|
||||
right now, without needing to use a working directory or
|
||||
'git-update-index'.
|
||||
'git update-index'.
|
||||
+
|
||||
If separate `author` and `committer` commands are used in a `commit`
|
||||
the timestamps may not match, as the system clock will be polled
|
||||
|
|
@ -303,6 +317,15 @@ and control the current import process. More detailed discussion
|
|||
standard output. This command is optional and is not needed
|
||||
to perform an import.
|
||||
|
||||
`feature`::
|
||||
Require that fast-import supports the specified feature, or
|
||||
abort if it does not.
|
||||
|
||||
`option`::
|
||||
Specify any of the options listed under OPTIONS that do not
|
||||
change stream semantic to suit the frontend's needs. This
|
||||
command is optional and is not needed to perform an import.
|
||||
|
||||
`commit`
|
||||
~~~~~~~~
|
||||
Create or update a branch with a new commit, recording one logical
|
||||
|
|
@ -690,7 +713,7 @@ recommended, as the frontend does not (easily) have access to the
|
|||
complete set of bytes which normally goes into such a signature.
|
||||
If signing is required, create lightweight tags from within fast-import with
|
||||
`reset`, then create the annotated versions of those tags offline
|
||||
with the standard 'git-tag' process.
|
||||
with the standard 'git tag' process.
|
||||
|
||||
`reset`
|
||||
~~~~~~~
|
||||
|
|
@ -846,6 +869,62 @@ Placing a `progress` command immediately after a `checkpoint` will
|
|||
inform the reader when the `checkpoint` has been completed and it
|
||||
can safely access the refs that fast-import updated.
|
||||
|
||||
`feature`
|
||||
~~~~~~~~~
|
||||
Require that fast-import supports the specified feature, or abort if
|
||||
it does not.
|
||||
|
||||
....
|
||||
'feature' SP <feature> LF
|
||||
....
|
||||
|
||||
The <feature> part of the command may be any string matching
|
||||
^[a-zA-Z][a-zA-Z-]*$ and should be understood by fast-import.
|
||||
|
||||
Feature work identical as their option counterparts with the
|
||||
exception of the import-marks feature, see below.
|
||||
|
||||
The following features are currently supported:
|
||||
|
||||
* date-format
|
||||
* import-marks
|
||||
* export-marks
|
||||
* relative-marks
|
||||
* no-relative-marks
|
||||
* force
|
||||
|
||||
The import-marks behaves differently from when it is specified as
|
||||
commandline option in that only one "feature import-marks" is allowed
|
||||
per stream. Also, any --import-marks= specified on the commandline
|
||||
will override those from the stream (if any).
|
||||
|
||||
`option`
|
||||
~~~~~~~~
|
||||
Processes the specified option so that git fast-import behaves in a
|
||||
way that suits the frontend's needs.
|
||||
Note that options specified by the frontend are overridden by any
|
||||
options the user may specify to git fast-import itself.
|
||||
|
||||
....
|
||||
'option' SP <option> LF
|
||||
....
|
||||
|
||||
The `<option>` part of the command may contain any of the options
|
||||
listed in the OPTIONS section that do not change import semantics,
|
||||
without the leading '--' and is treated in the same way.
|
||||
|
||||
Option commands must be the first commands on the input (not counting
|
||||
feature commands), to give an option command after any non-option
|
||||
command is an error.
|
||||
|
||||
The following commandline options change import semantics and may therefore
|
||||
not be passed as option:
|
||||
|
||||
* date-format
|
||||
* import-marks
|
||||
* export-marks
|
||||
* force
|
||||
|
||||
Crash Reports
|
||||
-------------
|
||||
If fast-import is supplied invalid input it will terminate with a
|
||||
|
|
@ -991,7 +1070,7 @@ is not `refs/heads/TAG_FIXUP`).
|
|||
|
||||
When committing fixups, consider using `merge` to connect the
|
||||
commit(s) which are supplying file revisions to the fixup branch.
|
||||
Doing so will allow tools such as 'git-blame' to track
|
||||
Doing so will allow tools such as 'git blame' to track
|
||||
through the real commit history and properly annotate the source
|
||||
files.
|
||||
|
||||
|
|
@ -1020,7 +1099,7 @@ Repacking Historical Data
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
If you are repacking very old imported data (e.g. older than the
|
||||
last year), consider expending some extra CPU time and supplying
|
||||
\--window=50 (or higher) when you run 'git-repack'.
|
||||
\--window=50 (or higher) when you run 'git repack'.
|
||||
This will take longer, but will also produce a smaller packfile.
|
||||
You only need to expend the effort once, and everyone using your
|
||||
project will benefit from the smaller repository.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ SYNOPSIS
|
|||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Usually you would want to use 'git-fetch', which is a
|
||||
Usually you would want to use 'git fetch', which is a
|
||||
higher level wrapper of this command, instead.
|
||||
|
||||
Invokes 'git-upload-pack' on a possibly remote repository
|
||||
|
|
@ -33,12 +33,12 @@ OPTIONS
|
|||
|
||||
-q::
|
||||
--quiet::
|
||||
Pass '-q' flag to 'git-unpack-objects'; this makes the
|
||||
Pass '-q' flag to 'git unpack-objects'; this makes the
|
||||
cloning process less verbose.
|
||||
|
||||
-k::
|
||||
--keep::
|
||||
Do not invoke 'git-unpack-objects' on received data, but
|
||||
Do not invoke 'git unpack-objects' on received data, but
|
||||
create a single packfile out of it instead, and store it
|
||||
in the object database. If provided twice then the pack is
|
||||
locked against repacking.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ along with the objects necessary to complete them.
|
|||
|
||||
The ref names and their object names of fetched refs are stored
|
||||
in `.git/FETCH_HEAD`. This information is left for a later merge
|
||||
operation done by 'git-merge'.
|
||||
operation done by 'git merge'.
|
||||
|
||||
When <refspec> stores the fetched result in tracking branches,
|
||||
the tags that point at these branches are automatically
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ OPTIONS
|
|||
--commit-filter <command>::
|
||||
This is the filter for performing the commit.
|
||||
If this filter is specified, it will be called instead of the
|
||||
'git-commit-tree' command, with arguments of the form
|
||||
'git commit-tree' command, with arguments of the form
|
||||
"<TREE_ID> [-p <PARENT_COMMIT_ID>]..." and the log message on
|
||||
stdin. The commit id is expected on stdout.
|
||||
+
|
||||
|
|
@ -127,10 +127,10 @@ have all of them as parents.
|
|||
You can use the 'map' convenience function in this filter, and other
|
||||
convenience functions, too. For example, calling 'skip_commit "$@"'
|
||||
will leave out the current commit (but not its changes! If you want
|
||||
that, use 'git-rebase' instead).
|
||||
that, use 'git rebase' instead).
|
||||
+
|
||||
You can also use the 'git_commit_non_empty_tree "$@"' instead of
|
||||
'git commit-tree "$@"' if you don't wish to keep commits with a single parent
|
||||
You can also use the `git_commit_non_empty_tree "$@"` instead of
|
||||
`git commit-tree "$@"` if you don't wish to keep commits with a single parent
|
||||
and that makes no change to the tree.
|
||||
|
||||
--tag-name-filter <command>::
|
||||
|
|
@ -179,7 +179,7 @@ the nearest ancestor that was not excluded.
|
|||
and only one parent, it will hence keep merges points. Also, this
|
||||
option is not compatible with the use of '--commit-filter'. Though you
|
||||
just need to use the function 'git_commit_non_empty_tree "$@"' instead
|
||||
of the 'git commit-tree "$@"' idiom in your commit filter to make that
|
||||
of the `git commit-tree "$@"` idiom in your commit filter to make that
|
||||
happen.
|
||||
|
||||
--original <namespace>::
|
||||
|
|
@ -196,15 +196,15 @@ the nearest ancestor that was not excluded.
|
|||
|
||||
-f::
|
||||
--force::
|
||||
'git-filter-branch' refuses to start with an existing temporary
|
||||
'git filter-branch' refuses to start with an existing temporary
|
||||
directory or when there are already refs starting with
|
||||
'refs/original/', unless forced.
|
||||
|
||||
<rev-list options>...::
|
||||
Arguments for 'git-rev-list'. All positive refs included by
|
||||
Arguments for 'git rev-list'. All positive refs included by
|
||||
these options are rewritten. You may also specify options
|
||||
such as '--all', but you must use '--' to separate them from
|
||||
the 'git-filter-branch' options.
|
||||
the 'git filter-branch' options.
|
||||
|
||||
|
||||
Examples
|
||||
|
|
@ -221,7 +221,7 @@ However, if the file is absent from the tree of some commit,
|
|||
a simple `rm filename` will fail for that tree and commit.
|
||||
Thus you may instead want to use `rm -f filename` as the script.
|
||||
|
||||
Using `\--index-filter` with 'git-rm' yields a significantly faster
|
||||
Using `\--index-filter` with 'git rm' yields a significantly faster
|
||||
version. Like with using `rm filename`, `git rm --cached filename`
|
||||
will fail if the file is absent from the tree of a commit. If you
|
||||
want to "completely forget" a file, it does not matter when it entered
|
||||
|
|
@ -303,7 +303,7 @@ and all children of the merge will become merge commits with P1,P2
|
|||
as their parents instead of the merge commit.
|
||||
|
||||
You can rewrite the commit log messages using `--msg-filter`. For
|
||||
example, 'git-svn-id' strings in a repository created by 'git-svn' can
|
||||
example, 'git svn-id' strings in a repository created by 'git svn' can
|
||||
be removed this way:
|
||||
|
||||
-------------------------------------------------------
|
||||
|
|
@ -314,7 +314,7 @@ git filter-branch --msg-filter '
|
|||
|
||||
To restrict rewriting to only part of the history, specify a revision
|
||||
range in addition to the new branch name. The new branch name will
|
||||
point to the top-most revision that a 'git-rev-list' of this range
|
||||
point to the top-most revision that a 'git rev-list' of this range
|
||||
will print.
|
||||
|
||||
If you need to add 'Acked-by' lines to, say, the last 10 commits (none
|
||||
|
|
@ -330,7 +330,7 @@ git filter-branch --msg-filter '
|
|||
*NOTE* the changes introduced by the commits, and which are not reverted
|
||||
by subsequent commits, will still be in the rewritten branch. If you want
|
||||
to throw out _changes_ together with the commits, you should use the
|
||||
interactive mode of 'git-rebase'.
|
||||
interactive mode of 'git rebase'.
|
||||
|
||||
|
||||
Consider this history:
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ DESCRIPTION
|
|||
-----------
|
||||
Takes the list of merged objects on stdin and produces a suitable
|
||||
commit message to be used for the merge commit, usually to be
|
||||
passed as the '<merge-message>' argument of 'git-merge'.
|
||||
passed as the '<merge-message>' argument of 'git merge'.
|
||||
|
||||
This command is intended mostly for internal use by scripts
|
||||
automatically invoking 'git merge'.
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ objecttype::
|
|||
The type of the object (`blob`, `tree`, `commit`, `tag`).
|
||||
|
||||
objectsize::
|
||||
The size of the object (the same as 'git-cat-file -s' reports).
|
||||
The size of the object (the same as 'git cat-file -s' reports).
|
||||
|
||||
objectname::
|
||||
The object name (aka SHA-1).
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ DESCRIPTION
|
|||
Prepare each commit with its patch in
|
||||
one file per commit, formatted to resemble UNIX mailbox format.
|
||||
The output of this command is convenient for e-mail submission or
|
||||
for use with 'git-am'.
|
||||
for use with 'git am'.
|
||||
|
||||
There are two ways to specify which commits to operate on.
|
||||
|
||||
|
|
@ -221,7 +221,7 @@ EXAMPLES
|
|||
--------
|
||||
|
||||
* Extract commits between revisions R1 and R2, and apply them on top of
|
||||
the current branch using 'git-am' to cherry-pick them:
|
||||
the current branch using 'git am' to cherry-pick them:
|
||||
+
|
||||
------------
|
||||
$ git format-patch -k --stdout R1..R2 | git am -3 -k
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ OPTIONS
|
|||
<object>::
|
||||
An object to treat as the head of an unreachability trace.
|
||||
+
|
||||
If no objects are given, 'git-fsck' defaults to using the
|
||||
If no objects are given, 'git fsck' defaults to using the
|
||||
index file, all SHA1 references in .git/refs/*, and all reflogs (unless
|
||||
--no-reflogs is given) as heads.
|
||||
|
||||
|
|
@ -85,7 +85,7 @@ So for example
|
|||
|
||||
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
|
||||
sorted properly etc), but on the whole if 'git-fsck' is happy, you
|
||||
sorted properly etc), but on the whole if 'git fsck' is happy, you
|
||||
do have a valid tree.
|
||||
|
||||
Any corrupt objects you will have to find in backups or other archives
|
||||
|
|
|
|||
|
|
@ -15,13 +15,13 @@ DESCRIPTION
|
|||
Runs a number of housekeeping tasks within the current repository,
|
||||
such as compressing file revisions (to reduce disk space and increase
|
||||
performance) and removing unreachable objects which may have been
|
||||
created from prior invocations of 'git-add'.
|
||||
created from prior invocations of 'git add'.
|
||||
|
||||
Users are encouraged to run this task on a regular basis within
|
||||
each repository to maintain good disk space utilization and good
|
||||
operating performance.
|
||||
|
||||
Some git commands may automatically run 'git-gc'; see the `--auto` flag
|
||||
Some git commands may automatically run 'git gc'; see the `--auto` flag
|
||||
below for details. If you know what you're doing and all you want is to
|
||||
disable this behavior permanently without further considerations, just do:
|
||||
|
||||
|
|
@ -33,15 +33,15 @@ OPTIONS
|
|||
-------
|
||||
|
||||
--aggressive::
|
||||
Usually 'git-gc' runs very quickly while providing good disk
|
||||
Usually 'git gc' runs very quickly while providing good disk
|
||||
space utilization and performance. This option will cause
|
||||
'git-gc' to more aggressively optimize the repository at the expense
|
||||
'git gc' to more aggressively optimize the repository at the expense
|
||||
of taking much more time. The effects of this optimization are
|
||||
persistent, so this option only needs to be used occasionally; every
|
||||
few hundred changesets or so.
|
||||
|
||||
--auto::
|
||||
With this option, 'git-gc' checks whether any housekeeping is
|
||||
With this option, 'git gc' checks whether any housekeeping is
|
||||
required; if not, it exits without performing any work.
|
||||
Some git commands run `git gc --auto` after performing
|
||||
operations that could create many loose objects.
|
||||
|
|
@ -50,13 +50,13 @@ Housekeeping is required if there are too many loose objects or
|
|||
too many packs in the repository. If the number of loose objects
|
||||
exceeds the value of the `gc.auto` configuration variable, then
|
||||
all loose objects are combined into a single pack using
|
||||
'git-repack -d -l'. Setting the value of `gc.auto` to 0
|
||||
`git repack -d -l`. Setting the value of `gc.auto` to 0
|
||||
disables automatic packing of loose objects.
|
||||
+
|
||||
If the number of packs exceeds the value of `gc.autopacklimit`,
|
||||
then existing packs (except those marked with a `.keep` file)
|
||||
are consolidated into a single pack by using the `-A` option of
|
||||
'git-repack'. Setting `gc.autopacklimit` to 0 disables
|
||||
'git repack'. Setting `gc.autopacklimit` to 0 disables
|
||||
automatic consolidation of packs.
|
||||
|
||||
--prune=<date>::
|
||||
|
|
@ -97,7 +97,7 @@ how long records of conflicted merge you have not resolved are
|
|||
kept. This defaults to 15 days.
|
||||
|
||||
The optional configuration variable 'gc.packrefs' determines if
|
||||
'git-gc' runs 'git-pack-refs'. This can be set to "nobare" to enable
|
||||
'git gc' runs 'git pack-refs'. This can be set to "nobare" to enable
|
||||
it within all non-bare repos or it can be set to a boolean value.
|
||||
This defaults to true.
|
||||
|
||||
|
|
@ -116,10 +116,10 @@ default is "2 weeks ago".
|
|||
Notes
|
||||
-----
|
||||
|
||||
'git-gc' tries very hard to be safe about the garbage it collects. In
|
||||
'git gc' tries very hard to be safe about the garbage it collects. In
|
||||
particular, it will keep not only objects referenced by your current set
|
||||
of branches and tags, but also objects referenced by the index, remote
|
||||
tracking branches, refs saved by 'git-filter-branch' in
|
||||
tracking branches, refs saved by 'git filter-branch' in
|
||||
refs/original/, or reflogs (which may reference commits in branches
|
||||
that were later amended or rewound).
|
||||
|
||||
|
|
|
|||
|
|
@ -14,12 +14,12 @@ SYNOPSIS
|
|||
DESCRIPTION
|
||||
-----------
|
||||
Acts as a filter, extracting the commit ID stored in archives created by
|
||||
'git-archive'. It reads only the first 1024 bytes of input, thus its
|
||||
'git archive'. It reads only the first 1024 bytes of input, thus its
|
||||
runtime is not influenced by the size of <tarfile> very much.
|
||||
|
||||
If no commit ID is found, 'git-get-tar-commit-id' quietly exists with a
|
||||
If no commit ID is found, 'git get-tar-commit-id' quietly exists with a
|
||||
return code of 1. This can happen if <tarfile> had not been created
|
||||
using 'git-archive' or if the first parameter of 'git-archive' had been
|
||||
using 'git archive' or if the first parameter of 'git archive' had been
|
||||
a tree ID instead of a commit ID or tag.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ OPTIONS
|
|||
--files-without-match::
|
||||
Instead of showing every matched line, show only the
|
||||
names of files that contain (or do not contain) matches.
|
||||
For better compatibility with 'git-diff', --name-only is a
|
||||
For better compatibility with 'git diff', --name-only is a
|
||||
synonym for --files-with-matches.
|
||||
|
||||
-z::
|
||||
|
|
|
|||
|
|
@ -11,19 +11,19 @@ SYNOPSIS
|
|||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
A Tcl/Tk based graphical user interface to Git. 'git-gui' focuses
|
||||
A Tcl/Tk based graphical user interface to Git. 'git gui' focuses
|
||||
on allowing users to make changes to their repository by making
|
||||
new commits, amending existing ones, creating branches, performing
|
||||
local merges, and fetching/pushing to remote repositories.
|
||||
|
||||
Unlike 'gitk', 'git-gui' focuses on commit generation
|
||||
Unlike 'gitk', 'git gui' focuses on commit generation
|
||||
and single file annotation and does not show project history.
|
||||
It does however supply menu actions to start a 'gitk' session from
|
||||
within 'git-gui'.
|
||||
within 'git gui'.
|
||||
|
||||
'git-gui' is known to work on all popular UNIX systems, Mac OS X,
|
||||
'git gui' is known to work on all popular UNIX systems, Mac OS X,
|
||||
and Windows (under both Cygwin and MSYS). To the extent possible
|
||||
OS specific user interface guidelines are followed, making 'git-gui'
|
||||
OS specific user interface guidelines are followed, making 'git gui'
|
||||
a fairly native interface for users.
|
||||
|
||||
COMMANDS
|
||||
|
|
@ -38,13 +38,13 @@ browser::
|
|||
browser are opened in the blame viewer.
|
||||
|
||||
citool::
|
||||
Start 'git-gui' and arrange to make exactly one commit before
|
||||
Start 'git gui' and arrange to make exactly one commit before
|
||||
exiting and returning to the shell. The interface is limited
|
||||
to only commit actions, slightly reducing the application's
|
||||
startup time and simplifying the menubar.
|
||||
|
||||
version::
|
||||
Display the currently running version of 'git-gui'.
|
||||
Display the currently running version of 'git gui'.
|
||||
|
||||
|
||||
Examples
|
||||
|
|
@ -103,15 +103,15 @@ SEE ALSO
|
|||
linkgit:gitk[1]::
|
||||
The git repository browser. Shows branches, commit history
|
||||
and file differences. gitk is the utility started by
|
||||
'git-gui''s Repository Visualize actions.
|
||||
'git gui''s Repository Visualize actions.
|
||||
|
||||
Other
|
||||
-----
|
||||
'git-gui' is actually maintained as an independent project, but stable
|
||||
'git gui' is actually maintained as an independent project, but stable
|
||||
versions are distributed as part of the Git suite for the convenience
|
||||
of end users.
|
||||
|
||||
A 'git-gui' development repository can be obtained from:
|
||||
A 'git gui' development repository can be obtained from:
|
||||
|
||||
git clone git://repo.or.cz/git-gui.git
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Computes the object ID value for an object with specified type
|
|||
with the contents of the named file (which can be outside of the
|
||||
work tree), and optionally writes the resulting object into the
|
||||
object database. Reports its object ID to its standard output.
|
||||
This is used by 'git-cvsimport' to update the index
|
||||
This is used by 'git cvsimport' to update the index
|
||||
without modifying files in the work tree. When <type> is not
|
||||
specified, it defaults to "blob".
|
||||
|
||||
|
|
|
|||
|
|
@ -55,8 +55,8 @@ other display programs (see below).
|
|||
+
|
||||
The web browser can be specified using the configuration variable
|
||||
'help.browser', or 'web.browser' if the former is not set. If none of
|
||||
these config variables is set, the 'git-web--browse' helper script
|
||||
(called by 'git-help') will pick a suitable default. See
|
||||
these config variables is set, the 'git web--browse' helper script
|
||||
(called by 'git help') will pick a suitable default. See
|
||||
linkgit:git-web--browse[1] for more information about this.
|
||||
|
||||
CONFIGURATION VARIABLES
|
||||
|
|
@ -67,7 +67,7 @@ help.format
|
|||
|
||||
If no command line option is passed, the 'help.format' configuration
|
||||
variable will be checked. The following values are supported for this
|
||||
variable; they make 'git-help' behave as their corresponding command
|
||||
variable; they make 'git help' behave as their corresponding command
|
||||
line option:
|
||||
|
||||
* "man" corresponds to '-m|--man',
|
||||
|
|
@ -122,7 +122,7 @@ man.<tool>.path
|
|||
You can explicitly provide a full path to your preferred man viewer by
|
||||
setting the configuration variable 'man.<tool>.path'. For example, you
|
||||
can configure the absolute path to konqueror by setting
|
||||
'man.konqueror.path'. Otherwise, 'git-help' assumes the tool is
|
||||
'man.konqueror.path'. Otherwise, 'git help' assumes the tool is
|
||||
available in PATH.
|
||||
|
||||
man.<tool>.cmd
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ git-http-backend - Server side implementation of Git over HTTP
|
|||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git-http-backend'
|
||||
'git http-backend'
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
|
@ -18,11 +18,16 @@ The program supports clients fetching using both the smart HTTP protcol
|
|||
and the backwards-compatible dumb HTTP protocol, as well as clients
|
||||
pushing using the smart HTTP protocol.
|
||||
|
||||
It verifies that the directory has the magic file
|
||||
"git-daemon-export-ok", and it will refuse to export any git directory
|
||||
that hasn't explicitly been marked for export this way (unless the
|
||||
GIT_HTTP_EXPORT_ALL environmental variable is set).
|
||||
|
||||
By default, only the `upload-pack` service is enabled, which serves
|
||||
'git-fetch-pack' and 'git-ls-remote' clients, which are invoked from
|
||||
'git-fetch', 'git-pull', and 'git-clone'. If the client is authenticated,
|
||||
the `receive-pack` service is enabled, which serves 'git-send-pack'
|
||||
clients, which is invoked from 'git-push'.
|
||||
'git fetch-pack' and 'git ls-remote' clients, which are invoked from
|
||||
'git fetch', 'git pull', and 'git clone'. If the client is authenticated,
|
||||
the `receive-pack` service is enabled, which serves 'git send-pack'
|
||||
clients, which is invoked from 'git push'.
|
||||
|
||||
SERVICES
|
||||
--------
|
||||
|
|
@ -38,12 +43,12 @@ http.getanyfile::
|
|||
by setting this configuration item to `false`.
|
||||
|
||||
http.uploadpack::
|
||||
This serves 'git-fetch-pack' and 'git-ls-remote' clients.
|
||||
This serves 'git fetch-pack' and 'git ls-remote' clients.
|
||||
It is enabled by default, but a repository can disable it
|
||||
by setting this configuration item to `false`.
|
||||
|
||||
http.receivepack::
|
||||
This serves 'git-send-pack' clients, allowing push. It is
|
||||
This serves 'git send-pack' clients, allowing push. It is
|
||||
disabled by default for anonymous users, and enabled by
|
||||
default for users authenticated by the web server. It can be
|
||||
disabled by setting this item to `false`, or enabled for all
|
||||
|
|
@ -51,11 +56,11 @@ http.receivepack::
|
|||
|
||||
URL TRANSLATION
|
||||
---------------
|
||||
To determine the location of the repository on disk, 'git-http-backend'
|
||||
To determine the location of the repository on disk, 'git http-backend'
|
||||
concatenates the environment variables PATH_INFO, which is set
|
||||
automatically by the web server, and GIT_PROJECT_ROOT, which must be set
|
||||
manually in the web server configuration. If GIT_PROJECT_ROOT is not
|
||||
set, 'git-http-backend' reads PATH_TRANSLATED, which is also set
|
||||
set, 'git http-backend' reads PATH_TRANSLATED, which is also set
|
||||
automatically by the web server.
|
||||
|
||||
EXAMPLES
|
||||
|
|
@ -70,6 +75,7 @@ Apache 2.x::
|
|||
+
|
||||
----------------------------------------------------------------
|
||||
SetEnv GIT_PROJECT_ROOT /var/www/git
|
||||
SetEnv GIT_HTTP_EXPORT_ALL
|
||||
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
|
||||
----------------------------------------------------------------
|
||||
+
|
||||
|
|
@ -98,7 +104,7 @@ directive around the repository, or one of its parent directories:
|
|||
----------------------------------------------------------------
|
||||
+
|
||||
To serve gitweb at the same url, use a ScriptAliasMatch to only
|
||||
those URLs that 'git-http-backend' can handle, and forward the
|
||||
those URLs that 'git http-backend' can handle, and forward the
|
||||
rest to gitweb:
|
||||
+
|
||||
----------------------------------------------------------------
|
||||
|
|
@ -147,7 +153,7 @@ ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
|
|||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
'git-http-backend' relies upon the CGI environment variables set
|
||||
'git http-backend' relies upon the CGI environment variables set
|
||||
by the invoking web server, including:
|
||||
|
||||
* PATH_INFO (if GIT_PROJECT_ROOT is set, otherwise PATH_TRANSLATED)
|
||||
|
|
@ -157,6 +163,10 @@ by the invoking web server, including:
|
|||
* QUERY_STRING
|
||||
* REQUEST_METHOD
|
||||
|
||||
The GIT_HTTP_EXPORT_ALL environmental variable may be passed to
|
||||
'git-http-backend' to bypass the check for the "git-daemon-export-ok"
|
||||
file in each repository before allowing export of that repository.
|
||||
|
||||
The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and
|
||||
GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}',
|
||||
ensuring that any reflogs created by 'git-receive-pack' contain some
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ commit-id::
|
|||
|
||||
--stdin::
|
||||
Instead of a commit id on the command line (which is not expected in this
|
||||
case), 'git-http-fetch' expects lines on stdin in the format
|
||||
case), 'git http-fetch' expects lines on stdin in the format
|
||||
|
||||
<commit-id>['\t'<filename-as-in--w>]
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ SYNOPSIS
|
|||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
This command uploads a mailbox generated with 'git-format-patch'
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -43,10 +43,10 @@ OPTIONS
|
|||
a default name determined from the pack content. If
|
||||
<pack-file> is not specified consider using --keep to
|
||||
prevent a race condition between this process and
|
||||
'git-repack'.
|
||||
'git repack'.
|
||||
|
||||
--fix-thin::
|
||||
It is possible for 'git-pack-objects' to build
|
||||
It is possible for 'git pack-objects' to build
|
||||
"thin" pack, which records objects in deltified form based on
|
||||
objects not included in the pack to reduce network traffic.
|
||||
Those objects are expected to be present on the receiving end
|
||||
|
|
@ -59,7 +59,7 @@ OPTIONS
|
|||
Before moving the index into its final destination
|
||||
create an empty .keep file for the associated pack file.
|
||||
This option is usually necessary with --stdin to prevent a
|
||||
simultaneous 'git-repack' process from deleting
|
||||
simultaneous 'git repack' process from deleting
|
||||
the newly constructed pack and index before refs can be
|
||||
updated to use objects contained in the pack.
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ Once the index has been created, the list of object names is sorted
|
|||
and the SHA1 hash of that list is printed to stdout. If --stdin was
|
||||
also used then this is prefixed by either "pack\t", or "keep\t" if a
|
||||
new .keep file was successfully created. This is useful to remove a
|
||||
.keep file used as a lock to prevent the race with 'git-repack'
|
||||
.keep file used as a lock to prevent the race with 'git repack'
|
||||
mentioned above.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -95,11 +95,11 @@ If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY`
|
|||
environment variable then the sha1 directories are created underneath -
|
||||
otherwise the default `$GIT_DIR/objects` directory is used.
|
||||
|
||||
Running 'git-init' in an existing repository is safe. It will not overwrite
|
||||
things that are already there. The primary reason for rerunning 'git-init'
|
||||
Running 'git init' in an existing repository is safe. It will not overwrite
|
||||
things that are already there. The primary reason for rerunning 'git init'
|
||||
is to pick up newly added templates.
|
||||
|
||||
Note that 'git-init' is the same as 'git-init-db'. The command
|
||||
Note that 'git init' is the same as 'git init-db'. The command
|
||||
was primarily meant to initialize the object database, but over
|
||||
time it has become responsible for setting up the other aspects
|
||||
of the repository, such as installing the default hooks and
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ OPTIONS
|
|||
-b::
|
||||
--browser::
|
||||
The web browser that should be used to view the gitweb
|
||||
page. This will be passed to the 'git-web--browse' helper
|
||||
page. This will be passed to the 'git web--browse' helper
|
||||
script along with the URL of the gitweb instance. See
|
||||
linkgit:git-web--browse[1] for more information about this. If
|
||||
the script fails, the URL will be printed to stdout.
|
||||
|
|
|
|||
|
|
@ -14,9 +14,9 @@ DESCRIPTION
|
|||
-----------
|
||||
Shows the commit logs.
|
||||
|
||||
The command takes options applicable to the 'git-rev-list'
|
||||
The command takes options applicable to the 'git rev-list'
|
||||
command to control what is shown and how, and options applicable to
|
||||
the 'git-diff-*' commands to control how the changes
|
||||
the 'git diff-*' commands to control how the changes
|
||||
each commit introduces are shown.
|
||||
|
||||
|
||||
|
|
@ -107,6 +107,17 @@ git log --follow builtin-rev-list.c::
|
|||
those commits that occurred before the file was given its
|
||||
present name.
|
||||
|
||||
git log --branches --not --remotes=origin::
|
||||
|
||||
Shows all commits that are in any of local branches but not in
|
||||
any of remote tracking branches for 'origin' (what you have that
|
||||
origin doesn't).
|
||||
|
||||
git log master --not --remotes=*/master::
|
||||
|
||||
Shows all commits that are in local master but not in any remote
|
||||
repository master branches.
|
||||
|
||||
Discussion
|
||||
----------
|
||||
|
||||
|
|
|
|||
|
|
@ -109,6 +109,7 @@ OPTIONS
|
|||
Identify the file status with the following tags (followed by
|
||||
a space) at the start of each line:
|
||||
H:: cached
|
||||
S:: skip-worktree
|
||||
M:: unmerged
|
||||
R:: removed/deleted
|
||||
C:: modified/changed
|
||||
|
|
@ -140,12 +141,12 @@ OPTIONS
|
|||
|
||||
Output
|
||||
------
|
||||
show files just outputs the filename unless '--stage' is specified in
|
||||
'git ls-files' just outputs the filenames unless '--stage' is specified in
|
||||
which case it outputs:
|
||||
|
||||
[<tag> ]<mode> <object> <stage> <file>
|
||||
|
||||
'git-ls-files --unmerged' and 'git-ls-files --stage' can be used to examine
|
||||
'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine
|
||||
detailed information on unmerged paths.
|
||||
|
||||
For an unmerged path, instead of recording a single mode/SHA1 pair,
|
||||
|
|
@ -162,7 +163,7 @@ respectively.
|
|||
Exclude Patterns
|
||||
----------------
|
||||
|
||||
'git-ls-files' can use a list of "exclude patterns" when
|
||||
'git ls-files' can use a list of "exclude patterns" when
|
||||
traversing the directory tree and finding files to show when the
|
||||
flags --others or --ignored are specified. linkgit:gitignore[5]
|
||||
specifies the format of exclude patterns.
|
||||
|
|
@ -178,7 +179,7 @@ These exclude patterns come from these places, in order:
|
|||
in the same order they appear in the file.
|
||||
|
||||
3. command line flag --exclude-per-directory=<name> specifies
|
||||
a name of the file in each directory 'git-ls-files'
|
||||
a name of the file in each directory 'git ls-files'
|
||||
examines, normally `.gitignore`. Files in deeper
|
||||
directories take precedence. Patterns are ordered in the
|
||||
same order they appear in the files.
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ in the current working directory. Note that:
|
|||
in a directory 'sub' that has a directory 'dir', you can run 'git
|
||||
ls-tree -r HEAD dir' to list the contents of the tree (that is
|
||||
'sub/dir' in 'HEAD'). You don't want to give a tree that is not at the
|
||||
root level (e.g. 'git ls-tree -r HEAD:sub dir') in this case, as that
|
||||
root level (e.g. `git ls-tree -r HEAD:sub dir`) in this case, as that
|
||||
would result in asking for 'sub/sub/dir' in the 'HEAD' commit.
|
||||
However, the current working directory can be ignored by passing
|
||||
--full-tree option.
|
||||
|
|
@ -84,7 +84,7 @@ Output Format
|
|||
|
||||
Unless the `-z` option is used, TAB, LF, and backslash characters
|
||||
in pathnames are represented as `\t`, `\n`, and `\\`, respectively.
|
||||
This output format is compatible with what '--index-info --stdin' of
|
||||
This output format is compatible with what `--index-info --stdin` of
|
||||
'git update-index' expects.
|
||||
|
||||
When the `-l` option is used, format changes to
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ DESCRIPTION
|
|||
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'
|
||||
written out to the standard output to be used by 'git am'
|
||||
to create a commit. It is usually not necessary to use this
|
||||
command directly. See linkgit:git-am[1] instead.
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ OPTIONS
|
|||
whitespaces, (3) '[' up to ']', typically '[PATCH]', and
|
||||
then prepends "[PATCH] ". This flag forbids this
|
||||
munging, and is most useful when used to read back
|
||||
'git-format-patch -k' output.
|
||||
'git format-patch -k' output.
|
||||
|
||||
-b::
|
||||
When -k is not in effect, all leading strings bracketed with '['
|
||||
|
|
|
|||
|
|
@ -10,20 +10,21 @@ SYNOPSIS
|
|||
--------
|
||||
[verse]
|
||||
'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
|
||||
[-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file>
|
||||
[--ours|--theirs] [-p|--stdout] [-q|--quiet]
|
||||
<current-file> <base-file> <other-file>
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
'git-merge-file' 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
|
||||
`<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.
|
||||
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'
|
||||
in a common segment of lines. If a conflict is found, 'git merge-file'
|
||||
normally outputs a warning and brackets the conflict with lines containing
|
||||
<<<<<<< and >>>>>>> markers. A typical conflict will look like this:
|
||||
|
||||
|
|
@ -34,12 +35,14 @@ normally outputs a warning and brackets the conflict with lines containing
|
|||
>>>>>>> B
|
||||
|
||||
If there are conflicts, the user should edit the result and delete one of
|
||||
the alternatives.
|
||||
the alternatives. When `--ours` or `--theirs` option is in effect, however,
|
||||
these conflicts are resolved favouring lines from `<current-file>` or
|
||||
lines from `<other-file>` respectively.
|
||||
|
||||
The exit value of this program is negative on error, and the number of
|
||||
conflicts otherwise. If the merge was clean, the exit value is 0.
|
||||
|
||||
'git-merge-file' is designed to be a minimal clone of RCS 'merge'; that is, it
|
||||
'git merge-file' is designed to be a minimal clone of RCS 'merge'; that is, it
|
||||
implements all of RCS 'merge''s functionality which is needed by
|
||||
linkgit:git[1].
|
||||
|
||||
|
|
@ -62,6 +65,11 @@ OPTIONS
|
|||
-q::
|
||||
Quiet; do not warn about conflicts.
|
||||
|
||||
--ours::
|
||||
--theirs::
|
||||
Instead of leaving conflicts in the file, resolve conflicts
|
||||
favouring our (or their) side of the lines.
|
||||
|
||||
|
||||
EXAMPLES
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -36,14 +36,14 @@ OPTIONS
|
|||
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
|
||||
If 'git merge-index' is called with multiple <file>s (or -a) then it
|
||||
processes them in turn only stopping if merge returns a non-zero exit
|
||||
code.
|
||||
|
||||
Typically this is run with a script calling git's imitation of
|
||||
the 'merge' command from the RCS package.
|
||||
|
||||
A sample script called 'git-merge-one-file' is included in the
|
||||
A sample script called 'git merge-one-file' is included in the
|
||||
distribution.
|
||||
|
||||
ALERT ALERT ALERT! The git "merge object order" is different from the
|
||||
|
|
@ -68,10 +68,10 @@ or
|
|||
This is added AA in the branch B.
|
||||
fatal: merge program failed
|
||||
|
||||
where the latter example shows how 'git-merge-index' will stop trying to
|
||||
where the latter example shows how 'git merge-index' will stop trying to
|
||||
merge once anything has returned an error (i.e., `cat` returned an error
|
||||
for the AA file, because it didn't exist in the original, and thus
|
||||
'git-merge-index' didn't even try to merge the MM thing).
|
||||
'git merge-index' didn't even try to merge the MM thing).
|
||||
|
||||
Author
|
||||
------
|
||||
|
|
|
|||
|
|
@ -8,12 +8,12 @@ git-merge-one-file - The standard helper program to use with git-merge-index
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git-merge-one-file'
|
||||
'git merge-one-file'
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
This is the standard helper program to use with 'git-merge-index'
|
||||
to resolve a merge after the trivial merge done with 'git-read-tree -m'.
|
||||
This is the standard helper program to use with 'git merge-index'
|
||||
to resolve a merge after the trivial merge done with 'git read-tree -m'.
|
||||
|
||||
Author
|
||||
------
|
||||
|
|
|
|||
|
|
@ -10,17 +10,45 @@ SYNOPSIS
|
|||
--------
|
||||
[verse]
|
||||
'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
|
||||
[-m <msg>] <remote>...
|
||||
'git merge' <msg> HEAD <remote>...
|
||||
[--[no-]rerere-autoupdate] [-m <msg>] <commit>...
|
||||
'git merge' <msg> HEAD <commit>...
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
This is the top-level interface to the merge machinery
|
||||
which drives multiple merge strategy scripts.
|
||||
Incorporates changes from the named commits (since the time their
|
||||
histories diverged from the current branch) into the current
|
||||
branch. This command is used by 'git pull' to incorporate changes
|
||||
from another repository and can be used by hand to merge changes
|
||||
from one branch into another.
|
||||
|
||||
The second syntax (<msg> `HEAD` <remote>) is supported for
|
||||
Assume the following history exists and the current branch is
|
||||
"`master`":
|
||||
|
||||
------------
|
||||
A---B---C topic
|
||||
/
|
||||
D---E---F---G master
|
||||
------------
|
||||
|
||||
Then "`git merge topic`" will replay the changes made on the
|
||||
`topic` branch since it diverged from `master` (i.e., `E`) until
|
||||
its current commit (`C`) on top of `master`, and record the result
|
||||
in a new commit along with the names of the two parent commits and
|
||||
a log message from the user describing the changes.
|
||||
|
||||
------------
|
||||
A---B---C topic
|
||||
/ \
|
||||
D---E---F---G---H master
|
||||
------------
|
||||
|
||||
The second syntax (<msg> `HEAD` <commit>...) is supported for
|
||||
historical reasons. Do not use it from the command line or in
|
||||
new scripts. It is the same as `git merge -m <msg> <remote>`.
|
||||
new scripts. It is the same as `git merge -m <msg> <commit>...`.
|
||||
|
||||
*Warning*: Running 'git merge' with uncommitted changes is
|
||||
discouraged: while possible, it leaves you in a state that is hard to
|
||||
back out of in the case of a conflict.
|
||||
|
||||
|
||||
OPTIONS
|
||||
|
|
@ -33,93 +61,83 @@ include::merge-options.txt[]
|
|||
used to give a good default for automated 'git merge'
|
||||
invocations.
|
||||
|
||||
<remote>...::
|
||||
Other branch heads to merge into our branch. You need at
|
||||
least one <remote>. Specifying more than one <remote>
|
||||
obviously means you are trying an Octopus.
|
||||
--rerere-autoupdate::
|
||||
--no-rerere-autoupdate::
|
||||
Allow the rerere mechanism to update the index with the
|
||||
result of auto-conflict resolution if possible.
|
||||
|
||||
include::merge-strategies.txt[]
|
||||
<commit>...::
|
||||
Commits, usually other branch heads, to merge into our branch.
|
||||
You need at least one <commit>. Specifying more than one
|
||||
<commit> obviously means you are trying an Octopus.
|
||||
|
||||
|
||||
If you tried a merge which resulted in complex conflicts and
|
||||
want to start over, you can recover with 'git-reset'.
|
||||
PRE-MERGE CHECKS
|
||||
----------------
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
include::merge-config.txt[]
|
||||
Before applying outside changes, you should get your own work in
|
||||
good shape and committed locally, so it will not be clobbered if
|
||||
there are conflicts. See also linkgit:git-stash[1].
|
||||
'git pull' and 'git merge' will stop without doing anything when
|
||||
local uncommitted changes overlap with files that 'git pull'/'git
|
||||
merge' may need to update.
|
||||
|
||||
branch.<name>.mergeoptions::
|
||||
Sets default options for merging into branch <name>. The syntax and
|
||||
supported options are the same as those of 'git merge', but option
|
||||
values containing whitespace characters are currently not supported.
|
||||
To avoid recording unrelated changes in the merge commit,
|
||||
'git pull' and 'git merge' will also abort if there are any changes
|
||||
registered in the index relative to the `HEAD` commit. (One
|
||||
exception is when the changed index entries are in the state that
|
||||
would result from the merge already.)
|
||||
|
||||
HOW MERGE WORKS
|
||||
---------------
|
||||
If all named commits are already ancestors of `HEAD`, 'git merge'
|
||||
will exit early with the message "Already up-to-date."
|
||||
|
||||
A merge is always between the current `HEAD` and one or more
|
||||
commits (usually, branch head or tag), and the index file must
|
||||
match the tree of `HEAD` commit (i.e. the contents of the last commit)
|
||||
when it starts out. In other words, `git diff --cached HEAD` must
|
||||
report no changes. (One exception is when the changed index
|
||||
entries are already in the same state that would result from
|
||||
the merge anyway.)
|
||||
FAST-FORWARD MERGE
|
||||
------------------
|
||||
|
||||
Three kinds of merge can happen:
|
||||
Often the current branch head is an ancestor of the named commit.
|
||||
This is the most common case especially when invoked from 'git
|
||||
pull': you are tracking an upstream repository, you have committed
|
||||
no local changes, and now you want to update to a newer upstream
|
||||
revision. In this case, a new commit is not needed to store the
|
||||
combined history; instead, the `HEAD` (along with the index) is
|
||||
updated to point at the named commit, without creating an extra
|
||||
merge commit.
|
||||
|
||||
* The merged commit is already contained in `HEAD`. This is the
|
||||
simplest case, called "Already up-to-date."
|
||||
This behavior can be suppressed with the `--no-ff` option.
|
||||
|
||||
* `HEAD` is already contained in the merged commit. This is the
|
||||
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 point at the merged
|
||||
commit, without creating an extra merge commit. This is
|
||||
called "Fast-forward".
|
||||
TRUE MERGE
|
||||
----------
|
||||
|
||||
* Both the merged commit and `HEAD` are independent and must be
|
||||
tied together by a merge commit that has both of them as its parents.
|
||||
The rest of this section describes this "True merge" case.
|
||||
Except in a fast-forward merge (see above), the branches to be
|
||||
merged must be tied together by a merge commit that has both of them
|
||||
as its parents.
|
||||
|
||||
The chosen merge strategy merges the two commits into a single
|
||||
new source tree.
|
||||
When things merge cleanly, this is what happens:
|
||||
A merged version reconciling the changes from all branches to be
|
||||
merged is committed, and your `HEAD`, index, and working tree are
|
||||
updated to it. It is possible to have modifications in the working
|
||||
tree as long as they do not overlap; the update will preserve them.
|
||||
|
||||
1. The results are updated both in the index file and in your
|
||||
working tree;
|
||||
2. Index file is written out as a tree;
|
||||
3. The tree gets committed; and
|
||||
4. The `HEAD` pointer gets advanced.
|
||||
When it is not obvious how to reconcile the changes, the following
|
||||
happens:
|
||||
|
||||
Because of 2., we require that the original state of the index
|
||||
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 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, the following happens:
|
||||
|
||||
1. `HEAD` stays the same.
|
||||
|
||||
2. Cleanly merged paths are updated both in the index file and
|
||||
1. The `HEAD` pointer stays the same.
|
||||
2. The `MERGE_HEAD` ref is set to point to the other branch head.
|
||||
3. Paths that merged cleanly are updated both in the index file and
|
||||
in your working tree.
|
||||
|
||||
3. For conflicting paths, the index file records up to three
|
||||
versions; stage1 stores the version from the common ancestor,
|
||||
stage2 from `HEAD`, and stage3 from the remote branch (you
|
||||
4. For conflicting paths, the index file records up to three
|
||||
versions: stage 1 stores the version from the common ancestor,
|
||||
stage 2 from `HEAD`, and stage 3 from `MERGE_HEAD` (you
|
||||
can inspect the stages with `git ls-files -u`). The working
|
||||
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
|
||||
merge results with familiar conflict markers `<<<` `===` `>>>`.
|
||||
5. No other changes are made. 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`.
|
||||
|
||||
If you tried a merge which resulted in complex conflicts and
|
||||
want to start over, you can recover with `git reset --merge`.
|
||||
|
||||
HOW CONFLICTS ARE PRESENTED
|
||||
---------------------------
|
||||
|
||||
|
|
@ -189,28 +207,30 @@ After seeing a conflict, you can do two things:
|
|||
|
||||
* 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
|
||||
up working tree changes made by 2. and 3.; `git-reset --hard` can
|
||||
be used for this.
|
||||
|
||||
* 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.
|
||||
'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
|
||||
* 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. `git diff` will show a three-way diff,
|
||||
highlighting changes from both the `HEAD` and `MERGE_HEAD`
|
||||
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 diffs from each branch. `git log --merge -p <path>`
|
||||
will show diffs first for the `HEAD` version and then the
|
||||
`MERGE_HEAD` 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.
|
||||
* 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 `MERGE_HEAD`
|
||||
version.
|
||||
|
||||
|
||||
EXAMPLES
|
||||
|
|
@ -245,6 +265,17 @@ changes into a merge commit. Small fixups like bumping
|
|||
release/version name would be acceptable.
|
||||
|
||||
|
||||
include::merge-strategies.txt[]
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
include::merge-config.txt[]
|
||||
|
||||
branch.<name>.mergeoptions::
|
||||
Sets default options for merging into branch <name>. The syntax and
|
||||
supported options are the same as those of 'git merge', but option
|
||||
values containing whitespace characters are currently not supported.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],
|
||||
|
|
|
|||
|
|
@ -13,11 +13,11 @@ DESCRIPTION
|
|||
-----------
|
||||
|
||||
Use `git mergetool` to run one of several merge utilities to resolve
|
||||
merge conflicts. It is typically run after 'git-merge'.
|
||||
merge conflicts. It is typically run after 'git merge'.
|
||||
|
||||
If one or more <file> parameters are given, the merge tool program will
|
||||
be run to resolve differences on each file. If no <file> names are
|
||||
specified, 'git-mergetool' will run the merge tool program on every file
|
||||
specified, 'git mergetool' will run the merge tool program on every file
|
||||
with merge conflicts.
|
||||
|
||||
OPTIONS
|
||||
|
|
@ -29,23 +29,23 @@ OPTIONS
|
|||
kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge,
|
||||
diffuse, tortoisemerge, opendiff, p4merge and araxis.
|
||||
+
|
||||
If a merge resolution program is not specified, 'git-mergetool'
|
||||
If a merge resolution program is not specified, 'git mergetool'
|
||||
will use the configuration variable `merge.tool`. If the
|
||||
configuration variable `merge.tool` is not set, 'git-mergetool'
|
||||
configuration variable `merge.tool` is not set, 'git mergetool'
|
||||
will pick a suitable default.
|
||||
+
|
||||
You can explicitly provide a full path to the tool by setting the
|
||||
configuration variable `mergetool.<tool>.path`. For example, you
|
||||
can configure the absolute path to kdiff3 by setting
|
||||
`mergetool.kdiff3.path`. Otherwise, 'git-mergetool' assumes the
|
||||
`mergetool.kdiff3.path`. Otherwise, 'git mergetool' assumes the
|
||||
tool is available in PATH.
|
||||
+
|
||||
Instead of running one of the known merge tool programs,
|
||||
'git-mergetool' can be customized to run an alternative program
|
||||
'git mergetool' can be customized to run an alternative program
|
||||
by specifying the command line to invoke in a configuration
|
||||
variable `mergetool.<tool>.cmd`.
|
||||
+
|
||||
When 'git-mergetool' is invoked with this tool (either through the
|
||||
When 'git mergetool' is invoked with this tool (either through the
|
||||
`-t` or `--tool` option or the `merge.tool` configuration
|
||||
variable) the configured command line will be invoked with `$BASE`
|
||||
set to the name of a temporary file containing the common base for
|
||||
|
|
@ -59,7 +59,7 @@ merge resolution.
|
|||
If the custom merge tool correctly indicates the success of a
|
||||
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
|
||||
Otherwise, 'git mergetool' will prompt the user to indicate the
|
||||
success of the resolution after the custom tool has exited.
|
||||
|
||||
-y::
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ SYNOPSIS
|
|||
DESCRIPTION
|
||||
-----------
|
||||
Finds symbolic names suitable for human digestion for revisions given in any
|
||||
format parsable by 'git-rev-parse'.
|
||||
format parsable by 'git rev-parse'.
|
||||
|
||||
|
||||
OPTIONS
|
||||
|
|
@ -55,7 +55,7 @@ wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
|
|||
Of course, you look into the commit, but that only tells you what happened, but
|
||||
not the context.
|
||||
|
||||
Enter 'git-name-rev':
|
||||
Enter 'git name-rev':
|
||||
|
||||
------------
|
||||
% git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ git-notes - Add/inspect commit notes
|
|||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git-notes' (edit [-F <file> | -m <msg>] | show) [commit]
|
||||
'git notes' (edit [-F <file> | -m <msg>] | show) [commit]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
|
|||
any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
|
||||
enables git to read from such an archive.
|
||||
|
||||
The 'git-unpack-objects' command can read the packed archive and
|
||||
The 'git unpack-objects' command can read the packed archive and
|
||||
expand the objects contained in the pack into "one-file
|
||||
one-object" format; this is typically done by the smart-pull
|
||||
commands when a pack is created on-the-fly for efficient network
|
||||
|
|
@ -61,7 +61,7 @@ base-name::
|
|||
--revs::
|
||||
Read the revision arguments from the standard input, instead of
|
||||
individual object names. The revision arguments are processed
|
||||
the same way as 'git-rev-list' with the `--objects` flag
|
||||
the same way as 'git rev-list' with the `--objects` flag
|
||||
uses its `commit` arguments to build the list of objects it
|
||||
outputs. The objects on the resulting list are packed.
|
||||
|
||||
|
|
@ -182,7 +182,7 @@ base-name::
|
|||
A packed archive can express base object of a delta as
|
||||
either 20-byte object name or as an offset in the
|
||||
stream, but older version of git does not understand the
|
||||
latter. By default, 'git-pack-objects' only uses the
|
||||
latter. By default, 'git pack-objects' only uses the
|
||||
former format for better compatibility. This option
|
||||
allows the command to use the latter format for
|
||||
compactness. Depending on the average delta chain
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ This program computes which packs in your repository
|
|||
are redundant. The output is suitable for piping to
|
||||
`xargs rm` if you are in the root of the repository.
|
||||
|
||||
'git-pack-redundant' accepts a list of objects on standard input. Any objects
|
||||
'git pack-redundant' accepts a list of objects on standard input. Any objects
|
||||
given will be ignored when checking which packs are required. This makes the
|
||||
following command useful when wanting to remove packs which contain unreachable
|
||||
objects.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ ID" are almost guaranteed to be the same thing.
|
|||
|
||||
IOW, you can use this thing to look for likely duplicate commits.
|
||||
|
||||
When dealing with 'git-diff-tree' output, it takes advantage of
|
||||
When dealing with 'git diff-tree' output, it takes advantage of
|
||||
the fact that the patch is prefixed with the object name of the
|
||||
commit, and outputs two 40-byte hexadecimal strings. The first
|
||||
string is the patch ID, and the second string is the commit ID.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ SYNOPSIS
|
|||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
This command is deprecated; use 'git-ls-remote' instead.
|
||||
This command is deprecated; use 'git ls-remote' instead.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
|
|
|||
|
|
@ -8,21 +8,21 @@ git-prune - Prune all unreachable objects from the object database
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git-prune' [-n] [-v] [--expire <expire>] [--] [<head>...]
|
||||
'git prune' [-n] [-v] [--expire <expire>] [--] [<head>...]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
NOTE: In most cases, users should run 'git-gc', which calls
|
||||
'git-prune'. See the section "NOTES", below.
|
||||
NOTE: In most cases, users should run 'git gc', which calls
|
||||
'git prune'. See the section "NOTES", below.
|
||||
|
||||
This runs 'git-fsck --unreachable' using all the refs
|
||||
This runs 'git fsck --unreachable' using all the refs
|
||||
available in `$GIT_DIR/refs`, optionally with additional set of
|
||||
objects specified on the command line, and prunes all unpacked
|
||||
objects unreachable from any of these head objects from the object database.
|
||||
In addition, it
|
||||
prunes the unpacked objects that are also found in packs by
|
||||
running 'git-prune-packed'.
|
||||
running 'git prune-packed'.
|
||||
|
||||
Note that unreachable, packed objects will remain. If this is
|
||||
not desired, see linkgit:git-repack[1].
|
||||
|
|
@ -62,12 +62,12 @@ $ git prune $(cd ../another && $(git rev-parse --all))
|
|||
Notes
|
||||
-----
|
||||
|
||||
In most cases, users will not need to call 'git-prune' directly, but
|
||||
should instead call 'git-gc', which handles pruning along with
|
||||
In most cases, users will not need to call 'git prune' directly, but
|
||||
should instead call 'git gc', which handles pruning along with
|
||||
many other housekeeping tasks.
|
||||
|
||||
For a description of which objects are considered for pruning, see
|
||||
'git-fsck''s --unreachable option.
|
||||
'git fsck''s --unreachable option.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -13,16 +13,20 @@ SYNOPSIS
|
|||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Runs 'git-fetch' with the given parameters, and calls 'git-merge'
|
||||
Runs 'git fetch' with the given parameters, and calls 'git merge'
|
||||
to merge the retrieved head(s) into the current branch.
|
||||
With `--rebase`, calls 'git-rebase' instead of 'git-merge'.
|
||||
With `--rebase`, calls 'git rebase' instead of 'git merge'.
|
||||
|
||||
Note that you can use `.` (current directory) as the
|
||||
<repository> to pull from the local repository -- this is useful
|
||||
when merging local branches into the current branch.
|
||||
|
||||
Also note that options meant for 'git-pull' itself and underlying
|
||||
'git-merge' must be given before the options meant for 'git-fetch'.
|
||||
Also note that options meant for 'git pull' itself and underlying
|
||||
'git merge' must be given before the options meant for 'git fetch'.
|
||||
|
||||
*Warning*: Running 'git pull' (actually, the underlying 'git merge')
|
||||
with uncommitted changes is discouraged: while possible, it leaves you
|
||||
in a state that is hard to back out of in the case of a conflict.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
|
@ -148,7 +152,7 @@ $ git merge origin/next
|
|||
|
||||
|
||||
If you tried a pull which resulted in a complex conflicts and
|
||||
would want to start over, you can recover with 'git-reset'.
|
||||
would want to start over, you can recover with 'git reset'.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ SYNOPSIS
|
|||
--------
|
||||
[verse]
|
||||
'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
|
||||
[--repo=<repository>] [-f | --force] [-v | --verbose]
|
||||
[--repo=<repository>] [-f | --force] [-v | --verbose] [-u | --set-upstream]
|
||||
[<repository> <refspec>...]
|
||||
|
||||
DESCRIPTION
|
||||
|
|
@ -91,6 +91,10 @@ nor in any Push line of the corresponding remotes file---see below).
|
|||
will be tab-separated and sent to stdout instead of stderr. The full
|
||||
symbolic names of the refs will be given.
|
||||
|
||||
--delete::
|
||||
All listed refs are deleted from the remote repository. This is
|
||||
the same as prefixing all refs with a colon.
|
||||
|
||||
--tags::
|
||||
All refs under `$GIT_DIR/refs/tags` are pushed, in
|
||||
addition to refspecs explicitly listed on the command
|
||||
|
|
@ -112,7 +116,7 @@ nor in any Push line of the corresponding remotes file---see below).
|
|||
|
||||
--repo=<repository>::
|
||||
This option is only relevant if no <repository> argument is
|
||||
passed in the invocation. In this case, 'git-push' derives the
|
||||
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
|
||||
|
|
@ -126,11 +130,18 @@ 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'.
|
||||
useful if you write an alias or script around 'git push'.
|
||||
|
||||
-u::
|
||||
--set-upstream::
|
||||
For every branch that is up to date or successfully pushed, add
|
||||
upstream (tracking) reference, used by argument-less
|
||||
linkgit:git-pull[1] and other commands. For more information,
|
||||
see 'branch.<name>.merge' in linkgit:git-config[1].
|
||||
|
||||
--thin::
|
||||
--no-thin::
|
||||
These options are passed to 'git-send-pack'. Thin
|
||||
These options are passed to 'git send-pack'. Thin
|
||||
transfer spends extra cycles to minimize the number of
|
||||
objects to be sent and meant to be used on slower connection.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ SYNOPSIS
|
|||
--------
|
||||
'git read-tree' [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>]
|
||||
[-u [--exclude-per-directory=<gitignore>] | -i]]
|
||||
[--index-output=<file>]
|
||||
[--index-output=<file>] [--no-sparse-checkout]
|
||||
<tree-ish1> [<tree-ish2> [<tree-ish3>]]
|
||||
|
||||
|
||||
|
|
@ -25,8 +25,8 @@ fast-forward (i.e. 2-way) merge, or a 3-way merge, with the `-m`
|
|||
flag. When used with `-m`, the `-u` flag causes it to also update
|
||||
the files in the work tree with the result of the merge.
|
||||
|
||||
Trivial merges are done by 'git-read-tree' itself. Only conflicting paths
|
||||
will be in unmerged state when 'git-read-tree' returns.
|
||||
Trivial merges are done by 'git read-tree' itself. Only conflicting paths
|
||||
will be in unmerged state when 'git read-tree' returns.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
|
@ -57,13 +57,13 @@ OPTIONS
|
|||
Show the progress of checking files out.
|
||||
|
||||
--trivial::
|
||||
Restrict three-way merge by 'git-read-tree' to happen
|
||||
Restrict three-way merge by 'git read-tree' to happen
|
||||
only if there is no file-level merging required, instead
|
||||
of resolving merge for trivial cases and leaving
|
||||
conflicting files unresolved in the index.
|
||||
|
||||
--aggressive::
|
||||
Usually a three-way merge by 'git-read-tree' resolves
|
||||
Usually a three-way merge by 'git read-tree' resolves
|
||||
the merge for really trivial cases and leaves other
|
||||
cases unresolved in the index, so that Porcelains can
|
||||
implement different merge policies. This flag makes the
|
||||
|
|
@ -110,13 +110,17 @@ OPTIONS
|
|||
directories the index file and index output file are
|
||||
located in.
|
||||
|
||||
--no-sparse-checkout::
|
||||
Disable sparse checkout support even if `core.sparseCheckout`
|
||||
is true.
|
||||
|
||||
<tree-ish#>::
|
||||
The id of the tree object(s) to be read/merged.
|
||||
|
||||
|
||||
Merging
|
||||
-------
|
||||
If `-m` is specified, 'git-read-tree' can perform 3 kinds of
|
||||
If `-m` is specified, 'git read-tree' can perform 3 kinds of
|
||||
merge, a single tree merge if only 1 tree is given, a
|
||||
fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
|
||||
provided.
|
||||
|
|
@ -124,18 +128,18 @@ provided.
|
|||
|
||||
Single Tree Merge
|
||||
~~~~~~~~~~~~~~~~~
|
||||
If only 1 tree is specified, 'git-read-tree' operates as if the user did not
|
||||
If only 1 tree is specified, 'git read-tree' operates as if the user did not
|
||||
specify `-m`, except that if the original index has an entry for a
|
||||
given pathname, and the contents of the path matches with the tree
|
||||
being read, the stat info from the index is used. (In other words, the
|
||||
index's stat()s take precedence over the merged tree's).
|
||||
|
||||
That means that if you do a `git read-tree -m <newtree>` followed by a
|
||||
`git checkout-index -f -u -a`, the 'git-checkout-index' only checks out
|
||||
`git checkout-index -f -u -a`, the 'git checkout-index' only checks out
|
||||
the stuff that really changed.
|
||||
|
||||
This is used to avoid unnecessary false hits when 'git-diff-files' is
|
||||
run after 'git-read-tree'.
|
||||
This is used to avoid unnecessary false hits when 'git diff-files' is
|
||||
run after 'git read-tree'.
|
||||
|
||||
|
||||
Two Tree Merge
|
||||
|
|
@ -146,7 +150,7 @@ is the head commit of the current repository, and $M is the head
|
|||
of a foreign tree, which is simply ahead of $H (i.e. we are in a
|
||||
fast-forward situation).
|
||||
|
||||
When two trees are specified, the user is telling 'git-read-tree'
|
||||
When two trees are specified, the user is telling 'git read-tree'
|
||||
the following:
|
||||
|
||||
1. The current index and work tree is derived from $H, but
|
||||
|
|
@ -199,10 +203,10 @@ Here are the "carry forward" rules:
|
|||
|
||||
In all "keep index" cases, the index entry stays as in the
|
||||
original index file. If the entry were not up to date,
|
||||
'git-read-tree' keeps the copy in the work tree intact when
|
||||
'git read-tree' keeps the copy in the work tree intact when
|
||||
operating under the -u flag.
|
||||
|
||||
When this form of 'git-read-tree' returns successfully, you can
|
||||
When this form of 'git read-tree' returns successfully, you can
|
||||
see what "local changes" you made are carried forward by running
|
||||
`git diff-index --cached $M`. Note that this does not
|
||||
necessarily match `git diff-index --cached $H` would have
|
||||
|
|
@ -225,7 +229,7 @@ of the path is kept as long as $H and $M are the same.
|
|||
Each "index" entry has two bits worth of "stage" state. stage 0 is the
|
||||
normal one, and is the only one you'd see in any kind of normal use.
|
||||
|
||||
However, when you do 'git-read-tree' with three trees, the "stage"
|
||||
However, when you do 'git read-tree' with three trees, the "stage"
|
||||
starts out at 1.
|
||||
|
||||
This means that you can do
|
||||
|
|
@ -241,7 +245,7 @@ branch into the current branch, we use the common ancestor tree
|
|||
as <tree1>, the current branch head as <tree2>, and the other
|
||||
branch head as <tree3>.
|
||||
|
||||
Furthermore, 'git-read-tree' has special-case logic that says: if you see
|
||||
Furthermore, 'git read-tree' has special-case logic that says: if you see
|
||||
a file that matches in all respects in the following states, it
|
||||
"collapses" back to "stage0":
|
||||
|
||||
|
|
@ -257,7 +261,7 @@ a file that matches in all respects in the following states, it
|
|||
- stage 1 and stage 3 are the same and stage 2 is different take
|
||||
stage 2 (we did something while they did nothing)
|
||||
|
||||
The 'git-write-tree' command refuses to write a nonsensical tree, and it
|
||||
The 'git write-tree' command refuses to write a nonsensical tree, and it
|
||||
will complain about unmerged entries if it sees a single entry that is not
|
||||
stage 0.
|
||||
|
||||
|
|
@ -273,7 +277,7 @@ start a 3-way merge with an index file that is already
|
|||
populated. Here is an outline of how the algorithm works:
|
||||
|
||||
- if a file exists in identical format in all three trees, it will
|
||||
automatically collapse to "merged" state by 'git-read-tree'.
|
||||
automatically collapse to "merged" state by 'git read-tree'.
|
||||
|
||||
- a file that has _any_ difference what-so-ever in the three trees
|
||||
will stay as separate entries in the index. It's up to "porcelain
|
||||
|
|
@ -297,8 +301,8 @@ populated. Here is an outline of how the algorithm works:
|
|||
matching "stage1" entry if it exists too. .. all the normal
|
||||
trivial rules ..
|
||||
|
||||
You would normally use 'git-merge-index' with supplied
|
||||
'git-merge-one-file' to do this last step. The script updates
|
||||
You would normally use 'git merge-index' with supplied
|
||||
'git merge-one-file' to do this last step. The script updates
|
||||
the files in the working tree as it merges each path and at the
|
||||
end of a successful merge.
|
||||
|
||||
|
|
@ -320,7 +324,7 @@ $ JC=`git rev-parse --verify "HEAD^0"`
|
|||
$ git checkout-index -f -u -a $JC
|
||||
----------------
|
||||
|
||||
You do random edits, without running 'git-update-index'. And then
|
||||
You do random edits, without running 'git update-index'. And then
|
||||
you notice that the tip of your "upstream" tree has advanced
|
||||
since you pulled from him:
|
||||
|
||||
|
|
@ -346,20 +350,66 @@ your work-in-progress changes, and your work tree would be
|
|||
updated to the result of the merge.
|
||||
|
||||
However, if you have local changes in the working tree that
|
||||
would be overwritten by this merge, 'git-read-tree' will refuse
|
||||
would be overwritten by this merge, 'git read-tree' will refuse
|
||||
to run to prevent your changes from being lost.
|
||||
|
||||
In other words, there is no need to worry about what exists only
|
||||
in the working tree. When you have local changes in a part of
|
||||
the project that is not involved in the merge, your changes do
|
||||
not interfere with the merge, and are kept intact. When they
|
||||
*do* interfere, the merge does not even start ('git-read-tree'
|
||||
*do* interfere, the merge does not even start ('git read-tree'
|
||||
complains loudly and fails without modifying anything). In such
|
||||
a case, you can simply continue doing what you were in the
|
||||
middle of doing, and when your working tree is ready (i.e. you
|
||||
have finished your work-in-progress), attempt the merge again.
|
||||
|
||||
|
||||
Sparse checkout
|
||||
---------------
|
||||
|
||||
"Sparse checkout" allows to sparsely populate working directory.
|
||||
It uses skip-worktree bit (see linkgit:git-update-index[1]) to tell
|
||||
Git whether a file on working directory is worth looking at.
|
||||
|
||||
"git read-tree" and other merge-based commands ("git merge", "git
|
||||
checkout"...) can help maintaining skip-worktree bitmap and working
|
||||
directory update. `$GIT_DIR/info/sparse-checkout` is used to
|
||||
define the skip-worktree reference bitmap. When "git read-tree" needs
|
||||
to update working directory, it will reset skip-worktree bit in index
|
||||
based on this file, which uses the same syntax as .gitignore files.
|
||||
If an entry matches a pattern in this file, skip-worktree will be
|
||||
set on that entry. Otherwise, skip-worktree will be unset.
|
||||
|
||||
Then it compares the new skip-worktree value with the previous one. If
|
||||
skip-worktree turns from unset to set, it will add the corresponding
|
||||
file back. If it turns from set to unset, that file will be removed.
|
||||
|
||||
While `$GIT_DIR/info/sparse-checkout` is usually used to specify what
|
||||
files are in. You can also specify what files are _not_ in, using
|
||||
negate patterns. For example, to remove file "unwanted":
|
||||
|
||||
----------------
|
||||
*
|
||||
!unwanted
|
||||
----------------
|
||||
|
||||
Another tricky thing is fully repopulating working directory when you
|
||||
no longer want sparse checkout. You cannot just disable "sparse
|
||||
checkout" because skip-worktree are still in the index and you working
|
||||
directory is still sparsely populated. You should re-populate working
|
||||
directory with the `$GIT_DIR/info/sparse-checkout` file content as
|
||||
follows:
|
||||
|
||||
----------------
|
||||
*
|
||||
----------------
|
||||
|
||||
Then you can disable sparse checkout. Sparse checkout support in "git
|
||||
read-tree" and similar commands is disabled by default. You need to
|
||||
turn `core.sparseCheckout` on in order to have sparse checkout
|
||||
support.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
linkgit:git-write-tree[1]; linkgit:git-ls-files[1];
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ SYNOPSIS
|
|||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
If <branch> is specified, 'git-rebase' will perform an automatic
|
||||
If <branch> is specified, 'git rebase' will perform an automatic
|
||||
`git checkout <branch>` before doing anything else. Otherwise
|
||||
it remains on the current branch.
|
||||
|
||||
|
|
@ -170,8 +170,8 @@ This is useful if F and G were flawed in some way, or should not be
|
|||
part of topicA. Note that the argument to --onto and the <upstream>
|
||||
parameter can be any valid commit-ish.
|
||||
|
||||
In case of conflict, 'git-rebase' will stop at the first problematic commit
|
||||
and leave conflict markers in the tree. You can use 'git-diff' to locate
|
||||
In case of conflict, 'git rebase' will stop at the first problematic commit
|
||||
and leave conflict markers in the tree. You can use 'git diff' to locate
|
||||
the markers (<<<<<<) and make edits to resolve the conflict. For each
|
||||
file you edit, you need to tell git that the conflict has been resolved,
|
||||
typically this would be done with
|
||||
|
|
@ -187,7 +187,7 @@ desired resolution, you can continue the rebasing process with
|
|||
git rebase --continue
|
||||
|
||||
|
||||
Alternatively, you can undo the 'git-rebase' with
|
||||
Alternatively, you can undo the 'git rebase' with
|
||||
|
||||
|
||||
git rebase --abort
|
||||
|
|
@ -238,10 +238,10 @@ other words, the sides are swapped.
|
|||
-s <strategy>::
|
||||
--strategy=<strategy>::
|
||||
Use the given merge strategy.
|
||||
If there is no `-s` option 'git-merge-recursive' is used
|
||||
If there is no `-s` option 'git merge-recursive' is used
|
||||
instead. This implies --merge.
|
||||
+
|
||||
Because 'git-rebase' replays each commit from the working branch
|
||||
Because 'git rebase' replays each commit from the working branch
|
||||
on top of the <upstream> branch using the given strategy, using
|
||||
the 'ours' strategy simply discards all patches from the <branch>,
|
||||
which makes little sense.
|
||||
|
|
@ -280,13 +280,13 @@ which makes little sense.
|
|||
|
||||
--ignore-whitespace::
|
||||
--whitespace=<option>::
|
||||
These flag are passed to the 'git-apply' program
|
||||
These flag are passed to the 'git apply' program
|
||||
(see linkgit:git-apply[1]) that applies the patch.
|
||||
Incompatible with the --interactive option.
|
||||
|
||||
--committer-date-is-author-date::
|
||||
--ignore-date::
|
||||
These flags are passed to 'git-am' to easily change the dates
|
||||
These flags are passed to 'git am' to easily change the dates
|
||||
of the rebased commits (see linkgit:git-am[1]).
|
||||
|
||||
-i::
|
||||
|
|
@ -308,12 +308,22 @@ which makes little sense.
|
|||
root commits will be rewritten to have <newbase> as parent
|
||||
instead.
|
||||
|
||||
--autosquash::
|
||||
When the commit log message begins with "squash! ..." (or
|
||||
"fixup! ..."), and there is a commit whose title begins with
|
||||
the same ..., automatically modify the todo list of rebase -i
|
||||
so that the commit marked for squashing comes right after the
|
||||
commit to be modified, and change the action of the moved
|
||||
commit from `pick` to `squash` (or `fixup`).
|
||||
+
|
||||
This option is only valid when '--interactive' option is used.
|
||||
|
||||
include::merge-strategies.txt[]
|
||||
|
||||
NOTES
|
||||
-----
|
||||
|
||||
You should understand the implications of using 'git-rebase' on a
|
||||
You should understand the implications of using 'git rebase' on a
|
||||
repository that you share. See also RECOVERING FROM UPSTREAM REBASE
|
||||
below.
|
||||
|
||||
|
|
@ -369,12 +379,12 @@ pick fa1afe1 The oneline of the next commit
|
|||
...
|
||||
-------------------------------------------
|
||||
|
||||
The oneline descriptions are purely for your pleasure; 'git-rebase' will
|
||||
The oneline descriptions are purely for your pleasure; 'git rebase' will
|
||||
not look at them but at the commit names ("deadbee" and "fa1afe1" in this
|
||||
example), so do not delete or edit the names.
|
||||
|
||||
By replacing the command "pick" with the command "edit", you can tell
|
||||
'git-rebase' to stop after applying that commit, so that you can edit
|
||||
'git rebase' to stop after applying that commit, so that you can edit
|
||||
the files and/or the commit message, amend the commit, and continue
|
||||
rebasing.
|
||||
|
||||
|
|
@ -382,17 +392,20 @@ If you just want to edit the commit message for a commit, replace the
|
|||
command "pick" with the command "reword".
|
||||
|
||||
If you want to fold two or more commits into one, replace the command
|
||||
"pick" with "squash" for the second and subsequent commit. If the
|
||||
commits had different authors, it will attribute the squashed commit to
|
||||
the author of the first commit.
|
||||
"pick" for the second and subsequent commits with "squash" or "fixup".
|
||||
If the commits had different authors, the folded commit will be
|
||||
attributed to the author of the first commit. The suggested commit
|
||||
message for the folded commit is the concatenation of the commit
|
||||
messages of the first commit and of those with the "squash" command,
|
||||
but omits the commit messages of commits with the "fixup" command.
|
||||
|
||||
'git-rebase' will stop when "pick" has been replaced with "edit" or
|
||||
'git rebase' will stop when "pick" has been replaced with "edit" or
|
||||
when a command fails due to merge errors. When you are done editing
|
||||
and/or resolving conflicts you can continue with `git rebase --continue`.
|
||||
|
||||
For example, if you want to reorder the last 5 commits, such that what
|
||||
was HEAD~4 becomes the new HEAD. To achieve that, you would call
|
||||
'git-rebase' like this:
|
||||
'git rebase' like this:
|
||||
|
||||
----------------------
|
||||
$ git rebase -i HEAD~5
|
||||
|
|
@ -422,7 +435,7 @@ SPLITTING COMMITS
|
|||
-----------------
|
||||
|
||||
In interactive mode, you can mark commits with the action "edit". However,
|
||||
this does not necessarily mean that 'git-rebase' expects the result of this
|
||||
this does not necessarily mean that 'git rebase' expects the result of this
|
||||
edit to be exactly one commit. Indeed, you can undo the commit, or you can
|
||||
add other commits. This can be used to split a commit into two:
|
||||
|
||||
|
|
@ -438,7 +451,7 @@ add other commits. This can be used to split a commit into two:
|
|||
|
||||
- Now add the changes to the index that you want to have in the first
|
||||
commit. You can use `git add` (possibly interactively) or
|
||||
'git-gui' (or both) to do that.
|
||||
'git gui' (or both) to do that.
|
||||
|
||||
- Commit the now-current index with whatever commit message is appropriate
|
||||
now.
|
||||
|
|
@ -449,7 +462,7 @@ add other commits. This can be used to split a commit into two:
|
|||
|
||||
If you are not absolutely sure that the intermediate revisions are
|
||||
consistent (they compile, pass the testsuite, etc.) you should use
|
||||
'git-stash' to stash away the not-yet-committed changes
|
||||
'git stash' to stash away the not-yet-committed changes
|
||||
after each commit, test, and amend the commit if fixes are necessary.
|
||||
|
||||
|
||||
|
|
@ -512,8 +525,8 @@ Easy case: The changes are literally the same.::
|
|||
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
|
||||
`\--interactive` to omit, edit, squash, or fixup commits; or
|
||||
if the upstream used one of `commit \--amend`, `reset`, or
|
||||
`filter-branch`.
|
||||
|
||||
|
||||
|
|
@ -524,7 +537,7 @@ 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
|
||||
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')
|
||||
------------
|
||||
|
|
@ -551,12 +564,12 @@ NOTE: While an "easy case recovery" sometimes appears to be successful
|
|||
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'
|
||||
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
|
||||
* 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].)
|
||||
|
||||
|
|
|
|||
|
|
@ -8,15 +8,15 @@ git-receive-pack - Receive what is pushed into the repository
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git receive-pack' <directory>
|
||||
'git-receive-pack' <directory>
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Invoked by 'git-send-pack' and updates the repository with the
|
||||
Invoked by 'git send-pack' and updates the repository with the
|
||||
information fed from the remote end.
|
||||
|
||||
This command is usually not invoked directly by the end user.
|
||||
The UI for the protocol is on the 'git-send-pack' side, and the
|
||||
The UI for the protocol is on the 'git send-pack' side, and the
|
||||
program pair is meant to be used to push updates to remote
|
||||
repository. For pull operations, see linkgit:git-fetch-pack[1].
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ OPTIONS
|
|||
refs.
|
||||
+
|
||||
This computation involves traversing all the reachable objects, i.e. it
|
||||
has the same cost as 'git-prune'. Fortunately, once this is run, we
|
||||
has the same cost as 'git prune'. Fortunately, once this is run, we
|
||||
should not have to ever worry about missing objects, because the current
|
||||
prune and pack-objects know about reflogs and protect objects referred by
|
||||
them.
|
||||
|
|
|
|||
|
|
@ -25,7 +25,10 @@ Commands are given by the caller on the helper's standard input, one per line.
|
|||
|
||||
'capabilities'::
|
||||
Lists the capabilities of the helper, one per line, ending
|
||||
with a blank line.
|
||||
with a blank line. Each capability may be preceeded with '*'.
|
||||
This marks them mandatory for git version using the remote
|
||||
helper to understand (unknown mandatory capability is fatal
|
||||
error).
|
||||
|
||||
'list'::
|
||||
Lists the refs, one per line, in the format "<value> <name>
|
||||
|
|
@ -79,6 +82,31 @@ style string if it contains an LF.
|
|||
+
|
||||
Supported if the helper has the "push" capability.
|
||||
|
||||
'import' <name>::
|
||||
Produces a fast-import stream which imports the current value
|
||||
of the named ref. It may additionally import other refs as
|
||||
needed to construct the history efficiently. The script writes
|
||||
to a helper-specific private namespace. The value of the named
|
||||
ref should be written to a location in this namespace derived
|
||||
by applying the refspecs from the "refspec" capability to the
|
||||
name of the ref.
|
||||
+
|
||||
Supported if the helper has the "import" capability.
|
||||
|
||||
'connect' <service>::
|
||||
Connects to given service. Standard input and standard output
|
||||
of helper are connected to specified service (git prefix is
|
||||
included in service name so e.g. fetching uses 'git-upload-pack'
|
||||
as service) on remote side. Valid replies to this command are
|
||||
empty line (connection established), 'fallback' (no smart
|
||||
transport support, fall back to dumb transports) and just
|
||||
exiting with error message printed (can't connect, don't
|
||||
bother trying to fall back). After line feed terminating the
|
||||
positive (empty) response, the output of service starts. After
|
||||
the connection ends, the remote helper exits.
|
||||
+
|
||||
Supported if the helper has the "connect" capability.
|
||||
|
||||
If a fatal error occurs, the program writes the error message to
|
||||
stderr and exits. The caller should expect that a suitable error
|
||||
message has been printed if the child closes the connection without
|
||||
|
|
@ -99,6 +127,22 @@ CAPABILITIES
|
|||
'push'::
|
||||
This helper supports the 'push' command.
|
||||
|
||||
'import'::
|
||||
This helper supports the 'import' command.
|
||||
|
||||
'refspec' 'spec'::
|
||||
When using the import command, expect the source ref to have
|
||||
been written to the destination ref. The earliest applicable
|
||||
refspec takes precedence. For example
|
||||
"refs/heads/*:refs/svn/origin/branches/*" means that, after an
|
||||
"import refs/heads/name", the script has written to
|
||||
refs/svn/origin/branches/name. If this capability is used at
|
||||
all, it must cover all refs reported by the list command; if
|
||||
it is not used, it is effectively "*:*"
|
||||
|
||||
'connect'::
|
||||
This helper supports the 'connect' command.
|
||||
|
||||
REF LIST ATTRIBUTES
|
||||
-------------------
|
||||
|
||||
|
|
@ -107,6 +151,10 @@ REF LIST ATTRIBUTES
|
|||
commands. A helper might chose to acquire the ref list by
|
||||
opening a different type of connection to the destination.
|
||||
|
||||
'unchanged'::
|
||||
This ref is unchanged since the last import or fetch, although
|
||||
the helper cannot necessarily determine what value that produced.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
'option verbosity' <N>::
|
||||
|
|
@ -137,9 +185,15 @@ OPTIONS
|
|||
but don't actually change any repository data. For most
|
||||
helpers this only applies to the 'push', if supported.
|
||||
|
||||
'option servpath <c-style-quoted-path>'::
|
||||
Set service path (--upload-pack, --receive-pack etc.) for
|
||||
next connect. Remote helper MAY support this option. Remote
|
||||
helper MUST NOT rely on this option being set before
|
||||
connect request occurs.
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
Documentation by Daniel Barkalow.
|
||||
Documentation by Daniel Barkalow and Ilari Liusvaara
|
||||
|
||||
GIT
|
||||
---
|
||||
|
|
|
|||
|
|
@ -14,6 +14,9 @@ SYNOPSIS
|
|||
'git remote rename' <old> <new>
|
||||
'git remote rm' <name>
|
||||
'git remote set-head' <name> (-a | -d | <branch>)
|
||||
'git remote set-url' [--push] <name> <newurl> [<oldurl>]
|
||||
'git remote set-url --add' [--push] <name> <newurl>
|
||||
'git remote set-url --delete' [--push] <name> <url>
|
||||
'git remote' [-v | --verbose] 'show' [-n] <name>
|
||||
'git remote prune' [-n | --dry-run] <name>
|
||||
'git remote' [-v | --verbose] 'update' [-p | --prune] [group | remote]...
|
||||
|
|
@ -101,6 +104,20 @@ remote set-head origin master" will set `$GIT_DIR/refs/remotes/origin/HEAD` to
|
|||
`refs/remotes/origin/master` already exists; if not it must be fetched first.
|
||||
+
|
||||
|
||||
'set-url'::
|
||||
|
||||
Changes URL remote points to. Sets first URL remote points to matching
|
||||
regex <oldurl> (first URL if no <oldurl> is given) to <newurl>. If
|
||||
<oldurl> doesn't match any URL, error occurs and nothing is changed.
|
||||
+
|
||||
With '--push', push URLs are manipulated instead of fetch URLs.
|
||||
+
|
||||
With '--add', instead of changing some URL, new URL is added.
|
||||
+
|
||||
With '--delete', instead of changing some URL, all URLs matching
|
||||
regex <url> are deleted. Trying to delete all non-push URLs is an
|
||||
error.
|
||||
|
||||
'show'::
|
||||
|
||||
Gives some information about the remote <name>.
|
||||
|
|
@ -161,7 +178,7 @@ $ git checkout -b nfs linux-nfs/master
|
|||
...
|
||||
------------
|
||||
|
||||
* Imitate 'git-clone' but track only selected branches
|
||||
* Imitate 'git clone' but track only selected branches
|
||||
+
|
||||
------------
|
||||
$ mkdir project.git
|
||||
|
|
|
|||
|
|
@ -49,16 +49,16 @@ other objects in that pack they already have locally.
|
|||
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
|
||||
with the next 'git-gc' invocation. See linkgit:git-gc[1].
|
||||
with the next 'git gc' invocation. See linkgit:git-gc[1].
|
||||
|
||||
-d::
|
||||
After packing, if the newly created packs make some
|
||||
existing packs redundant, remove the redundant packs.
|
||||
Also run 'git-prune-packed' to remove redundant
|
||||
Also run 'git prune-packed' to remove redundant
|
||||
loose object files.
|
||||
|
||||
-l::
|
||||
Pass the `--local` option to 'git-pack-objects'. See
|
||||
Pass the `--local` option to 'git pack-objects'. See
|
||||
linkgit:git-pack-objects[1].
|
||||
|
||||
-f::
|
||||
|
|
@ -66,12 +66,12 @@ other objects in that pack they already have locally.
|
|||
linkgit:git-pack-objects[1].
|
||||
|
||||
-q::
|
||||
Pass the `-q` option to 'git-pack-objects'. See
|
||||
Pass the `-q` option to 'git pack-objects'. See
|
||||
linkgit:git-pack-objects[1].
|
||||
|
||||
-n::
|
||||
Do not update the server information with
|
||||
'git-update-server-info'. This option skips
|
||||
'git update-server-info'. This option skips
|
||||
updating local catalog files needed to publish
|
||||
this repository (or a direct copy of it)
|
||||
over HTTP or FTP. See linkgit:git-update-server-info[1].
|
||||
|
|
@ -109,7 +109,7 @@ Configuration
|
|||
|
||||
When configuration variable `repack.UseDeltaBaseOffset` is set
|
||||
for the repository, the command passes `--delta-base-offset`
|
||||
option to 'git-pack-objects'; this typically results in slightly
|
||||
option to 'git pack-objects'; this typically results in slightly
|
||||
smaller packs, but the generated packs are incompatible with
|
||||
versions of git older than (and including) v1.4.3; do not set
|
||||
the variable in a repository that older version of git needs to
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ OPTIONS
|
|||
BUGS
|
||||
----
|
||||
Comparing blobs or trees that have been replaced with those that
|
||||
replace them will not work properly. And using 'git reset --hard' to
|
||||
replace them will not work properly. And using `git reset --hard` to
|
||||
go back to a replaced commit will move the branch to the replacement
|
||||
commit instead of the replaced commit.
|
||||
|
||||
|
|
|
|||
|
|
@ -30,14 +30,14 @@ enable this command.
|
|||
COMMANDS
|
||||
--------
|
||||
|
||||
Normally, 'git-rerere' is run without arguments or user-intervention.
|
||||
Normally, 'git rerere' is run without arguments or user-intervention.
|
||||
However, it has several commands that allow it to interact with
|
||||
its working state.
|
||||
|
||||
'clear'::
|
||||
|
||||
This resets the metadata used by rerere if a merge resolution is to be
|
||||
aborted. Calling 'git-am [--skip|--abort]' or 'git-rebase [--skip|--abort]'
|
||||
aborted. Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]'
|
||||
will automatically invoke this command.
|
||||
|
||||
'diff'::
|
||||
|
|
@ -142,32 +142,32 @@ finally ready and merged into the master branch. This merge
|
|||
would require you to resolve the conflict, introduced by the
|
||||
commits marked with `*`. However, this conflict is often the
|
||||
same conflict you resolved when you created the test merge you
|
||||
blew away. 'git-rerere' helps you resolve this final
|
||||
blew away. 'git rerere' helps you resolve this final
|
||||
conflicted merge using the information from your earlier hand
|
||||
resolve.
|
||||
|
||||
Running the 'git-rerere' command immediately after a conflicted
|
||||
Running the 'git rerere' command immediately after a conflicted
|
||||
automerge records the conflicted working tree files, with the
|
||||
usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in
|
||||
them. Later, after you are done resolving the conflicts,
|
||||
running 'git-rerere' again will record the resolved state of these
|
||||
running 'git rerere' again will record the resolved state of these
|
||||
files. Suppose you did this when you created the test merge of
|
||||
master into the topic branch.
|
||||
|
||||
Next time, after seeing the same conflicted automerge,
|
||||
running 'git-rerere' will perform a three-way merge between the
|
||||
running 'git rerere' will perform a three-way merge between the
|
||||
earlier conflicted automerge, the earlier manual resolution, and
|
||||
the current conflicted automerge.
|
||||
If this three-way merge resolves cleanly, the result is written
|
||||
out to your working tree file, so you do not have to manually
|
||||
resolve it. Note that 'git-rerere' leaves the index file alone,
|
||||
resolve it. Note that 'git rerere' leaves the index file alone,
|
||||
so you still need to do the final sanity checks with `git diff`
|
||||
(or `git diff -c`) and 'git-add' when you are satisfied.
|
||||
(or `git diff -c`) and 'git add' when you are satisfied.
|
||||
|
||||
As a convenience measure, 'git-merge' automatically invokes
|
||||
'git-rerere' upon exiting with a failed automerge and 'git-rerere'
|
||||
As a convenience measure, 'git merge' automatically invokes
|
||||
'git rerere' upon exiting with a failed automerge and 'git rerere'
|
||||
records the hand resolve when it is a new conflict, or reuses the earlier hand
|
||||
resolve when it is not. 'git-commit' also invokes 'git-rerere'
|
||||
resolve when it is not. 'git commit' also invokes 'git rerere'
|
||||
when committing a merge result. What this means is that you do
|
||||
not have to do anything special yourself (besides enabling
|
||||
the rerere.enabled config variable).
|
||||
|
|
@ -177,8 +177,8 @@ resolution is recorded, and it will be reused when you do the
|
|||
actual merge later with the updated master and topic branch, as long
|
||||
as the recorded resolution is still applicable.
|
||||
|
||||
The information 'git-rerere' records is also used when running
|
||||
'git-rebase'. After blowing away the test merge and continuing
|
||||
The information 'git rerere' records is also used when running
|
||||
'git rebase'. After blowing away the test merge and continuing
|
||||
development on the topic branch:
|
||||
|
||||
------------
|
||||
|
|
@ -197,7 +197,7 @@ you could run `git rebase master topic`, to bring yourself
|
|||
up-to-date before your topic is ready to be sent upstream.
|
||||
This would result in falling back to a three-way merge, and it
|
||||
would conflict the same way as the test merge you resolved earlier.
|
||||
'git-rerere' will be run by 'git-rebase' to help you resolve this
|
||||
'git rerere' will be run by 'git rebase' to help you resolve this
|
||||
conflict.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ OPTIONS
|
|||
--soft::
|
||||
Does not touch the index file nor the working tree at all, but
|
||||
requires them to be in a good order. This leaves all your changed
|
||||
files "Changes to be committed", as 'git-status' would
|
||||
files "Changes to be committed", as 'git status' would
|
||||
put it.
|
||||
|
||||
--hard::
|
||||
|
|
@ -62,11 +62,101 @@ This means that `git reset -p` is the opposite of `git add -p` (see
|
|||
linkgit:git-add[1]).
|
||||
|
||||
-q::
|
||||
--quiet::
|
||||
Be quiet, only report errors.
|
||||
|
||||
<commit>::
|
||||
Commit to make the current HEAD. If not given defaults to HEAD.
|
||||
|
||||
DISCUSSION
|
||||
----------
|
||||
|
||||
The tables below show what happens when running:
|
||||
|
||||
----------
|
||||
git reset --option target
|
||||
----------
|
||||
|
||||
to reset the HEAD to another commit (`target`) with the different
|
||||
reset options depending on the state of the files.
|
||||
|
||||
In these tables, A, B, C and D are some different states of a
|
||||
file. For example, the first line of the first table means that if a
|
||||
file is in state A in the working tree, in state B in the index, in
|
||||
state C in HEAD and in state D in the target, then "git reset --soft
|
||||
target" will put the file in state A in the working tree, in state B
|
||||
in the index and in state D in HEAD.
|
||||
|
||||
working index HEAD target working index HEAD
|
||||
----------------------------------------------------
|
||||
A B C D --soft A B D
|
||||
--mixed A D D
|
||||
--hard D D D
|
||||
--merge (disallowed)
|
||||
|
||||
working index HEAD target working index HEAD
|
||||
----------------------------------------------------
|
||||
A B C C --soft A B C
|
||||
--mixed A C C
|
||||
--hard C C C
|
||||
--merge (disallowed)
|
||||
|
||||
working index HEAD target working index HEAD
|
||||
----------------------------------------------------
|
||||
B B C D --soft B B D
|
||||
--mixed B D D
|
||||
--hard D D D
|
||||
--merge D D D
|
||||
|
||||
working index HEAD target working index HEAD
|
||||
----------------------------------------------------
|
||||
B B C C --soft B B C
|
||||
--mixed B C C
|
||||
--hard C C C
|
||||
--merge C C C
|
||||
|
||||
working index HEAD target working index HEAD
|
||||
----------------------------------------------------
|
||||
B C C D --soft B C D
|
||||
--mixed B D D
|
||||
--hard D D D
|
||||
--merge (disallowed)
|
||||
|
||||
working index HEAD target working index HEAD
|
||||
----------------------------------------------------
|
||||
B C C C --soft B C C
|
||||
--mixed B C C
|
||||
--hard C C C
|
||||
--merge B C C
|
||||
|
||||
"reset --merge" is meant to be used when resetting out of a conflicted
|
||||
merge. Any mergy operation guarantees that the work tree file that is
|
||||
involved in the merge does not have local change wrt the index before
|
||||
it starts, and that it writes the result out to the work tree. So if
|
||||
we see some difference between the index and the target and also
|
||||
between the index and the work tree, then it means that we are not
|
||||
resetting out from a state that a mergy operation left after failing
|
||||
with a conflict. That is why we disallow --merge option in this case.
|
||||
|
||||
The following tables show what happens when there are unmerged
|
||||
entries:
|
||||
|
||||
working index HEAD target working index HEAD
|
||||
----------------------------------------------------
|
||||
X U A B --soft (disallowed)
|
||||
--mixed X B B
|
||||
--hard B B B
|
||||
--merge B B B
|
||||
|
||||
working index HEAD target working index HEAD
|
||||
----------------------------------------------------
|
||||
X U A A --soft (disallowed)
|
||||
--mixed X A A
|
||||
--hard A A A
|
||||
--merge A A A
|
||||
|
||||
X means any state and U means an unmerged index.
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ git-rev-list - Lists commit objects in reverse chronological order
|
|||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
'git-rev-list' [ \--max-count=number ]
|
||||
'git rev-list' [ \--max-count=number ]
|
||||
[ \--skip=number ]
|
||||
[ \--max-age=timestamp ]
|
||||
[ \--min-age=timestamp ]
|
||||
|
|
@ -21,9 +21,10 @@ SYNOPSIS
|
|||
[ \--full-history ]
|
||||
[ \--not ]
|
||||
[ \--all ]
|
||||
[ \--branches ]
|
||||
[ \--tags ]
|
||||
[ \--remotes ]
|
||||
[ \--branches[=pattern] ]
|
||||
[ \--tags[=pattern] ]
|
||||
[ \--remotes[=pattern] ]
|
||||
[ \--glob=glob-pattern ]
|
||||
[ \--stdin ]
|
||||
[ \--quiet ]
|
||||
[ \--topo-order ]
|
||||
|
|
@ -93,8 +94,8 @@ between the two operands. The following two commands are equivalent:
|
|||
'rev-list' is a very essential git command, since it
|
||||
provides the ability to build and traverse commit ancestry graphs. For
|
||||
this reason, it has a lot of different options that enables it to be
|
||||
used by commands as different as 'git-bisect' and
|
||||
'git-repack'.
|
||||
used by commands as different as 'git bisect' and
|
||||
'git repack'.
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
|
|
|
|||
|
|
@ -15,16 +15,16 @@ DESCRIPTION
|
|||
|
||||
Many git porcelainish commands take mixture of flags
|
||||
(i.e. parameters that begin with a dash '-') and parameters
|
||||
meant for the underlying 'git-rev-list' command they use internally
|
||||
meant for the underlying 'git rev-list' command they use internally
|
||||
and flags and parameters for the other commands they use
|
||||
downstream of 'git-rev-list'. This command is used to
|
||||
downstream of 'git rev-list'. This command is used to
|
||||
distinguish between them.
|
||||
|
||||
|
||||
OPTIONS
|
||||
-------
|
||||
--parseopt::
|
||||
Use 'git-rev-parse' in option parsing mode (see PARSEOPT section below).
|
||||
Use 'git rev-parse' in option parsing mode (see PARSEOPT section below).
|
||||
|
||||
--keep-dashdash::
|
||||
Only meaningful in `--parseopt` mode. Tells the option parser to echo
|
||||
|
|
@ -36,17 +36,17 @@ OPTIONS
|
|||
that take options themself.
|
||||
|
||||
--sq-quote::
|
||||
Use 'git-rev-parse' in shell quoting mode (see SQ-QUOTE
|
||||
Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE
|
||||
section below). In contrast to the `--sq` option below, this
|
||||
mode does only quoting. Nothing else is done to command input.
|
||||
|
||||
--revs-only::
|
||||
Do not output flags and parameters not meant for
|
||||
'git-rev-list' command.
|
||||
'git rev-list' command.
|
||||
|
||||
--no-revs::
|
||||
Do not output flags and parameters meant for
|
||||
'git-rev-list' command.
|
||||
'git rev-list' command.
|
||||
|
||||
--flags::
|
||||
Do not output non-flag parameters.
|
||||
|
|
@ -74,7 +74,7 @@ OPTIONS
|
|||
properly quoted for consumption by shell. Useful when
|
||||
you expect your parameter to contain whitespaces and
|
||||
newlines (e.g. when using pickaxe `-S` with
|
||||
'git-diff-\*'). In contrast to the `--sq-quote` option,
|
||||
'git diff-\*'). In contrast to the `--sq-quote` option,
|
||||
the command input is still interpreted as usual.
|
||||
|
||||
--not::
|
||||
|
|
@ -103,14 +103,27 @@ OPTIONS
|
|||
--all::
|
||||
Show all refs found in `$GIT_DIR/refs`.
|
||||
|
||||
--branches::
|
||||
Show branch refs found in `$GIT_DIR/refs/heads`.
|
||||
--branches[=pattern]::
|
||||
--tags[=pattern]::
|
||||
--remotes[=pattern]::
|
||||
Show all branches, tags, or remote-tracking branches,
|
||||
respectively (i.e., refs found in `$GIT_DIR/refs/heads`,
|
||||
`$GIT_DIR/refs/tags`, or `$GIT_DIR/refs/remotes`,
|
||||
respectively).
|
||||
+
|
||||
If a `pattern` is given, only refs matching the given shell glob are
|
||||
shown. If the pattern does not contain a globbing character (`?`,
|
||||
`\*`, or `[`), it is turned into a prefix match by appending `/\*`.
|
||||
|
||||
--tags::
|
||||
Show tag refs found in `$GIT_DIR/refs/tags`.
|
||||
--glob=pattern::
|
||||
Show all refs matching the shell glob pattern `pattern`. If
|
||||
the pattern does not start with `refs/`, this is automatically
|
||||
prepended. If the pattern does not contain a globbing
|
||||
character (`?`, `\*`, or `[`), it is turned into a prefix
|
||||
match by appending `/\*`.
|
||||
|
||||
--remotes::
|
||||
Show tag refs found in `$GIT_DIR/refs/remotes`.
|
||||
--show-toplevel::
|
||||
Show the absolute path of the top-level directory.
|
||||
|
||||
--show-prefix::
|
||||
When the command is invoked from a subdirectory, show the
|
||||
|
|
@ -145,12 +158,12 @@ OPTIONS
|
|||
--since=datestring::
|
||||
--after=datestring::
|
||||
Parse the date string, and output the corresponding
|
||||
--max-age= parameter for 'git-rev-list'.
|
||||
--max-age= parameter for 'git rev-list'.
|
||||
|
||||
--until=datestring::
|
||||
--before=datestring::
|
||||
Parse the date string, and output the corresponding
|
||||
--min-age= parameter for 'git-rev-list'.
|
||||
--min-age= parameter for 'git rev-list'.
|
||||
|
||||
<args>...::
|
||||
Flags and parameters to be parsed.
|
||||
|
|
@ -171,7 +184,7 @@ blobs contained in a commit.
|
|||
name the same commit object if there are no other object in
|
||||
your repository whose object name starts with dae86e.
|
||||
|
||||
* An output from 'git-describe'; i.e. a closest tag, optionally
|
||||
* An output from 'git describe'; i.e. a closest tag, optionally
|
||||
followed by a dash and a number of commits, followed by a dash, a
|
||||
`g`, and an abbreviated object name.
|
||||
|
||||
|
|
@ -197,13 +210,13 @@ blobs contained in a commit.
|
|||
+
|
||||
HEAD names the commit your changes in the working tree is based on.
|
||||
FETCH_HEAD records the branch you fetched from a remote repository
|
||||
with your last 'git-fetch' invocation.
|
||||
with your last 'git fetch' invocation.
|
||||
ORIG_HEAD is created by commands that moves your HEAD in a drastic
|
||||
way, to record the position of the HEAD before their operation, so that
|
||||
you can change the tip of the branch back to the state before you ran
|
||||
them easily.
|
||||
MERGE_HEAD records the commit(s) you are merging into your branch
|
||||
when you run 'git-merge'.
|
||||
when you run 'git merge'.
|
||||
|
||||
* A ref followed by the suffix '@' with a date specification
|
||||
enclosed in a brace
|
||||
|
|
@ -231,6 +244,10 @@ when you run 'git-merge'.
|
|||
* The special construct '@\{-<n>\}' means the <n>th branch checked out
|
||||
before the current one.
|
||||
|
||||
* The suffix '@{upstream}' to a ref (short form 'ref@{u}') refers to
|
||||
the branch the ref is set to build on top of. Missing ref defaults
|
||||
to the current branch.
|
||||
|
||||
* A suffix '{caret}' to a revision parameter means the first parent of
|
||||
that commit object. '{caret}<n>' means the <n>th parent (i.e.
|
||||
'rev{caret}'
|
||||
|
|
@ -308,7 +325,7 @@ G H I J
|
|||
SPECIFYING RANGES
|
||||
-----------------
|
||||
|
||||
History traversing commands such as 'git-log' operate on a set
|
||||
History traversing commands such as 'git log' operate on a set
|
||||
of commits, not just a single commit. To these commands,
|
||||
specifying a single revision with the notation described in the
|
||||
previous section means the set of commits reachable from that
|
||||
|
|
@ -349,7 +366,7 @@ Here are a handful of examples:
|
|||
PARSEOPT
|
||||
--------
|
||||
|
||||
In `--parseopt` mode, 'git-rev-parse' helps massaging options to bring to shell
|
||||
In `--parseopt` mode, 'git rev-parse' helps massaging options to bring to shell
|
||||
scripts the same facilities C builtins have. It works as an option normalizer
|
||||
(e.g. splits single switches aggregate values), a bit like `getopt(1)` does.
|
||||
|
||||
|
|
@ -361,7 +378,7 @@ usage on the standard error stream, and exits with code 129.
|
|||
Input Format
|
||||
~~~~~~~~~~~~
|
||||
|
||||
'git-rev-parse --parseopt' input format is fully text based. It has two parts,
|
||||
'git rev-parse --parseopt' input format is fully text based. It has two parts,
|
||||
separated by a line that contains only `--`. The lines before the separator
|
||||
(should be more than one) are used for the usage.
|
||||
The lines after the separator describe the options.
|
||||
|
|
@ -420,13 +437,13 @@ eval `echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?`
|
|||
SQ-QUOTE
|
||||
--------
|
||||
|
||||
In `--sq-quote` mode, 'git-rev-parse' echoes on the standard output a
|
||||
In `--sq-quote` mode, 'git rev-parse' echoes on the standard output a
|
||||
single line suitable for `sh(1)` `eval`. This line is made by
|
||||
normalizing the arguments following `--sq-quote`. Nothing other than
|
||||
quoting the arguments is done.
|
||||
|
||||
If you want command input to still be interpreted as usual by
|
||||
'git-rev-parse' before the output is shell quoted, see the `--sq`
|
||||
'git rev-parse' before the output is shell quoted, see the `--sq`
|
||||
option.
|
||||
|
||||
Example
|
||||
|
|
|
|||
|
|
@ -20,8 +20,8 @@ effect of an earlier commit (often a faulty one). If you want to
|
|||
throw away all uncommitted changes in your working directory, you
|
||||
should see linkgit:git-reset[1], particularly the '--hard' option. If
|
||||
you want to extract specific files as they were in another commit, you
|
||||
should see linkgit:git-checkout[1], specifically the 'git checkout
|
||||
<commit> -- <filename>' syntax. Take care with these alternatives as
|
||||
should see linkgit:git-checkout[1], specifically the `git checkout
|
||||
<commit> -- <filename>` syntax. Take care with these alternatives as
|
||||
both will discard uncommitted changes in your working directory.
|
||||
|
||||
OPTIONS
|
||||
|
|
@ -33,7 +33,7 @@ OPTIONS
|
|||
|
||||
-e::
|
||||
--edit::
|
||||
With this option, 'git-revert' will let you edit the commit
|
||||
With this option, 'git revert' will let you edit the commit
|
||||
message prior to committing the revert. This is the default if
|
||||
you run the command from a terminal.
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ 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
|
||||
With this option, 'git revert' will not start the commit
|
||||
message editor.
|
||||
|
||||
-n::
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ See the CONFIGURATION section for 'sendemail.multiedit'.
|
|||
--in-reply-to=<identifier>::
|
||||
Specify the contents of the first In-Reply-To header.
|
||||
Subsequent emails will refer to the previous email
|
||||
instead of this if --chain-reply-to is set (the default)
|
||||
instead of this if --chain-reply-to is set.
|
||||
Only necessary if --compose is also set. If --compose
|
||||
is not set, this will be prompted for.
|
||||
|
||||
|
|
@ -172,8 +172,8 @@ Automating
|
|||
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.
|
||||
entire patch series. Disabled by default, but the 'sendemail.chainreplyto'
|
||||
configuration variable can be used to enable it.
|
||||
|
||||
--identity=<identity>::
|
||||
A configuration identity. When given, causes values in the
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ SYNOPSIS
|
|||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Usually you would want to use 'git-push', which is a
|
||||
Usually you would want to use 'git push', which is a
|
||||
higher-level wrapper of this command, instead. See linkgit:git-push[1].
|
||||
|
||||
Invokes 'git-receive-pack' on a possibly remote repository, and
|
||||
|
|
@ -86,7 +86,7 @@ and the destination side (after the colon). The ref to be
|
|||
pushed is determined by finding a match that matches the source
|
||||
side, and where it is pushed is determined by using the
|
||||
destination side. The rules used to match a ref are the same
|
||||
rules used by 'git-rev-parse' to resolve a symbolic ref
|
||||
rules used by 'git rev-parse' to resolve a symbolic ref
|
||||
name. See linkgit:git-rev-parse[1].
|
||||
|
||||
- It is an error if <src> does not match exactly one of the
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ This is not a command the end user would want to run. Ever.
|
|||
This documentation is meant for people who are studying the
|
||||
Porcelain-ish scripts and/or are writing new ones.
|
||||
|
||||
The 'git-sh-setup' scriptlet is designed to be sourced (using
|
||||
The 'git sh-setup' scriptlet is designed to be sourced (using
|
||||
`.`) by other shell scripts to set up some variables pointing at
|
||||
the normal git directories and a few helper shell functions.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,17 +3,17 @@ git-shortlog(1)
|
|||
|
||||
NAME
|
||||
----
|
||||
git-shortlog - Summarize 'git-log' output
|
||||
git-shortlog - Summarize 'git log' output
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
[verse]
|
||||
git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w]
|
||||
git shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>...]
|
||||
'git shortlog' [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>...]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
Summarizes 'git-log' output in a format suitable for inclusion
|
||||
Summarizes 'git log' output in a format suitable for inclusion
|
||||
in release announcements. Each commit will be grouped by author and
|
||||
the first line of the commit message will be shown.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,10 +14,10 @@ SYNOPSIS
|
|||
DESCRIPTION
|
||||
-----------
|
||||
Reads given idx file for packed git archive created with
|
||||
'git-pack-objects' command, and dumps its contents.
|
||||
'git pack-objects' command, and dumps its contents.
|
||||
|
||||
The information it outputs is subset of what you can get from
|
||||
'git-verify-pack -v'; this command only shows the packfile
|
||||
'git verify-pack -v'; this command only shows the packfile
|
||||
offset and SHA1 of each object.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ OPTIONS
|
|||
|
||||
--exclude-existing[=<pattern>]::
|
||||
|
||||
Make 'git-show-ref' act as a filter that reads refs from stdin of the
|
||||
Make 'git show-ref' act as a filter that reads refs from stdin of the
|
||||
form "^(?:<anything>\s)?<refname>(?:\^\{\})?$" and performs the
|
||||
following actions on each:
|
||||
(1) strip "^{}" at the end of line if any;
|
||||
|
|
@ -135,7 +135,7 @@ When using the '--verify' flag, the command requires an exact path:
|
|||
|
||||
will only match the exact branch called "master".
|
||||
|
||||
If nothing matches, 'git-show-ref' will return an error code of 1,
|
||||
If nothing matches, 'git show-ref' will return an error code of 1,
|
||||
and in the case of verification, it will show an error message.
|
||||
|
||||
For scripting, you can ask it to be quiet with the "--quiet" flag, which
|
||||
|
|
|
|||
|
|
@ -16,16 +16,16 @@ Shows one or more objects (blobs, trees, tags and commits).
|
|||
|
||||
For commits it shows the log message and textual diff. It also
|
||||
presents the merge commit in a special format as produced by
|
||||
'git-diff-tree --cc'.
|
||||
'git diff-tree --cc'.
|
||||
|
||||
For tags, it shows the tag message and the referenced objects.
|
||||
|
||||
For trees, it shows the names (equivalent to 'git-ls-tree'
|
||||
For trees, it shows the names (equivalent to 'git ls-tree'
|
||||
with \--name-only).
|
||||
|
||||
For plain blobs, it shows the plain contents.
|
||||
|
||||
The command takes options applicable to the 'git-diff-tree' command to
|
||||
The command takes options applicable to the 'git diff-tree' command to
|
||||
control how the changes the commit introduces are shown.
|
||||
|
||||
This manual page describes only the most frequently used options.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ SYNOPSIS
|
|||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
Use 'git stash' when you want to record the current state of the
|
||||
Use `git stash` when you want to record the current state of the
|
||||
working directory and the index, but want to go back to a clean
|
||||
working directory. The command saves your local modifications away
|
||||
and reverts the working directory to match the `HEAD` commit.
|
||||
|
|
@ -77,7 +77,7 @@ stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
|
|||
stash@{1}: On master: 9cc0589... Add git-stash
|
||||
----------------------------------------------------------------
|
||||
+
|
||||
The command takes options applicable to the 'git-log'
|
||||
The command takes options applicable to the 'git log'
|
||||
command to control what is shown and how. See linkgit:git-log[1].
|
||||
|
||||
show [<stash>]::
|
||||
|
|
@ -85,7 +85,7 @@ show [<stash>]::
|
|||
Show the changes recorded in the stash as a diff between the
|
||||
stashed state and its original parent. When no `<stash>` is given,
|
||||
shows the latest one. By default, the command shows the diffstat, but
|
||||
it will accept any format known to 'git-diff' (e.g., `git stash show
|
||||
it will accept any format known to 'git diff' (e.g., `git stash show
|
||||
-p stash@\{1}` to view the second most recent stash in patch form).
|
||||
|
||||
pop [--index] [-q|--quiet] [<stash>]::
|
||||
|
|
@ -201,7 +201,7 @@ $ git reset --soft HEAD^
|
|||
# ... continue hacking ...
|
||||
----------------------------------------------------------------
|
||||
+
|
||||
You can use 'git-stash' to simplify the above, like this:
|
||||
You can use 'git stash' to simplify the above, like this:
|
||||
+
|
||||
----------------------------------------------------------------
|
||||
# ... hack hack hack ...
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ git-status - Show the working tree status
|
|||
|
||||
SYNOPSIS
|
||||
--------
|
||||
'git status' <options>...
|
||||
'git status' [<options>...] [--] [<pathspec>...]
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
|
@ -17,28 +17,93 @@ current HEAD commit, paths that have differences between the working
|
|||
tree and the index file, and paths in the working tree that are not
|
||||
tracked by git (and are not ignored by linkgit:gitignore[5]). The first
|
||||
are what you _would_ commit by running `git commit`; the second and
|
||||
third are what you _could_ commit by running 'git-add' before running
|
||||
third are what you _could_ commit by running 'git add' before running
|
||||
`git commit`.
|
||||
|
||||
The command takes the same set of options as 'git-commit'; it
|
||||
shows what would be committed if the same options are given to
|
||||
'git-commit'.
|
||||
OPTIONS
|
||||
-------
|
||||
|
||||
If there is no path that is different between the index file and
|
||||
the current HEAD commit (i.e., there is nothing to commit by running
|
||||
`git commit`), the command exits with non-zero status.
|
||||
-s::
|
||||
--short::
|
||||
Give the output in the short-format.
|
||||
|
||||
--porcelain::
|
||||
Give the output in a stable, easy-to-parse format for scripts.
|
||||
Currently this is identical to --short output, but is guaranteed
|
||||
not to change in the future, making it safe for scripts.
|
||||
|
||||
-u[<mode>]::
|
||||
--untracked-files[=<mode>]::
|
||||
Show untracked files (Default: 'all').
|
||||
+
|
||||
The mode parameter is optional, and is used to specify
|
||||
the handling of untracked files. The possible options are:
|
||||
+
|
||||
--
|
||||
- 'no' - Show no untracked files
|
||||
- 'normal' - Shows untracked files and directories
|
||||
- 'all' - Also shows individual files in untracked directories.
|
||||
--
|
||||
+
|
||||
See linkgit:git-config[1] for configuration variable
|
||||
used to change the default for when the option is not
|
||||
specified.
|
||||
|
||||
-z::
|
||||
Terminate entries with NUL, instead of LF. This implies
|
||||
the `--porcelain` output format if no other format is given.
|
||||
|
||||
|
||||
OUTPUT
|
||||
------
|
||||
The output from this command is designed to be used as a commit
|
||||
template comment, and all the output lines are prefixed with '#'.
|
||||
The default, long format, is designed to be human readable,
|
||||
verbose and descriptive. They are subject to change in any time.
|
||||
|
||||
The paths mentioned in the output, unlike many other git commands, are
|
||||
made relative to the current directory if you are working in a
|
||||
subdirectory (this is on purpose, to help cutting and pasting). See
|
||||
the status.relativePaths config option below.
|
||||
|
||||
In short-format, the status of each path is shown as
|
||||
|
||||
XY PATH1 -> PATH2
|
||||
|
||||
where `PATH1` is the path in the `HEAD`, and ` -> PATH2` part is
|
||||
shown only when `PATH1` corresponds to a different path in the
|
||||
index/worktree (i.e. renamed).
|
||||
|
||||
For unmerged entries, `X` shows the status of stage #2 (i.e. ours) and `Y`
|
||||
shows the status of stage #3 (i.e. theirs).
|
||||
|
||||
For entries that do not have conflicts, `X` shows the status of the index,
|
||||
and `Y` shows the status of the work tree. For untracked paths, `XY` are
|
||||
`??`.
|
||||
|
||||
X Y Meaning
|
||||
-------------------------------------------------
|
||||
[MD] not updated
|
||||
M [ MD] updated in index
|
||||
A [ MD] added to index
|
||||
D [ MD] deleted from index
|
||||
R [ MD] renamed in index
|
||||
C [ MD] copied in index
|
||||
[MARC] index and work tree matches
|
||||
[ MARC] M work tree changed since index
|
||||
[ MARC] D deleted in work tree
|
||||
-------------------------------------------------
|
||||
D D unmerged, both deleted
|
||||
A U unmerged, added by us
|
||||
U D unmerged, deleted by them
|
||||
U A unmerged, added by them
|
||||
D U unmerged, deleted by us
|
||||
A A unmerged, both added
|
||||
U U unmerged, both modified
|
||||
-------------------------------------------------
|
||||
? ? untracked
|
||||
-------------------------------------------------
|
||||
|
||||
|
||||
CONFIGURATION
|
||||
-------------
|
||||
|
|
@ -53,9 +118,9 @@ paths shown are relative to the repository root, not to the current
|
|||
directory.
|
||||
|
||||
If `status.submodulesummary` is set to a non zero number or true (identical
|
||||
to -1 or an unlimited number), the submodule summary will be enabled and a
|
||||
summary of commits for modified submodules will be shown (see --summary-limit
|
||||
option of linkgit:git-submodule[1]).
|
||||
to -1 or an unlimited number), the submodule summary will be enabled for
|
||||
the long format and a summary of commits for modified submodules will be
|
||||
shown (see --summary-limit option of linkgit:git-submodule[1]).
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
|
@ -63,8 +128,7 @@ linkgit:gitignore[5]
|
|||
|
||||
Author
|
||||
------
|
||||
Written by Linus Torvalds <torvalds@osdl.org> and
|
||||
Junio C Hamano <gitster@pobox.com>.
|
||||
Written by Junio C Hamano <gitster@pobox.com>.
|
||||
|
||||
Documentation
|
||||
--------------
|
||||
|
|
|
|||
|
|
@ -99,11 +99,11 @@ locate the submodule using the relative URL in .gitmodules.
|
|||
status::
|
||||
Show the status of the submodules. This will print the SHA-1 of the
|
||||
currently checked out commit for each submodule, along with the
|
||||
submodule path and the output of 'git-describe' for the
|
||||
submodule path and the output of 'git describe' for the
|
||||
SHA-1. Each SHA-1 will be prefixed with `-` if the submodule is not
|
||||
initialized and `+` if the currently checked out submodule commit
|
||||
does not match the SHA-1 found in the index of the containing
|
||||
repository. This command is the default command for 'git-submodule'.
|
||||
repository. This command is the default command for 'git submodule'.
|
||||
+
|
||||
If '--recursive' is specified, this command will recurse into nested
|
||||
submodules, and show their status as well.
|
||||
|
|
@ -114,8 +114,8 @@ init::
|
|||
The key used in .git/config is `submodule.$name.url`.
|
||||
This command does not alter existing information in .git/config.
|
||||
You can then customize the submodule clone URLs in .git/config
|
||||
for your local setup and proceed to 'git submodule update';
|
||||
you can also just use 'git submodule update --init' without
|
||||
for your local setup and proceed to `git submodule update`;
|
||||
you can also just use `git submodule update --init` without
|
||||
the explicit 'init' step if you do not intend to customize
|
||||
any submodule locations.
|
||||
|
||||
|
|
|
|||
|
|
@ -62,6 +62,8 @@ COMMANDS
|
|||
Set the 'useSvnsyncProps' option in the [svn-remote] config.
|
||||
--rewrite-root=<URL>;;
|
||||
Set the 'rewriteRoot' option in the [svn-remote] config.
|
||||
--rewrite-uuid=<UUID>;;
|
||||
Set the 'rewriteUUID' option in the [svn-remote] config.
|
||||
--username=<USER>;;
|
||||
For transports that SVN handles authentication for (http,
|
||||
https, and plain svn), specify the username. For other
|
||||
|
|
@ -239,6 +241,19 @@ discouraged.
|
|||
where <name> is the name of the SVN repository as specified by the -R option to
|
||||
'init' (or "svn" by default).
|
||||
|
||||
--username;;
|
||||
Specify the SVN username to perform the commit as. This option overrides
|
||||
configuration property 'username'.
|
||||
|
||||
--commit-url;;
|
||||
Use the specified URL to connect to the destination Subversion
|
||||
repository. This is useful in cases where the source SVN
|
||||
repository is read-only. This option overrides configuration
|
||||
property 'commiturl'.
|
||||
+
|
||||
git config --get-all svn-remote.<name>.commiturl
|
||||
+
|
||||
|
||||
'tag'::
|
||||
Create a tag in the SVN repository. This is a shorthand for
|
||||
'branch -t'.
|
||||
|
|
@ -616,6 +631,12 @@ svn-remote.<name>.rewriteRoot::
|
|||
the repository with a public http:// or svn:// URL in the
|
||||
metadata so users of it will see the public URL.
|
||||
|
||||
svn-remote.<name>.rewriteUUID::
|
||||
Similar to the useSvmProps option; this is for users who need
|
||||
to remap the UUID manually. This may be useful in situations
|
||||
where the original UUID is not available via either useSvmProps
|
||||
or useSvnsyncProps.
|
||||
|
||||
svn.brokenSymlinkWorkaround::
|
||||
This disables potentially expensive checks to workaround
|
||||
broken symlinks checked into SVN by broken clients. Set this
|
||||
|
|
@ -625,13 +646,14 @@ svn.brokenSymlinkWorkaround::
|
|||
revision fetched. If unset, 'git svn' assumes this option to
|
||||
be "true".
|
||||
|
||||
Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
|
||||
Since the noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps and useSvmProps
|
||||
options all affect the metadata generated and used by 'git svn'; they
|
||||
*must* be set in the configuration file before any history is imported
|
||||
and these settings should never be changed once they are set.
|
||||
|
||||
Additionally, only one of these four options can be used per-svn-remote
|
||||
section because they affect the 'git-svn-id:' metadata line.
|
||||
Additionally, only one of these options can be used per svn-remote
|
||||
section because they affect the 'git-svn-id:' metadata line, except
|
||||
for rewriteRoot and rewriteUUID which can be used together.
|
||||
|
||||
|
||||
BASIC EXAMPLES
|
||||
|
|
@ -816,6 +838,22 @@ independent path component (surrounded by '/' or EOL). This
|
|||
type of configuration is not automatically created by 'init' and
|
||||
should be manually entered with a text-editor or using 'git config'.
|
||||
|
||||
It is also possible to fetch a subset of branches or tags by using a
|
||||
comma-separated list of names within braces. For example:
|
||||
|
||||
------------------------------------------------------------------------
|
||||
[svn-remote "huge-project"]
|
||||
url = http://server.org/svn
|
||||
fetch = trunk/src:refs/remotes/trunk
|
||||
branches = branches/{red,green}/src:refs/remotes/branches/*
|
||||
tags = tags/{1.0,2.0}/src:refs/remotes/tags/*
|
||||
------------------------------------------------------------------------
|
||||
|
||||
Note that git-svn keeps track of the highest revision in which a branch
|
||||
or tag has appeared. If the subset of branches or tags is changed after
|
||||
fetching, then .git/svn/.metadata must be manually edited to remove (or
|
||||
reset) branches-maxRev and/or tags-maxRev as appropriate.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
linkgit:git-rebase[1]
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ cumbersome. On some platforms, `ln -sf` does not even work as
|
|||
advertised (horrors). Therefore symbolic links are now deprecated
|
||||
and symbolic refs are used by default.
|
||||
|
||||
'git-symbolic-ref' will exit with status 0 if the contents of the
|
||||
'git symbolic-ref' will exit with status 0 if the contents of the
|
||||
symbolic ref were printed correctly, with status 1 if the requested
|
||||
name is not a symbolic ref, or 128 if another error occurs.
|
||||
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче