Merge branch 'bc/reflog-fix' into js/reflog-delete
* bc/reflog-fix: (1490 commits)
builtin-reflog.c: don't install new reflog on write failure
hash: fix lookup_hash semantics
gitweb: Better chopping in commit search results
builtin-tag.c: remove cruft
git-merge-index documentation: clarify synopsis
send-email: fix In-Reply-To regression
git-reset --hard and git-read-tree --reset: fix read_cache_unmerged()
Teach git-grep --name-only as synonym for -l
diff: fix java funcname pattern for solaris
t3404: use configured shell instead of /bin/sh
git_config_*: don't assume we are parsing a config file
prefix_path: use is_absolute_path() instead of *orig == '/'
git-clean: handle errors if removing files fails
Clarified the meaning of git-add -u in the documentation
git-clone.sh: properly configure remote even if remote's head is dangling
git.el: Set process-environment instead of invoking env
Documentation/git-stash: document options for git stash list
send-email: squelch warning due to comparing undefined $_ to ""
cvsexportcommit: be graceful when "cvs status" reorders the arguments
Rename git-core rpm to just git and rename the meta-pacakge to git-all.
...
Conflicts:
Documentation/git-reflog.txt
t/t1410-reflog.sh
@ -10,7 +10,7 @@ Checklist (and a short version for the impatient):
@@ -10,7 +10,7 @@ Checklist (and a short version for the impatient):
- the first line of the commit message should be a short
description and should skip the full stop
- if you want your work included in git.git, add a
"Signed-off-by: Your Name <your@email.com>" line to the
"Signed-off-by: Your Name <you@example.com>" line to the
commit message (or just use the option "-s" when
committing) to confirm that you agree to the Developer's
Certificate of Origin
@ -20,9 +20,6 @@ Checklist (and a short version for the impatient):
@@ -20,9 +20,6 @@ Checklist (and a short version for the impatient):
Patch:
- use "git format-patch -M" to create the patch
- send your patch to <git@vger.kernel.org>. If you use
git-send-email(1), please test it first by sending
email to yourself.
- do not PGP sign your patch
- do not attach your patch, but read in the mail
body, unless you cannot teach your mailer to
@ -31,13 +28,15 @@ Checklist (and a short version for the impatient):
@@ -31,13 +28,15 @@ Checklist (and a short version for the impatient):
corrupt whitespaces.
- provide additional information (which is unsuitable for
the commit message) between the "---" and the diffstat
- send the patch to the list (git@vger.kernel.org) and the
maintainer (gitster@pobox.com).
- if you change, add, or remove a command line option or
make some other user interface change, the associated
documentation should be updated as well.
- if your name is not writable in ASCII, make sure that
you send off a message in the correct encoding.
- send the patch to the list (git@vger.kernel.org) and the
maintainer (gitster@pobox.com) if (and only if) the patch
is ready for inclusion. If you use git-send-email(1),
please test it first by sending email to yourself.
Long version:
@ -113,7 +112,12 @@ lose tabs that way if you are not careful.
@@ -113,7 +112,12 @@ lose tabs that way if you are not careful.
It is a common convention to prefix your subject line with
[PATCH]. This lets people easily distinguish patches from other
e-mail discussions.
e-mail discussions. Use of additional markers after PATCH and
the closing bracket to mark the nature of the patch is also
encouraged. E.g. [PATCH/RFC] is often used when the patch is
not ready to be applied but it is for discussion, [PATCH v2],
[PATCH v3] etc. are often seen when you are sending an update to
what you have previously sent.
"git format-patch" command follows the best current practice to
format the body of an e-mail message. At the beginning of the
@ -158,7 +162,8 @@ Note that your maintainer does not necessarily read everything
@@ -158,7 +162,8 @@ Note that your maintainer does not necessarily read everything
on the git mailing list. If your patch is for discussion first,
send it "To:" the mailing list, and optionally "cc:" him. If it
is trivially correct or after the list reached a consensus, send
it "To:" the maintainer and optionally "cc:" the list.
it "To:" the maintainer and optionally "cc:" the list for
inclusion.
Also note that your maintainer does not actively involve himself in
maintaining what are in contrib/ hierarchy. When you send fixes and
@ -211,10 +216,53 @@ then you just add a line saying
@@ -211,10 +216,53 @@ then you just add a line saying
This line can be automatically added by git if you run the git-commit
command with the -s option.
Some people also put extra tags at the end. They'll just be ignored for
now, but you can do this to mark internal company procedures or just
point out some special detail about the sign-off.
Notice that you can place your own Signed-off-by: line when
forwarding somebody else's patch with the above rules for
D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
the change to its true author (see (2) above).
Some people also put extra tags at the end.
"Acked-by:" says that the patch was reviewed by the person who
is more familiar with the issues and the area the patch attempts
to modify. "Tested-by:" says the patch was tested by the person
and found to have the desired effect.
------------------------------------------------
An ideal patch flow
Here is an ideal patch flow for this project the current maintainer
suggests to the contributors:
(0) You come up with an itch. You code it up.
(1) Send it to the list and cc people who may need to know about
the change.
The people who may need to know are the ones whose code you
are butchering. These people happen to be the ones who are
most likely to be knowledgeable enough to help you, but
they have no obligation to help you (i.e. you ask for help,
don't demand). "git log -p -- $area_you_are_modifying" would
help you find out who they are.
(2) You get comments and suggestions for improvements. You may
even get them in a "on top of your change" patch form.
(3) Polish, refine, and re-send to the list and the people who
spend their time to improve your patch. Go back to step (2).
(4) The list forms consensus that the last round of your patch is
good. Send it to the list and cc the maintainer.
(5) A topic branch is created with the patch and is merged to 'next',
and cooked further and eventually graduates to 'master'.
In any time between the (2)-(3) cycle, the maintainer may pick it up
from the list and queue it to 'pu', in order to make it easier for
people play with it without having to pick up and apply the patch to
The command that git will use to paginate output. Can be overridden
with the `GIT_PAGER` environment variable.
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
consider them as errors:
+
* `trailing-space` treats trailing whitespaces at the end of the line
as an error (enabled by default).
* `space-before-tab` treats a space character that appears immediately
before a tab character in the initial indent part of the line as an
error (enabled by default).
* `indent-with-non-tab` treats a line that is indented with 8 or more
space characters as an error (not enabled by default).
alias.*::
Command aliases for the gitlink:git[1] command wrapper - e.g.
Command aliases for the linkgit:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
"git last" is equivalent to "git cat-file commit HEAD". To avoid
confusion and troubles with script usage, aliases that
@ -310,24 +371,25 @@ it will be treated as a shell command. For example, defining
@@ -310,24 +371,25 @@ it will be treated as a shell command. For example, defining
apply.whitespace::
Tells `git-apply` how to handle whitespaces, in the same way
as the '--whitespace' option. See gitlink:git-apply[1].
as the '--whitespace' option. See linkgit:git-apply[1].
branch.autosetupmerge::
Tells `git-branch` and `git-checkout` to setup new branches
so that gitlink:git-pull[1] will appropriately merge from that
so that linkgit:git-pull[1] will appropriately merge from that
remote branch. Note that even if this option is not set,
this behavior can be chosen per-branch using the `--track`
and `--no-track` options. This option defaults to false.
and `--no-track` options. This option defaults to true.
branch.<name>.remote::
When in branch <name>, it tells `git fetch` which remote to fetch.
If this option is not given, `git fetch` defaults to remote "origin".
branch.<name>.merge::
When in branch <name>, it tells `git fetch` the default refspec to
be marked for merging in FETCH_HEAD. The value has exactly to match
a remote part of one of the refspecs which are fetched from the remote
given by "branch.<name>.remote".
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.
Sets default options for merging into branch <name>. The syntax and
supported options are equal to that of gitlink:git-merge[1], but
supported options are equal to that of linkgit:git-merge[1], but
option values containing whitespace characters are currently not
supported.
branch.<name>.rebase::
When true, rebase the branch <name> on top of the fetched branch,
instead of merging the default branch from the default remote.
*NOTE*: this is a possibly dangerous operation; do *not* use
it unless you understand the implications (see linkgit:git-rebase[1]
for details).
browser.<tool>.path::
Override the path for the given tool that may be used to
browse HTML help (see '-w' option in linkgit:git-help[1]) or a
working repository in gitweb (see linkgit:git-instaweb[1]).
clean.requireForce::
A boolean to make git-clean do nothing unless given -f or -n. Defaults
to false.
A boolean to make git-clean do nothing unless given -f
or -n. Defaults to true.
color.branch::
A boolean to enable/disable color in the output of
gitlink:git-branch[1]. May be set to `true` (or `always`),
`false` (or `never`) or `auto`, in which case colors are used
linkgit:git-branch[1]. May be set to `always`,
`false` (or `never`) or `auto` (or `true`), in which case colors are used
only when the output is to a terminal. Defaults to false.
color.branch.<slot>::
@ -368,17 +442,30 @@ second is the background. The position of the attribute, if any,
@@ -368,17 +442,30 @@ second is the background. The position of the attribute, if any,
doesn't matter.
color.diff::
When true (or `always`), always use colors in patch.
When false (or `never`), never. When set to `auto`, use
colors only when the output is to the terminal.
When set to `always`, always use colors in patch.
When false (or `never`), never. When set to `true` or `auto`, use
colors only when the output is to the terminal. Defaults to false.
color.diff.<slot>::
Use customized color for diff colorization. `<slot>` specifies
which part of the patch to use the specified color, and is one
of `plain` (context text), `meta` (metainformation), `frag`
and in fact a lot of the common git command combinations can be scripted
with the `git xyz` interfaces. You can learn things by just looking
at what the various git scripts do. For example, `git reset` is the
above two lines implemented in `git-reset`, but some things like
at what the various git scripts do. For example, `git reset` used to be
the above two lines implemented in `git-reset`, but some things like
`git status` and `git commit` are slightly more complex scripts around
the basic git commands.
@ -805,8 +800,8 @@ you have, you can say
@@ -805,8 +800,8 @@ you have, you can say
$ git branch
------------
which is nothing more than a simple script around `ls .git/refs/heads`.
There will be asterisk in front of the branch you are currently on.
which used to be nothing more than a simple script around `ls .git/refs/heads`.
There will be an asterisk in front of the branch you are currently on.
Sometimes you may wish to create a new branch _without_ actually
checking it out and switching to it. If so, just use the command
@ -833,7 +828,7 @@ that branch, and do some work there.
@@ -833,7 +828,7 @@ that branch, and do some work there.
------------------------------------------------
$ git checkout mybranch
$ echo "Work, work, work" >>hello
$ git commit -m 'Some work.' -i hello
$ git commit -m "Some work." -i hello
------------------------------------------------
Here, we just added another line to `hello`, and we used a shorthand for
@ -858,7 +853,7 @@ hasn't happened in the `master` branch at all. Then do
@@ -858,7 +853,7 @@ hasn't happened in the `master` branch at all. Then do
------------
$ echo "Play, play, play" >>hello
$ echo "Lots of fun" >>example
$ git commit -m 'Some fun.' -i hello example
$ git commit -m "Some fun." -i hello example
------------
since the master branch is obviously in a much better mood.
@ -883,7 +878,7 @@ script called `git merge`, which wants to know which branches you want
@@ -883,7 +878,7 @@ script called `git merge`, which wants to know which branches you want
to resolve and what the merge is all about:
------------
$ git merge "Merge work in mybranch" HEAD mybranch
$ git merge -m "Merge work in mybranch" mybranch
------------
where the first argument is going to be used as the commit message if
@ -936,12 +931,13 @@ Another useful tool, especially if you do not always work in X-Window
@@ -936,12 +931,13 @@ Another useful tool, especially if you do not always work in X-Window
The first two lines indicate that it is showing the two branches
@ -952,17 +948,29 @@ the later output lines is used to show commits contained in the
@@ -952,17 +948,29 @@ the later output lines is used to show commits contained in the
`master` branch, and the second column for the `mybranch`
branch. Three commits are shown along with their log messages.
All of them have non blank characters in the first column (`*`
shows an ordinary commit on the current branch, `.` is a merge commit), which
shows an ordinary commit on the current branch, `-` is a merge commit), which
means they are now part of the `master` branch. Only the "Some
work" commit has the plus `+` character in the second column,
because `mybranch` has not been merged to incorporate these
commits from the master branch. The string inside brackets
before the commit log message is a short name you can use to
name the commit. In the above example, 'master' and 'mybranch'
are branch heads. 'master~1' is the first parent of 'master'
are branch heads. 'master^' is the first parent of 'master'
branch head. Please see 'git-rev-parse' documentation if you
see more complex cases.
[NOTE]
Without the '--more=1' option, 'git-show-branch' would not output the
'[master^]' commit, as '[mybranch]' commit is a common ancestor of
both 'master' and 'mybranch' tips. Please see 'git-show-branch'
documentation for details.
[NOTE]
If there were more commits on the 'master' branch after the merge, the
merge commit itself would not be shown by 'git-show-branch' by
default. You would need to provide '--sparse' option to make the
merge commit visible in this case.
Now, let's pretend you are the one who did all the work in
`mybranch`, and the fruit of your hard work has finally been merged
to the `master` branch. Let's go back to `mybranch`, and run
@ -970,7 +978,7 @@ to the `master` branch. Let's go back to `mybranch`, and run
@@ -970,7 +978,7 @@ to the `master` branch. Let's go back to `mybranch`, and run
------------
$ git checkout mybranch
$ git merge "Merge upstream changes." HEAD master
$ git merge -m "Merge upstream changes." master
------------
This outputs something like this (the actual commit object names
@ -1082,11 +1090,6 @@ server like git Native transport does. Any stock HTTP server
@@ -1082,11 +1090,6 @@ server like git Native transport does. Any stock HTTP server
that does not even support directory index would suffice. But
you must prepare your repository with `git-update-server-info`
to help dumb transport downloaders.
+
There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload`
programs, which are 'commit walkers'; they outlived their
usefulness when git Native and SSH transports were introduced,
and not used by `git pull` or `git push` scripts.
Once you fetch from the remote repository, you `merge` that
with your current branch.
@ -1149,7 +1152,7 @@ back to the earlier repository with "hello" and "example" file,
@@ -1149,7 +1152,7 @@ back to the earlier repository with "hello" and "example" file,
and bring ourselves back to the pre-merge state:
------------
$ git show-branch --more=3 master mybranch
$ git show-branch --more=2 master mybranch
! [master] Merge work in mybranch
* [mybranch] Merge work in mybranch
--
@ -1193,7 +1196,7 @@ $ mb=$(git-merge-base HEAD mybranch)
@@ -1193,7 +1196,7 @@ $ mb=$(git-merge-base HEAD mybranch)
The command writes the commit object name of the common ancestor
to the standard output, so we captured its output to a variable,
because we will be using it in the next step. BTW, the common
because we will be using it in the next step. By the way, the common
ancestor commit is the "New day." commit in this case. You can
This is the same `git-read-tree` command we have already seen,
but it takes three trees, unlike previous examples. This reads
the contents of each tree into different 'stage' in the index
file (the first tree goes to stage 1, the second stage 2,
file (the first tree goes to stage 1, the second to stage 2,
etc.). After reading three trees into three stages, the paths
that are the same in all three stages are 'collapsed' into stage
0. Also paths that are the same in two of three stages are
@ -1459,8 +1462,7 @@ Although git is a truly distributed system, it is often
@@ -1459,8 +1462,7 @@ Although git is a truly distributed system, it is often
convenient to organize your project with an informal hierarchy
of developers. Linux kernel development is run this way. There
is a nice illustration (page 17, "Merges to Mainline") in
It should be stressed that this hierarchy is purely *informal*.
There is nothing fundamental in git that enforces the "chain of
@ -1613,8 +1615,8 @@ in both of them. You could merge in 'diff-fix' first and then
@@ -1613,8 +1615,8 @@ in both of them. You could merge in 'diff-fix' first and then
'commit-fix' next, like this:
------------
$ git merge 'Merge fix in diff-fix' master diff-fix
$ git merge 'Merge fix in commit-fix' master commit-fix
$ git merge -m "Merge fix in diff-fix" diff-fix
$ git merge -m "Merge fix in commit-fix" commit-fix
@ -36,12 +36,12 @@ them first before running git pull.
@@ -36,12 +36,12 @@ them first before running git pull.
================================
The `pull` command knows where to get updates from because of certain
configuration variables that were set by the first `git clone`
command; see `git config -l` and the gitlink:git-config[1] man
command; see `git config -l` and the linkgit:git-config[1] man
page for details.
================================
You can update the shared repository with your changes by first committing
your changes, and then using the gitlink:git-push[1] command:
your changes, and then using the linkgit:git-push[1] command:
------------------------------------------------
$ git push origin master
@ -88,7 +88,7 @@ Next, give every team member read/write access to this repository. One
@@ -88,7 +88,7 @@ Next, give every team member read/write access to this repository. One
easy way to do this is to give all the team members ssh access to the
machine where the repository is hosted. If you don't want to give them a
full shell on the machine, there is a restricted shell which only allows
users to do git pushes and pulls; see gitlink:git-shell[1].
users to do git pushes and pulls; see linkgit:git-shell[1].
Put all the committers in the same group, and make the repository
writable by that group:
@ -106,7 +106,7 @@ Importing a CVS archive
@@ -106,7 +106,7 @@ Importing a CVS archive
First, install version 2.1 or higher of cvsps from
link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
sure it is in your path. Then cd to a checked out CVS working directory
of the project you are interested in and run gitlink:git-cvsimport[1]:
of the project you are interested in and run linkgit:git-cvsimport[1]:
-------------------------------------------
$ git cvsimport -C <destination> <module>
@ -146,7 +146,7 @@ Providing CVS Access to a git Repository
@@ -146,7 +146,7 @@ Providing CVS Access to a git Repository
----------------------------------------
It is also possible to provide true CVS access to a git repository, so
that developers can still use CVS; see gitlink:git-cvsserver[1] for
that developers can still use CVS; see linkgit:git-cvsserver[1] for
"git-diff-tree" and "git-diff-files" can take '-c' or '--cc' option
"git-diff-tree", "git-diff-files" and "git-diff --raw"
can take '-c' or '--cc' option
to generate diff output also for merge commits. The output differs
from the format described above in the following way:
@ -82,161 +83,65 @@ Note that 'combined diff' lists only files which were modified from
@@ -82,161 +83,65 @@ Note that 'combined diff' lists only files which were modified from
all parents.
Generating patches with -p
--------------------------
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
with a '-p' option, they do not produce the output described above;
instead they produce a patch file. You can customize the creation
of such patches via the GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS
environment variables.
What the -p option produces is slightly different from the traditional
diff format.
1. It is preceded with a "git diff" header, that looks like
this:
diff --git a/file1 b/file2
+
The `a/` and `b/` filenames are the same unless rename/copy is
involved. Especially, even for a creation or a deletion,
`/dev/null` is _not_ used in place of `a/` or `b/` filenames.
+
When rename/copy is involved, `file1` and `file2` show the
name of the source file of the rename/copy and the name of
the file that rename/copy produces, respectively.
2. It is followed by one or more extended header lines:
old mode <mode>
new mode <mode>
deleted file mode <mode>
new file mode <mode>
copy from <path>
copy to <path>
rename from <path>
rename to <path>
similarity index <number>
dissimilarity index <number>
index <hash>..<hash> <mode>
3. TAB, LF, double quote and backslash characters in pathnames
are represented as `\t`, `\n`, `\"` and `\\`, respectively.
If there is need for such substitution then the whole
pathname is put in double quotes.
The similarity index is the percentage of unchanged lines, and
the dissimilarity index is the percentage of changed lines. It
is a rounded down integer, followed by a percent sign. The
similarity index value of 100% is thus reserved for two equal
files, while 100% dissimilarity means that no line from the old
file made it into the new one.
combined diff format
--------------------
git-diff-tree and git-diff-files can take '-c' or '--cc' option
to produce 'combined diff', which looks like this:
Everybody uses these commands to maintain git repositories.
* gitlink:git-init[1] or gitlink:git-clone[1] to create a
* linkgit:git-init[1] or linkgit:git-clone[1] to create a
new repository.
* gitlink:git-fsck[1] to check the repository for errors.
* linkgit:git-fsck[1] to check the repository for errors.
* gitlink:git-prune[1] to remove unused objects in the repository.
* gitlink:git-repack[1] to pack loose objects for efficiency.
* gitlink:git-gc[1] to do common housekeeping tasks such as
* linkgit:git-gc[1] to do common housekeeping tasks such as
repack and prune.
Examples
@ -45,24 +41,21 @@ Check health and remove cruft.::
@@ -45,24 +41,21 @@ Check health and remove cruft.::
------------
$ git fsck <1>
$ git count-objects <2>
$ git repack <3>
$ git gc <4>
$ git gc <3>
------------
+
<1> running without `\--full` is usually cheap and assures the
repository health reasonably well.
<2> check how many loose objects there are and how much
disk space is wasted by not repacking.
<3> without `-a` repacks incrementally. repacking every 4-5MB
of loose objects accumulation may be a good rule of thumb.
<4> it is easier to use `git gc` than individual housekeeping commands
such as `prune` and `repack`. This runs `repack -a -d`.
<3> repacks the local repository and performs other housekeeping tasks. Running
without `--prune` is a safe operation even while other ones are in progress.
Repack a small project into single pack.::
+
------------
$ git repack -a -d <1>
$ git prune
$ git gc <1>
$ git gc --prune
------------
+
<1> pack all the objects reachable from the refs into one pack,
@ -76,28 +69,28 @@ A standalone individual developer does not exchange patches with
@@ -76,28 +69,28 @@ A standalone individual developer does not exchange patches with
other people, and works alone in a single repository, using the
following commands.
* gitlink:git-show-branch[1] to see where you are.
* linkgit:git-show-branch[1] to see where you are.
* gitlink:git-log[1] to see what happened.
* linkgit:git-log[1] to see what happened.
* gitlink:git-checkout[1] and gitlink:git-branch[1] to switch
* linkgit:git-checkout[1] and linkgit:git-branch[1] to switch
branches.
* gitlink:git-add[1] to manage the index file.
* linkgit:git-add[1] to manage the index file.
* gitlink:git-diff[1] and gitlink:git-status[1] to see what
* linkgit:git-diff[1] and linkgit:git-status[1] to see what
you are in the middle of doing.
* gitlink:git-commit[1] to advance the current branch.
* linkgit:git-commit[1] to advance the current branch.
* gitlink:git-reset[1] and gitlink:git-checkout[1] (with
* linkgit:git-reset[1] and linkgit:git-checkout[1] (with
pathname parameters) to undo changes.
* gitlink:git-merge[1] to merge between local branches.
* linkgit:git-merge[1] to merge between local branches.
* gitlink:git-rebase[1] to maintain topic branches.
* linkgit:git-rebase[1] to maintain topic branches.
* gitlink:git-tag[1] to mark known point.
* linkgit:git-tag[1] to mark known point.
Examples
~~~~~~~~
@ -109,7 +102,7 @@ $ tar zxf frotz.tar.gz
@@ -109,7 +102,7 @@ $ tar zxf frotz.tar.gz
$ cd frotz
$ git-init
$ git add . <1>
$ git commit -m 'import of frotz source tree.'
$ git commit -m "import of frotz source tree."
$ git tag v2.43 <2>
------------
+
@ -163,16 +156,16 @@ A developer working as a participant in a group project needs to
@@ -163,16 +156,16 @@ A developer working as a participant in a group project needs to
learn how to communicate with others, and uses these commands in
addition to the ones needed by a standalone developer.
* gitlink:git-clone[1] from the upstream to prime your local
* linkgit:git-clone[1] from the upstream to prime your local
repository.
* gitlink:git-pull[1] and gitlink:git-fetch[1] from "origin"
* linkgit:git-pull[1] and linkgit:git-fetch[1] from "origin"
to keep up-to-date with the upstream.
* gitlink:git-push[1] to shared repository, if you adopt CVS
* linkgit:git-push[1] to shared repository, if you adopt CVS
style shared repository workflow.
* gitlink:git-format-patch[1] to prepare e-mail submission, if
* linkgit:git-format-patch[1] to prepare e-mail submission, if
you adopt Linux kernel-style public forum workflow.
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
$ git reset --hard ORIG_HEAD <6>
$ git prune <7>
$ git gc --prune <7>
$ git fetch --tags <8>
------------
+
@ -265,17 +258,17 @@ project receives changes made by others, reviews and integrates
@@ -265,17 +258,17 @@ project receives changes made by others, reviews and integrates
them and publishes the result for others to use, using these
commands in addition to the ones needed by participants.
* gitlink:git-am[1] to apply patches e-mailed in from your
* linkgit:git-am[1] to apply patches e-mailed in from your
contributors.
* gitlink:git-pull[1] to merge from your trusted lieutenants.
* linkgit:git-pull[1] to merge from your trusted lieutenants.
* gitlink:git-format-patch[1] to prepare and send suggested
* linkgit:git-format-patch[1] to prepare and send suggested
alternative to contributors.
* gitlink:git-revert[1] to undo botched commits.
* linkgit:git-revert[1] to undo botched commits.
* gitlink:git-push[1] to publish the bleeding edge.
* linkgit:git-push[1] to publish the bleeding edge.
@ -37,7 +37,7 @@ directory recursion or filename globbing performed by Git (quote your
@@ -37,7 +37,7 @@ directory recursion or filename globbing performed by Git (quote your
globs before the shell) will be silently ignored. The 'add' command can
be used to add ignored files with the `-f` (force) option.
Please see gitlink:git-commit[1] for alternative ways to add content to a
Please see linkgit:git-commit[1] for alternative ways to add content to a
@ -238,4 +248,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -238,4 +248,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -157,4 +157,4 @@ Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.o
@@ -157,4 +157,4 @@ Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.o
@ -117,4 +117,4 @@ Documentation by Junio C Hamano, Martin Langhoff and the git-list <git@vger.kern
@@ -117,4 +117,4 @@ Documentation by Junio C Hamano, Martin Langhoff and the git-list <git@vger.kern
@ -118,4 +118,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -118,4 +118,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@ -16,8 +16,9 @@ The command takes various subcommands, and different options depending
@@ -16,8 +16,9 @@ The command takes various subcommands, and different options depending
@ -167,14 +191,18 @@ $ git bisect run my_script
@@ -167,14 +191,18 @@ $ git bisect run my_script
------------
Note that the "run" script (`my_script` in the above example) should
exit with code 0 in case the current source code is good and with a
code between 1 and 127 (included) in case the current source code is
bad.
exit with code 0 in case the current source code is good. Exit with a
code between 1 and 127 (inclusive), except 125, if the current
source code is bad.
Any other exit code will abort the automatic bisect process. (A
program that does "exit(-1)" leaves $? = 255, see exit(3) manual page,
the value is chopped with "& 0377".)
The special exit code 125 should be used when the current source code
cannot be tested. If the "run" script exits with this code, the current
revision will be skipped, see `git bisect skip` above.
You may often find that during bisect you want to have near-constant
tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
"revision that does not have this commit needs this patch applied to
@ -199,4 +227,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -199,4 +227,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -21,7 +21,7 @@ last modified the line. Optionally, start annotating from the given revision.
@@ -21,7 +21,7 @@ last modified the line. Optionally, start annotating from the given revision.
Also it can limit the range of lines annotated.
This report doesn't tell you anything about lines which have been deleted or
replaced; you need to use a tool such as gitlink:git-diff[1] or the "pickaxe"
replaced; you need to use a tool such as linkgit:git-diff[1] or the "pickaxe"
interface briefly mentioned in the following paragraph.
Apart from supporting file annotation, git also supports searching the
@ -20,6 +21,9 @@ With no arguments given a list of existing branches
@@ -20,6 +21,9 @@ With no arguments given a list of existing branches
will be shown, the current branch will be highlighted with an asterisk.
Option `-r` causes the remote-tracking branches to be listed,
and option `-a` shows both.
With `--contains <commit>`, shows only the branches that
contains the named commit (in other words, the branches whose
tip commits are descendant of the named commit).
In its second form, a new branch named <branchname> will be created.
It will start out with a head equal to the one given as <start-point>.
@ -30,11 +34,11 @@ Note that this will create the new branch, but it will not switch the
@@ -30,11 +34,11 @@ Note that this will create the new branch, but it will not switch the
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 can setup the
branch so that gitlink:git-pull[1] will appropriately merge from that
remote branch. If this behavior is desired, it is possible to make it
the default using the global `branch.autosetupmerge` configuration
flag. Otherwise, it can be chosen per-branch using the `--track`
When a local branch is started off a remote branch, git sets up the
branch so that linkgit:git-pull[1] will appropriately merge from that
remote branch. If this behavior is not desired, it is possible to
disable it using the global `branch.autosetupmerge` configuration
flag. That setting can be overridden by using the `--track`
and `--no-track` options.
With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.
@ -45,17 +49,22 @@ to happen.
@@ -45,17 +49,22 @@ to happen.
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
has a reflog then the reflog will also be deleted. Use -r together with -d
to delete remote-tracking branches.
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 remote repository or if linkgit:git-fetch[1] was configured not to fetch
them again. See also 'prune' subcommand of linkgit:git-remote[1] for way to
clean up all obsolete remote-tracking branches.
OPTIONS
-------
-d::
Delete a branch. The branch must be fully merged.
Delete a branch. The branch must be fully merged in HEAD.
-D::
Delete a branch irrespective of its index status.
Delete a branch irrespective of its merged status.
-l::
Create the branch's reflog. This activates recording of
<2> Delete "test" branch even if the "master" branch does not have all
commits from test branch.
<1> Delete remote-tracking branches "todo", "html", "man". Next 'fetch' or
'pull' will create them again unless you configure them not to. See
linkgit:git-fetch[1].
<2> Delete "test" branch even if the "master" branch (or whichever branch is
currently checked out) does not have all commits from test branch.
Notes
@ -176,4 +188,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -176,4 +188,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -23,7 +23,7 @@ be directly connected so the interactive git protocols (git, ssh,
@@ -23,7 +23,7 @@ be directly connected so 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
in an archive at the originating machine, then importing those into
another repository using gitlink:git-fetch[1] and gitlink:git-pull[1]
another repository using linkgit:git-fetch[1] and linkgit:git-pull[1]
after moving the archive by some means (i.e., by sneakernet). As no
direct connection between repositories exists, the user must specify a
basis for the bundle that is held by the destination repository: the
For a more complete list of ways to spell object names, see
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
-t::
Instead of the content, show the object type identified by
@ -70,4 +70,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -70,4 +70,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
set up configuration so that git-pull will automatically
retrieve data from the remote branch. Use this if you always
pull from the same remote branch into the new branch, or if you
don't want to use "git pull <repository> <refspec>" explicitly. Set the
branch.autosetupmerge configuration variable to true if you
don't want to use "git pull <repository> <refspec>" explicitly.
This behavior is the default. Set the
branch.autosetupmerge configuration variable to false if you
want git-checkout and git-branch to always behave as if
'--track' were given.
'--no-track' were given.
--no-track::
When -b is given and a branch is created off a remote branch,
@ -216,4 +217,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -216,4 +217,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -7,7 +7,7 @@ git-cherry-pick - Apply the change introduced by an existing commit
@@ -7,7 +7,7 @@ git-cherry-pick - Apply the change introduced by an existing commit
described above, and `-r` was to disable it. Now the
default is not to do `-x` so this option is a no-op.
-m parent-number|--mainline parent-number::
Usually you cannot revert a merge because you do not know which
side of the merge should be considered the mainline. This
option specifies the parent number (starting from 1) of
the mainline and allows cherry-pick to replay the change
relative to the specified parent.
-n|--no-commit::
Usually the command automatically creates a commit with
a commit log message stating which commit was
@ -67,4 +75,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -67,4 +75,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -66,4 +66,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -66,4 +66,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
for "host.xz:foo/.git"). Cloning into an existing directory
is not allowed.
:git-clone: 1
include::urls.txt[]
Examples
@ -190,4 +200,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -190,4 +200,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -103,4 +103,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -103,4 +103,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@ -20,11 +20,11 @@ commit along with a log message describing the changes you have made.
@@ -20,11 +20,11 @@ commit along with a log message describing the changes you have made.
The content to be added can be specified in several ways:
1. by using gitlink:git-add[1] to incrementally "add" changes to the
1. by using linkgit:git-add[1] to incrementally "add" changes to the
index before using the 'commit' command (Note: even modified
files must be "added");
2. by using gitlink:git-rm[1] to remove files from the working tree
2. by using linkgit:git-rm[1] 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
@ -41,13 +41,13 @@ The content to be added can be specified in several ways:
@@ -41,13 +41,13 @@ The content to be added can be specified in several ways:
by one which files should be part of the commit, before finalizing the
operation. Currently, this is done by invoking `git-add --interactive`.
The gitlink:git-status[1] command can be used to obtain a
The linkgit:git-status[1] command 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 you would give to
this command.
If you make a commit and then found a mistake immediately after
that, you can recover from it with gitlink:git-reset[1].
that, you can recover from it with linkgit:git-reset[1].
'git-config' [<file-option>] --get-color name [default]
'git-config' [<file-option>] --get-colorbool name [stdout-is-tty]
DESCRIPTION
-----------
@ -128,12 +130,27 @@ See also <<FILES>>.
@@ -128,12 +130,27 @@ See also <<FILES>>.
-z, --null::
For all options that output values and/or keys, always
end values with with the null character (instead of a
end values with the null character (instead of a
newline). Use newline instead as a delimiter between
key and value. This allows for secure parsing of the
output without getting confused e.g. by values that
contain line breaks.
--get-colorbool name [stdout-is-tty]::
Find the color setting for `name` (e.g. `color.diff`) and output
"true" or "false". `stdout-is-tty` should be either "true" or
"false", and is taken into account when configuration says
"auto". If `stdout-is-tty` is missing, then checks the standard
output of the command itself, and exits with status 0 if color
is to be used, or exits with status 1 otherwise.
--get-color name default::
Find the color configured for `name` (e.g. `color.diff.new`) and
output it as the ANSI color escape sequence to the standard
output. The optional `default` parameter is used instead, if
there is no color configured for `name`.
[[FILES]]
FILES
@ -292,6 +309,15 @@ To add a new proxy, without altering any of the existing ones, use
@@ -292,6 +309,15 @@ To add a new proxy, without altering any of the existing ones, use
% git config core.gitproxy '"proxy-command" for example.com'
------------
An example to use customized color from the configuration in your
echo "${WS}your whitespace color or blue reverse${RESET}"
------------
include::config.txt[]
@ -306,4 +332,4 @@ Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.ker
@@ -306,4 +332,4 @@ Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.ker
@ -34,4 +34,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -34,4 +34,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -8,7 +8,7 @@ git-cvsexportcommit - Export a single commit to a CVS checkout
@@ -8,7 +8,7 @@ git-cvsexportcommit - Export a single commit to a CVS checkout
@ -107,8 +107,8 @@ If you need to pass multiple options, separate them with a comma.
@@ -107,8 +107,8 @@ If you need to pass multiple options, separate them with a comma.
-M <regex>::
Attempt to detect merges based on the commit message with a custom
regex. It can be used with '-m' to also see the default regexes.
You must escape forward slashes.
regex. It can be used with '-m' to enable the default regexes
as well. You must escape forward slashes.
-S <regex>::
Skip paths matching the regex.
@ -142,7 +142,7 @@ file each time git-cvsimport is run.
@@ -142,7 +142,7 @@ 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
gitlink:git-cvsexportcommit[1].
linkgit:git-cvsexportcommit[1].
-h::
Print a short usage message and exit.
@ -166,4 +166,4 @@ Documentation by Matthias Urlichs <smurf@smurf.noris.de>.
@@ -166,4 +166,4 @@ Documentation by Matthias Urlichs <smurf@smurf.noris.de>.
'DBD::Pg', and reported *not* to work with 'DBD::mysql'.
Please regard this as an experimental feature. May not
contain double colons (`:`).
contain colons (`:`).
Default: 'SQLite'
gitcvs.dbuser::
@ -319,4 +319,4 @@ Documentation by Martyn Smith <martyn@catalyst.net.nz>, Martin Langhoff <martin@
@@ -319,4 +319,4 @@ Documentation by Martyn Smith <martyn@catalyst.net.nz>, Martin Langhoff <martin@
@ -31,8 +31,8 @@ pass some directory paths as 'git-daemon' arguments, you can further restrict
@@ -31,8 +31,8 @@ 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-peek-remote` clients that are invoked
from `git-fetch`, `git-ls-remote`, 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.
@ -166,7 +166,7 @@ the per-repository configuration file can be used to enable or
@@ -166,7 +166,7 @@ the per-repository configuration file can be used to enable or
disable them.
upload-pack::
This serves `git-fetch-pack` and `git-peek-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`.
@ -272,4 +272,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -272,4 +272,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
being employed to standard error. The tag name will still
be printed to standard out.
--match <pattern>::
Only consider tags matching the given pattern (can be used to avoid
leaking private tags made from the repository).
EXAMPLES
--------
@ -123,4 +127,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -123,4 +127,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@ -57,4 +57,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -57,4 +57,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@ -129,4 +129,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -129,4 +129,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@ -165,4 +165,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -165,4 +165,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@ -21,7 +21,7 @@ tree and the index file, or the index file and the working tree.
@@ -21,7 +21,7 @@ tree and the index file, or the index file and the working tree.
the index (staging area for the next commit). In other
words, the differences are what you _could_ tell git to
further add to the index but you still haven't. You can
stage these changes by using gitlink:git-add[1].
stage these changes by using linkgit:git-add[1].
+
If exactly two paths are given, and at least one is untracked,
compare the two files / directories. This behavior can be
@ -67,14 +67,15 @@ for the last two forms that use ".." notations, can be any
@@ -67,14 +67,15 @@ for the last two forms that use ".." notations, can be any
<tree-ish>.
For a more complete list of ways to spell <commit>, see
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
"SPECIFYING REVISIONS" section in linkgit:git-rev-parse[1].
However, "diff" is about comparing two _endpoints_, not ranges,
and the range notations ("<commit>..<commit>" and
"<commit>\...<commit>") do not mean a range as defined in the
"SPECIFYING RANGES" section in gitlink:git-rev-parse[1].
"SPECIFYING RANGES" section in linkgit:git-rev-parse[1].
the diff to the named paths (you can give directory
names and get diff for all files under them).
Output format
-------------
include::diff-format.txt[]
EXAMPLES
--------
@ -164,4 +168,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -164,4 +168,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -24,7 +24,7 @@ updated branch and tag refs, fully updating 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 gitlink:git-init[1]) or incrementally
has already been initialized by linkgit:git-init[1]) or incrementally
update an existing populated repository. Whether or not incremental
imports are supported from a particular foreign source depends on
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 gitlink:git-pack-objects[1].
to linkgit:git-pack-objects[1].
--quiet::
Disable all non-fatal output, making fast-import silent when it
@ -220,7 +220,7 @@ variation in formatting will cause fast-import to reject the value.
@@ -220,7 +220,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 gitlink:git-am[1] when applying patches
same parser used by linkgit:git-am[1] when applying patches
received from email.
+
Some malformed strings may be accepted as valid dates. In some of
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
gitlink:git-update-index[1].
linkgit:git-update-index[1].
+
If separate `author` and `committer` commands are used in a `commit`
the timestamps may not match, as the system clock will be polled
@ -411,7 +411,7 @@ Marks must be declared (via `mark`) before they can be used.
@@ -411,7 +411,7 @@ Marks must be declared (via `mark`) before they can be used.
* A complete 40 byte or abbreviated commit SHA-1 in hex.
* Any valid Git SHA-1 expression that resolves to a commit. See
``SPECIFYING REVISIONS'' in gitlink:git-rev-parse[1] for details.
``SPECIFYING REVISIONS'' in linkgit:git-rev-parse[1] for details.
The special case of restarting an incremental import from the
current branch value should be written as:
@ -649,7 +649,7 @@ recommended, as the frontend does not (easily) have access to the
@@ -649,7 +649,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 gitlink:git-tag[1] process.
with the standard linkgit:git-tag[1] process.
`reset`
~~~~~~~
@ -805,6 +805,93 @@ Placing a `progress` command immediately after a `checkpoint` will
@@ -805,6 +805,93 @@ 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.
Crash Reports
-------------
If fast-import is supplied invalid input it will terminate with a
non-zero exit status and create a crash report in the top level of
the Git repository it was importing into. Crash reports contain
a snapshot of the internal fast-import state as well as the most
recent commands that lead up to the crash.
All recent commands (including stream comments, file changes and
progress commands) are shown in the command history within the crash
report, but raw file data and commit messages are excluded from the
crash report. This exclusion saves space within the report file
and reduces the amount of buffering that fast-import must perform
during execution.
After writing a crash report fast-import will close the current
packfile and export the marks table. This allows the frontend
developer to inspect the repository state and resume the import from
the point where it crashed. The modified branches and tags are not
updated during a crash, as the import did not complete successfully.
Branch and tag information can be found in the crash report and
must be applied manually if the update is needed.
An example crash:
====
$ cat >in <<END_OF_INPUT
# my very first test commit
commit refs/heads/master
committer Shawn O. Pearce <spearce> 19283 -0400
# who is that guy anyway?
data <<EOF
this is my commit
EOF
M 644 inline .gitignore
data <<EOF
.gitignore
EOF
M 777 inline bob
END_OF_INPUT
$ git-fast-import <in
fatal: Corrupt mode: M 777 inline bob
fast-import: dumping crash report to .git/fast_import_crash_8434
$ cat .git/fast_import_crash_8434
fast-import crash report:
fast-import process: 8434
parent process : 1391
at Sat Sep 1 00:58:12 2007
fatal: Corrupt mode: M 777 inline bob
Most Recent Commands Before Crash
---------------------------------
# my very first test commit
commit refs/heads/master
committer Shawn O. Pearce <spearce> 19283 -0400
# who is that guy anyway?
data <<EOF
M 644 inline .gitignore
data <<EOF
* M 777 inline bob
Active Branch LRU
-----------------
active_branches = 1 cur, 5 max
pos clock name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 0 refs/heads/master
Inactive Branches
-----------------
refs/heads/master:
status : active loaded dirty
tip commit : 0000000000000000000000000000000000000000
old tree : 0000000000000000000000000000000000000000
cur tree : 0000000000000000000000000000000000000000
commit clock: 0
last pack :
-------------------
END OF CRASH REPORT
====
Tips and Tricks
---------------
The following tips and tricks have been collected from various
@ -863,7 +950,7 @@ is not `refs/heads/TAG_FIXUP`).
@@ -863,7 +950,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 gitlink:git-blame[1] to track
Doing so will allow tools such as linkgit:git-blame[1] to track
through the real commit history and properly annotate the source
files.
@ -892,7 +979,7 @@ Repacking Historical Data
@@ -892,7 +979,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 gitlink:git-repack[1].
\--window=50 (or higher) when you run linkgit:git-repack[1].
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.
@ -1027,4 +1114,4 @@ Documentation by Shawn O. Pearce <spearce@spearce.org>.
@@ -1027,4 +1114,4 @@ Documentation by Shawn O. Pearce <spearce@spearce.org>.
@ -53,4 +53,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -53,4 +53,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
If this filter is specified, it will be called instead of the
gitlink:git-commit-tree[1] command, with arguments of the form
linkgit:git-commit-tree[1] 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.
+
@ -116,7 +116,7 @@ have all of them as parents.
@@ -116,7 +116,7 @@ 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 gitlink:git-rebase[1] instead).
that, use linkgit:git-rebase[1] instead).
--tag-name-filter <command>::
This is the filter for rewriting tag names. When passed,
@ -152,14 +152,14 @@ definition impossible to preserve signatures at any rate.)
@@ -152,14 +152,14 @@ definition impossible to preserve signatures at any rate.)
does this in the '.git-rewrite/' directory but you can override
that choice by this parameter.
-f\|--force::
-f|--force::
`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>::
When options are given after the new branch name, they will
be passed to gitlink:git-rev-list[1]. Only commits in the resulting
be passed to linkgit:git-rev-list[1]. Only commits in the resulting
output will be filtered, although the filtered commits can still
@ -59,4 +59,4 @@ Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.o
@@ -59,4 +59,4 @@ Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.o
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 gitlink:git-am[1].
for use with linkgit:git-am[1].
There are two ways to specify which commits to operate on.
@ -33,7 +34,7 @@ There are two ways to specify which commits to operate on.
@@ -33,7 +34,7 @@ There are two ways to specify which commits to operate on.
that leads to the <since> to be output.
2. Generic <revision range> expression (see "SPECIFYING
REVISIONS" section in gitlink:git-rev-parse[1]) means the
REVISIONS" section in linkgit:git-rev-parse[1]) means the
commits in the specified range.
A single commit, when interpreted as a <revision range>
@ -65,6 +66,7 @@ reference.
@@ -65,6 +66,7 @@ reference.
@ -199,4 +205,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -199,4 +205,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -150,4 +150,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -150,4 +150,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
With this option, `git gc` checks if there are too many
loose objects in the repository and runs
gitlink:git-repack[1] with `-d -l` option to pack them.
The threshold for loose objects is set with `gc.auto` configuration
variable, and can be disabled by setting it to 0. Some
Porcelain commands use this after they perform operation
that could create many loose objects automatically.
Additionally, when there are too many packs are present,
they are consolidated into one larger pack by running
the `git-repack` command with `-A` option. The
threshold for number of packs is set with
`gc.autopacklimit` configuration variable.
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.
+
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
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
automatic consolidation of packs.
Configuration
-------------
@ -84,23 +90,23 @@ how long records of conflicted merge you have not resolved are
@@ -84,23 +90,23 @@ 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`. Without the configuration, `git-pack-refs`
is not run in bare repositories by default, to allow older dumb-transport
clients fetch from the repository, but this will change in the future.
`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.
The optional configuration variable 'gc.aggressiveWindow' controls how
much time is spent optimizing the delta compression of the objects in
the repository when the --aggressive option is specified. The larger
the value, the more time is spent optimizing the delta compression. See
the documentation for the --window' option in gitlink:git-repack[1] for
the documentation for the --window' option in linkgit:git-repack[1] for
more details. This defaults to 10.
See Also
--------
gitlink:git-prune[1]
gitlink:git-reflog[1]
gitlink:git-repack[1]
gitlink:git-rerere[1]
linkgit:git-prune[1]
linkgit:git-reflog[1]
linkgit:git-repack[1]
linkgit:git-rerere[1]
Author
------
@ -108,4 +114,4 @@ Written by Shawn O. Pearce <spearce@spearce.org>
@@ -108,4 +114,4 @@ Written by Shawn O. Pearce <spearce@spearce.org>
Acts as a filter, extracting the commit ID stored in archives created by
git-tar-tree. It reads only the first 1024 bytes of input, thus its
linkgit:git-archive[1]. 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
return code of 1. This can happen if <tarfile> had not been created
using git-tar-tree or if the first parameter of git-tar-tree 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.
@ -33,4 +33,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -33,4 +33,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
Instead of showing every matched line, show only the
names of files that contain (or do not contain) matches.
For better compatability with git-diff, --name-only is a
synonym for --files-with-matches.
-c | --count::
Instead of showing every matched line, show the number of
@ -143,4 +145,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -143,4 +145,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -16,7 +16,7 @@ on allowing users to make changes to their repository by making
@@ -16,7 +16,7 @@ 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 gitlink:gitk[1], git-gui focuses on commit generation
Unlike linkgit:gitk[1], 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.
@ -112,4 +112,4 @@ Documentation by Shawn O. Pearce <spearce@spearce.org>.
@@ -112,4 +112,4 @@ Documentation by Shawn O. Pearce <spearce@spearce.org>.
@ -42,4 +42,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -42,4 +42,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@ -53,4 +53,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -53,4 +53,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@ -8,13 +8,16 @@ git-http-push - Push objects over HTTP/DAV to another repository
@@ -8,13 +8,16 @@ git-http-push - Push objects over HTTP/DAV to another repository
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 gitlink:git-repack[1] process from deleting
simultaneous linkgit:git-repack[1] process from deleting
the newly constructed pack and index before refs can be
updated to use objects contained in the pack.
@ -83,7 +83,7 @@ Once the index has been created, the list of object names is sorted
@@ -83,7 +83,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 gitlink:git-repack[1]
.keep file used as a lock to prevent the race with linkgit:git-repack[1]
mentioned above.
@ -97,4 +97,4 @@ Documentation by Sergey Vlasov
@@ -97,4 +97,4 @@ Documentation by Sergey Vlasov
@ -52,7 +52,7 @@ is given:
@@ -52,7 +52,7 @@ is given:
- 'all' (or 'world' or 'everybody'): Same as 'group', but make the repository
readable by all users.
By default, the configuration flag receive.denyNonFastforward is enabled
By default, the configuration flag receive.denyNonFastForwards is enabled
in shared repositories, so that you cannot force a non fast-forwarding push
into it.
@ -111,4 +111,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -111,4 +111,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
Show only commits that affect the specified paths.
include::rev-list-options.txt[]
include::pretty-formats.txt[]
include::diff-generate-patch.txt[]
Examples
--------
@ -124,4 +112,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -124,4 +112,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
*NOTE*: this command is deprecated. Use linkgit:git-fsck[1] with
the option '--lost-found' instead.
Finds dangling commits and tags from the object database, and
creates refs to them in the .git/lost-found/ directory. Commits and
tags that dereference to commits are stored in .git/lost-found/commit,
@ -74,4 +78,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -74,4 +78,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
'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. gitlink:gitignore[5]
flags --others or --ignored are specified. linkgit:gitignore[5]
specifies the format of exclude patterns.
These exclude patterns come from these places, in order:
@ -173,7 +179,7 @@ pattern file appears in.
@@ -173,7 +179,7 @@ pattern file appears in.
See Also
--------
gitlink:git-read-tree[1], gitlink:gitignore[5]
linkgit:git-read-tree[1], linkgit:gitignore[5]
Author
@ -186,4 +192,4 @@ Documentation by David Greaves, Junio C Hamano, Josh Triplett, and the git-list
@@ -186,4 +192,4 @@ Documentation by David Greaves, Junio C Hamano, Josh Triplett, and the git-list
@ -91,4 +91,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list
@@ -91,4 +91,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list
@ -18,7 +18,7 @@ writes the commit log message in <msg> file, and the patches in
@@ -18,7 +18,7 @@ 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
to create a commit. It is usually not necessary to use this
command directly. See gitlink:git-am[1] instead.
command directly. See linkgit:git-am[1] instead.
OPTIONS
@ -66,4 +66,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -66,4 +66,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -55,4 +55,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -55,4 +55,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -39,4 +39,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -39,4 +39,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@ -41,7 +41,7 @@ conflicts otherwise. If the merge was clean, the exit value is 0.
@@ -41,7 +41,7 @@ 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
implements all of RCS merge's functionality which is needed by
gitlink:git[1].
linkgit:git[1].
OPTIONS
@ -89,4 +89,4 @@ with parts copied from the original documentation of RCS merge.
@@ -89,4 +89,4 @@ with parts copied from the original documentation of RCS merge.
@ -84,4 +84,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -84,4 +84,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@ -26,4 +26,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -26,4 +26,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@ -33,4 +33,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -33,4 +33,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
If you tried a merge which resulted in a complex conflicts and
would want to start over, you can recover with
gitlink:git-reset[1].
linkgit:git-reset[1].
CONFIGURATION
-------------
@ -73,14 +74,14 @@ it happens. In other words, `git-diff --cached HEAD` must
@@ -73,14 +74,14 @@ it happens. In other words, `git-diff --cached HEAD` must
report no changes.
[NOTE]
This is a bit of lie. In certain special cases, your index are
allowed to be different from the tree of `HEAD` commit. The most
This is a bit of a lie. In certain special cases, your index is
allowed to be different from the tree of the `HEAD` commit. The most
notable case is when your `HEAD` commit is already ahead of what
is being merged, in which case your index can have arbitrary
difference from your `HEAD` commit. Otherwise, your index entries
are allowed have differences from your `HEAD` commit that match
the result of trivial merge (e.g. you received the same patch
from external source to produce the same result as what you are
differences from your `HEAD` commit. Also, your index entries
may have differences from your `HEAD` commit that match
the result of a trivial merge (e.g. you received the same patch
from an external source to produce the same result as what you are
merging). For example, if a path did not exist in the common
ancestor and your head commit but exists in the tree you are
merging into your repository, and if you already happen to have
@ -162,7 +163,8 @@ After seeing a conflict, you can do two things:
@@ -162,7 +163,8 @@ After seeing a conflict, you can do two things:
@ -176,4 +178,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@@ -176,4 +178,4 @@ Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
@ -43,4 +43,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
@@ -43,4 +43,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
GIT
---
Part of the gitlink:git[7] suite
Part of the linkgit:git[7] suite
Some files were not shown because too many files have changed in this diff
Show More
Junio C Hamano
17 years ago