Recommend format-patch and send-email for those who want to submit
patches to this project.
* jc/submitting-patches-mention-send-email:
SubmittingPatches: encourage users to use format-patch and send-email
"git prune" used to largely ignore broken refs when deciding which
objects are still being used, which could spread an existing small
damage and make it a larger one.
* jk/prune-with-corrupt-refs:
refs.c: drop curate_packed_refs
repack: turn on "ref paranoia" when doing a destructive repack
prune: turn on ref_paranoia flag
refs: introduce a "ref paranoia" flag
t5312: test object deletion code paths in a corrupted repository
The "also" sounds as if "preserve" does a rebase as an additional
step that "true" would not do, but that is not the case. Clarify
this by omitting "also", and rewording the sentence a bit.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The help text for the --force-with-lease option to git-push
does not parse cleanly. Clean up the wording and syntax to
be more sensible. Also remove redundant information in the
"--force-with-lease alone" description.
Signed-off-by: Phil Hord <hordp@cisco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git prune" used to largely ignore broken refs when deciding which
objects are still being used, which could spread an existing small
damage and make it a larger one.
* jk/prune-with-corrupt-refs:
refs.c: drop curate_packed_refs
repack: turn on "ref paranoia" when doing a destructive repack
prune: turn on ref_paranoia flag
refs: introduce a "ref paranoia" flag
t5312: test object deletion code paths in a corrupted repository
Recommend format-patch and send-email for those who want to submit
patches to this project.
* jc/submitting-patches-mention-send-email:
SubmittingPatches: encourage users to use format-patch and send-email
"git log --graph --no-walk A B..." is a otcnflicting request that
asks nonsense; no-walk tells us show discrete points in the
history, while graph asks to draw connections between these
discrete points. Forbid the combination.
* dj/log-graph-with-no-walk:
revision: forbid combining --graph and --no-walk
"git rev-list --bisect --first-parent" does not work (yet) and can
even cause SEGV; forbid it. "git log --bisect --first-parent"
would not be useful until "git bisect --first-parent" materializes,
so it is also forbidden for now.
* kd/rev-list-bisect-first-parent:
rev-list: refuse --first-parent combined with --bisect
Add $XDG_CONFIG_HOME/git/credentials to the default credential search
path of git-credential-store. This allows git-credential-store to
support user-specific configuration files in accordance with the XDG
base directory specification[1].
[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.7.html
~/.git-credentials has a higher precedence than
$XDG_CONFIG_HOME/git/credentials when looking up credentials. This
means that if any duplicate matching credentials are found in the xdg
file (due to ~/.git-credentials being updated by old versions of git or
outdated tools), they will not be used at all. This is to give the user
some leeway in switching to old versions of git while keeping the xdg
directory. This is consistent with the behavior of git-config.
However, the higher precedence of ~/.git-credentials means that as long
as ~/.git-credentials exist, all credentials will be written to the
~/.git-credentials file even if the user has an xdg file as having a
~/.git-credentials file indicates that the user wants to preserve
backwards-compatibility. This is also consistent with the behavior of
git-config.
To make this precedence explicit in docs/git-credential-store, add a new
section FILES that lists out the credential file paths in their order of
precedence, and explain how the ordering affects the lookup, storage and
erase operations.
Also, update the documentation for --file to briefly explain the
operations on multiple files if the --file option is not provided.
Since the xdg file will not be used unless it actually exists, to
prevent the situation where some credentials are present in the xdg file
while some are present in the home file, users are recommended to not
create the xdg file if they require compatibility with old versions of
git or outdated tools. Note, though, that "erase" can be used to
explicitly erase matching credentials from all files.
Helped-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Jeff King <peff@peff.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Paul Tan <pyokagan@gmail.com>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
At the first look, a user may think the default version is "23". Even
with UNIX background, there's no reference anywhere close that may
indicate this is glob or regex.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Restructure "git push" codepath to make it easier to add new
configuration bits and then add push.followTags configuration that
turns --follow-tags option on by default.
* jk/push-config:
push: allow --follow-tags to be set by config push.followTags
cmd_push: pass "flags" pointer to config callback
cmd_push: set "atomic" bit directly
git_push_config: drop cargo-culted wt_status pointer
"git log --decorate" did not reset colors correctly around the
branch names.
* jc/decorate-leaky-separator-color:
log --decorate: do not leak "commit" color into the next item
Documentation/config.txt: simplify boolean description in the syntax section
Documentation/config.txt: describe 'color' value type in the "Values" section
Documentation/config.txt: have a separate "Values" section
Documentation/config.txt: describe the structure first and then meaning
Documentation/config.txt: explain multi-valued variables once
Documentation/config.txt: avoid unnecessary negation
"git imap-send" learned to optionally talk with an IMAP server via
libcURL; because there is no other option when Git is built with
NO_OPENSSL option, use that codepath by default under such
configuration.
* km/imap-send-libcurl-options:
imap-send: use cURL automatically when NO_OPENSSL defined
"git log --decorate" did not reset colors correctly around the
branch names.
* jc/decorate-leaky-separator-color:
log --decorate: do not leak "commit" color into the next item
Documentation/config.txt: simplify boolean description in the syntax section
Documentation/config.txt: describe 'color' value type in the "Values" section
Documentation/config.txt: have a separate "Values" section
Documentation/config.txt: describe the structure first and then meaning
Documentation/config.txt: explain multi-valued variables once
Documentation/config.txt: avoid unnecessary negation
"git imap-send" learned to optionally talk with an IMAP server via
libcURL; because there is no other option when Git is built with
NO_OPENSSL option, use that codepath by default under such
configuration.
* km/imap-send-libcurl-options:
imap-send: use cURL automatically when NO_OPENSSL defined
The versionsort.prerelease configuration variable can be used to
specify that v1.0-pre1 comes before v1.0.
* nd/versioncmp-prereleases:
config.txt: update versioncmp.prereleaseSuffix
versionsort: support reorder prerelease suffixes
Most operations that iterate over refs are happy to ignore
broken cruft. However, some operations should be performed
with knowledge of these broken refs, because it is better
for the operation to choke on a missing object than it is to
silently pretend that the ref did not exist (e.g., if we are
computing the set of reachable tips in order to prune
objects).
These processes could just call for_each_rawref, except that
ref iteration is often hidden behind other interfaces. For
instance, for a destructive "repack -ad", we would have to
inform "pack-objects" that we are destructive, and then it
would in turn have to tell the revision code that our
"--all" should include broken refs.
It's much simpler to just set a global for "dangerous"
operations that includes broken refs in all iterations.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rev-list --bisect is used by git bisect, but never together with
--first-parent. Because rev-list --bisect together with --first-parent
is not handled currently, and even leads to segfaults, refuse to use
both options together.
Because this is not supported, it makes little sense to use git log
--bisect --first parent either, because refs/heads/bad is not limited to
the first parent chain.
Helped-by: Junio C. Hamano <gitster@pobox.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Kevin Daudt <me@ikke.info>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because "--graph" is about connected history while --no-walk is
about discrete points, it does not make sense to allow these two
options at the same time. [1]
This change makes a few calls to "show --graph" fail in t4052, but
asking to show one commit with graph is a nonsensical thing to do.
Thus, tests on "show --graph" in t4052 have been removed [2,3].
Same tests on "show" without --graph option have already been tested
in 4052.
3 testcases have been added to test this patch.
[1]: http://article.gmane.org/gmane.comp.version-control.git/216083
[2]: http://article.gmane.org/gmane.comp.version-control.git/264950
[3]: http://article.gmane.org/gmane.comp.version-control.git/265107
Helped-By: Eric Sunshine <sunshine@sunshineco.com>
Helped-By: René Scharfe <l.s.r@web.de>
Helped-By: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Dongcan Jiang <dongcan.jiang@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git status" now allows the "-v" to be given twice to show the
differences that are left in the working tree not to be committed.
* mg/status-v-v:
commit/status: show the index-worktree diff with -v -v
t7508: test git status -v
t7508: .gitignore 'expect' and 'output' files
In step "(4) Sending your patches", we instruct users to do an
inline patch, avoid breaking whitespaces, avoid attachments, use
[PATCH v2] for second round, etc., all of which format-patch and
send-email combo know how to do well.
The need was identified by, and the text is based on the work by
Cody Taylor.
Suggested-by: Cody Taylor <cody.taylor@maternityneighborhood.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git remote add" mentioned "--tags" and "--no-tags" and was not
clear that fetch from the remote in the future will use the default
behaviour when neither is given to override it.
* mg/doc-remote-tags-or-not:
git-remote.txt: describe behavior without --tags and --no-tags
The interaction between "git submodule update" and the
submodule.*.update configuration was not clearly documented.
* ms/submodule-update-config-doc:
submodule: improve documentation of update subcommand
"git apply" was not very careful about reading from, removing,
updating and creating paths outside the working tree (under
--index/--cached) or the current directory (when used as a
replacement for GNU patch).
* jc/apply-beyond-symlink:
apply: do not touch a file beyond a symbolic link
apply: do not read from beyond a symbolic link
apply: do not read from the filesystem under --index
apply: reject input that touches outside the working area
This should improve readability. Compare "thislongname" and
"thisLongName". The following keys are left in unchanged. We can
decide what to do with them later.
- am.keepcr
- core.autocrlf .safecrlf .trustctime
- diff.dirstat .noprefix
- gitcvs.usecrlfattr
- gui.blamehistoryctx .trustmtime
- pull.twohead
- receive.autogc
- sendemail.signedoffbycc .smtpsslcertpath .suppresscc
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reported-by: "Mladen B." <mladen074@gmail.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If both USE_CURL_FOR_IMAP_SEND and NO_OPENSSL are defined do
not force the user to add --curl to get a working git imap-send
command.
Instead automatically select --curl and warn and ignore the
--no-curl option. And while we're in there, correct the
warning message when --curl is requested but not supported.
Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Various issues around "reflog expire", e.g. using --updateref when
expiring a reflog for a symbolic reference, have been corrected
and/or made saner.
* mh/expire-updateref-fixes:
reflog_expire(): never update a reference to null_sha1
reflog_expire(): ignore --updateref for symbolic references
reflog: improve and update documentation
struct ref_lock: delete the force_write member
lock_ref_sha1_basic(): do not set force_write for missing references
write_ref_sha1(): move write elision test to callers
write_ref_sha1(): remove check for lock == NULL
The interaction between "git submodule update" and the
submodule.*.update configuration was not clearly documented.
* ms/submodule-update-config-doc:
submodule: improve documentation of update subcommand
"git remote add" mentioned "--tags" and "--no-tags" and was not
clear that fetch from the remote in the future will use the default
behaviour when neither is given to override it.
* mg/doc-remote-tags-or-not:
git-remote.txt: describe behavior without --tags and --no-tags
The configuration variable 'mailinfo.scissors' was hard to
discover in the documentation.
* mm/am-c-doc:
Documentation/git-am.txt: mention mailinfo.scissors config variable
Documentation/config.txt: document mailinfo.scissors
git commit and git status in long format show the diff between HEAD
and the index when given -v. This allows previewing a commit to be made.
They also list tracked files with unstaged changes, but without a diff.
Introduce '-v -v' which shows the diff between the index and the
worktree in addition to the HEAD index diff. This allows a review of unstaged
changes which might be missing from the commit.
In the case of '-v -v', additonal header lines
Changes to be committed:
and
Changes not staged for commit:
are inserted before the diffs, which are equal to those in the status
part; the latter preceded by 50*"-" to make it stick out more.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Longstanding configuration variable naming rules has been added to
the documentation.
* jc/conf-var-doc:
CodingGuidelines: describe naming rules for configuration variables
config.txt: mark deprecated variables more prominently
config.txt: clarify that add.ignore-errors is deprecated
Clarify in the documentation that "remote.<nick>.pushURL" and
"remote.<nick>.URL" are there to name the same repository accessed
via different transports, not two separate repositories.
* jc/remote-set-url-doc:
Documentation/git-remote.txt: stress that set-url is not for triangular
The configuration variable 'mailinfo.scissors' was hard to
discover in the documentation.
* mm/am-c-doc:
Documentation/git-am.txt: mention mailinfo.scissors config variable
Documentation/config.txt: document mailinfo.scissors
If we are expiring reflog entries for a symbolic reference, then how
should --updateref be handled if the newest reflog entry is expired?
Option 1: Update the referred-to reference. (This is what the current
code does.) This doesn't make sense, because the referred-to reference
has its own reflog, which hasn't been rewritten.
Option 2: Update the symbolic reference itself (as in, REF_NODEREF).
This would convert the symbolic reference into a non-symbolic
reference (e.g., detaching HEAD), which is surely not what a user
would expect.
Option 3: Error out. This is plausible, but it would make the
following usage impossible:
git reflog expire ... --updateref --all
Option 4: Ignore --updateref for symbolic references.
We choose to implement option 4.
Note: another problem in this code will be fixed in a moment.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Revamp the "git reflog" usage documentation in the manpage and the
command help to match the current reality and improve its clarity:
* Add documentation for some options that had been left out.
* Group the subcommands and options more logically and move more
common subcommands/options higher.
* Improve some explanations.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In "git log --decorate", you would see the commit header like this:
commit ... (HEAD, jc/decorate-leaky-separator-color)
where "commit ... (" is painted in color.diff.commit, "HEAD" in
color.decorate.head, ", " in color.diff.commit, the branch name in
color.decorate.branch and then closing ")" in color.diff.commit.
If you wanted to paint the HEAD and local branch name in the same
color as the body text (perhaps because cyan and green are too faint
on a black-on-white terminal to be readable), you would not want to
have to say
[color "decorate"]
head = black
branch = black
because that you would not be able to reuse same configuration on a
white-on-black terminal. You would naively expect
[color "decorate"]
head = normal
branch = normal
to work, but unfortunately it does not. It paints the string "HEAD"
and the branch name in the same color as the opening parenthesis or
comma between the decoration elements. This is because the code
forgets to reset the color after printing the "prefix" in its own
color.
It theoretically is possible that some people were expecting and
relying on that the attribute set as the "diff.commit" color, which
is used to draw these opening parenthesis and inter-item comma, is
inherited by the drawing of branch names, but it is not how the
coloring works everywhere else.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'true' short-hand doesn't deserve a separate sentence; even our own
git config --bool foo.bar yes
would not produce it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of describing it for color.branch.<slot> and have everybody
else refer to it, explain how colors are spelled in "Values" section
upfront.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The various types of values set to the configuration variables
deserve more than a brief footnote mention in the syntax section,
and it will be more so after the later steps of this clean up
effort.
Move the mention of booleans from the syntax section to this new
section, and describe how human-readble integers can be spelled with
scaling there.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A line can be continued via a backquote-LF and can be chomped at a
comment character. But that is not specific to string-typed values.
It is common to all, just like unquoted leading and trailing
whitespaces are stripped and inter-word spacing are retained.
Move the description around and desribe these structural rules
first, then introduce the double-quote facility as a way to override
them, and finally mention various types of values.
Note that these structural rules only apply to the value part of the
configuration file. E.g.
[aSection] \
name \
= value
does not work, because the rules kick in only after seeing "name =".
Both the original and the updated text are phrased in an awkward way
by singling out the "value" part of the line because of this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The syntax section repeats what the preamble explained already.
That a variable can have multiple values is more about what a
variable is than the syntax of the file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Section names and variable names are both case-insensitive, but one
is described as "not case sensitive". Use "case-insensitive" for
both.
Instead of saying "... have to be escaped" without telling what that
escaping achieves, state it in a more positive way, i.e. "... can be
included by escaping".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git apply" was not very careful about reading from, removing,
updating and creating paths outside the working tree (under
--index/--cached) or the current directory (when used as a
replacement for GNU patch).
* jc/apply-beyond-symlink:
apply: do not touch a file beyond a symbolic link
apply: do not read from beyond a symbolic link
apply: do not read from the filesystem under --index
apply: reject input that touches outside the working area
The documentation of 'git submodule update' has several problems:
1) It mentions that value 'none' of submodule.$name.update can be
overridden by --checkout, but other combinations of configuration
values and command line options are not mentioned.
2) The documentation of submodule.$name.update is scattered across three
places, which is confusing.
3) The documentation of submodule.$name.update in gitmodules.txt is
incorrect, because the code always uses the value from .git/config
and never from .gitmodules.
4) Documentation of --force was incomplete, because it is only effective
in case of checkout method of update.
Fix all these problems by documenting submodule.*.update in
git-submodule.txt and make everybody else refer to it.
Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is needed in build automation where the tree really needs to
be reset to known state.
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The strbuf API was explained between the API documentation and in
the header file. Move missing bits to strbuf.h so that programmers
can check only one place for all necessary information.
* jk/strbuf-doc-to-header:
strbuf.h: group documentation for trim functions
strbuf.h: drop boilerplate descriptions of strbuf_split_*
strbuf.h: reorganize api function grouping headers
strbuf.h: format asciidoc code blocks as 4-space indent
strbuf.h: drop asciidoc list formatting from API docs
strbuf.h: unify documentation comments beginnings
strbuf.h: integrate api-strbuf.txt documentation
The error handling functions and conventions are now documented in
the API manual.
* jn/doc-api-errors:
doc: document error handling functions and conventions
"git log --help" used to show rev-list options that are irrelevant
to the "log" command.
* jc/doc-log-rev-list-options:
Documentation: what does "git log --indexed-objects" even mean?
The documentation incorrectly said that C(opy) and R(ename) are the
only ones that can be followed by the score number in the output in
the --raw format.
* jc/diff-format-doc:
diff-format doc: a score can follow M for rewrite
The "git push" documentation made the "--repo=<there>" option
easily misunderstood.
* mg/push-repo-option-doc:
git-push.txt: document the behavior of --repo
Longstanding configuration variable naming rules has been added to
the documentation.
* jc/conf-var-doc:
CodingGuidelines: describe naming rules for configuration variables
config.txt: mark deprecated variables more prominently
config.txt: clarify that add.ignore-errors is deprecated
It was already documented, but the user had to follow the link to
git-mailinfo.txt to find it.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The variable was documented in git-mailinfo.txt, but not in config.txt.
The detailed documentation is still the one of --scissors in
git-mailinfo.txt, but we give enough information here to let the user
understand what it is about, and to make it easy to find it (e.g.
searching ">8" and "8<" finds it).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Clarify in the documentation that "remote.<nick>.pushURL" and
"remote.<nick>.URL" are there to name the same repository accessed
via different transports, not two separate repositories.
* jc/remote-set-url-doc:
Documentation/git-remote.txt: stress that set-url is not for triangular
The "git push" documentation made the "--repo=<there>" option
easily misunderstood.
* mg/push-repo-option-doc:
git-push.txt: document the behavior of --repo
The documentation incorrectly said that C(opy) and R(ename) are the
only ones that can be followed by the score number in the output in
the --raw format.
* jc/diff-format-doc:
diff-format doc: a score can follow M for rewrite
"git log --help" used to show rev-list options that are irrelevant
to the "log" command.
* jc/doc-log-rev-list-options:
Documentation: what does "git log --indexed-objects" even mean?
Extending the js/push-to-deploy topic, the behaviour of "git push"
when updating the working tree and the index with an update to the
branch that is checked out can be tweaked by push-to-checkout hook.
* jc/push-to-checkout:
receive-pack: support push-to-checkout hook
receive-pack: refactor updateInstead codepath
"git push" has been taught a "--atomic" option that makes push to
update more than one ref an "all-or-none" affair.
* sb/atomic-push:
Document receive.advertiseatomic
t5543-atomic-push.sh: add basic tests for atomic pushes
push.c: add an --atomic argument
send-pack.c: add --atomic command line argument
send-pack: rename ref_update_to_be_sent to check_to_send_update
receive-pack.c: negotiate atomic push support
receive-pack.c: add execute_commands_atomic function
receive-pack.c: move transaction handling in a central place
receive-pack.c: move iterating over all commands outside execute_commands
receive-pack.c: die instead of error in case of possible future bug
receive-pack.c: shorten the execute_commands loop over all commands
"git log --invert-grep --grep=WIP" will show only commits that do
not have the string "WIP" in their messages.
* cj/log-invert-grep:
log: teach --invert-grep option
The clone subcommand has long had support for excluding
subdirectories, but sync has not. This is a nuisance,
since as soon as you do a sync, any changed files that
were initially excluded start showing up.
Move the "exclude" command-line option into the parent
class; the actual behavior was already present there so
it simply had to be exposed.
Signed-off-by: Luke Diamand <luke@diamand.org>
Reviewed-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default, a patch that affects outside the working area (either a
Git controlled working tree, or the current working directory when
"git apply" is used as a replacement of GNU patch) is rejected as a
mistake (or a mischief). Git itself does not create such a patch,
unless the user bends over backwards and specifies a non-standard
prefix to "git diff" and friends.
When `git apply` is used as a "better GNU patch", the user can pass
the `--unsafe-paths` option to override this safety check. This
option has no effect when `--index` or `--cached` is in use.
The new test was stolen from Jeff King with slight enhancements.
Note that a few new tests for touching outside the working area by
following a symbolic link are still expected to fail at this step,
but will be fixed in later steps.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
