Also add titles to paragraphs under "CONFIGURATION VARIABLES".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The options --upload-pack (of git-fetch-pack) and --receive-pack (of
git-push) do the same as --exec (for both commands). But the former options
have the more descriptive name.
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently git mergetool is restricted to a set of commands defined
in the script. You can subvert the mergetool.<tool>.path to force
git mergetool to use a different command, but if you have a command
whose invocation syntax does not match one of the current tools then
you would have to write a wrapper script for it.
This patch adds two git config variable patterns which allow a more
flexible choice of merge tool.
If you run git mergetool with -t/--tool or the merge.tool config
variable set to an unrecognized tool then git mergetool will query the
mergetool.<tool>.cmd config variable. If this variable exists, then git
mergetool will treat the specified tool as a custom command and will use
a shell eval to run the command with the documented shell variables set.
mergetool.<tool>.trustExitCode can be used to indicate that the exit
code of the custom command can be used to determine the success of the
merge.
Signed-off-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently a backup pre-merge file with conflict markers is sometimes
kept with a .orig extenstion and sometimes removed depending on the
particular merge tool used.
This patch makes the handling consistent across all merge tools and
configurable via a new mergetool.keepBackup config variable
Signed-off-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running log/show/whatchanged from the command line, the user may
want to use a preferred format without having to pass --pretty=<fmt>
option every time from the command line. This teaches these three
commands to honor a new configuration variable, format.pretty.
The --pretty option given from the command line will override the
configured format.
The earlier patch fixed the in-tree callers that run these commands
for purposes other than showing the output directly to the end user
(the only other in-tree caller is "git bisect visualize", whose output
directly goes to the end user and should be affected by this patch).
Similar fixes will be needed for end-user scripts that parse the
output from these commands and expect them to be in the default pretty
format.
Signed-off-by: Denis Cheng <crquan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a configuration variable receive.fsckobjects is set,
receive-pack runs unpack-objects with --strict mode to check all
received objects.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier we had a cop-out in the documentation to make the
behaviour "undefined" if configuration had more than one
insteadOf that would match the target URL, like this:
[url "git://git.or.cz/"]
insteadOf = "git.or.cz:" ; (1)
insteadOf = "repo.or.cz:" ; (2)
[url "/local/mirror/"]
insteadOf = "git.or.cz:myrepo" ; (3)
insteadOf = "repo.or.cz:" ; (4)
It would be most natural to take the longest and first match, i.e.
- rewrite "git.or.cz:frotz" to "git://git.or.cz/frotz" by using
(1),
- rewrite "git.or.cz:myrepo/xyzzy" to "/local/mirror/xyzzy" by favoring
(3) over (1), and
- rewrite "repo.or.cz:frotz" to "git://git.or.cz/frotz" by
favoring (2) over (4).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows users with different preferences for access methods to the
same remote repositories to rewrite each other's URLs by pattern
matching across a large set of similiarly set up repositories to each
get the desired access.
For example, if you don't have a kernel.org account, you might want
settings like:
[url "git://git.kernel.org/pub/"]
insteadOf = master.kernel.org:/pub
Then, if you give git a URL like:
master.kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6.git
it will act like you gave it:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
and you can cut-and-paste pull requests in email without fixing them
by hand, for example.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Packing objects can be done in parallell nowadays, but it's
only done if the config option pack.threads is set to a value
above 1. Because of that, the code-path used is often not the
most optimal one.
This patch adds a routine to detect the number of online CPU's
at runtime (online_cpus()). When pack.threads (or --threads=) is
given a value of 0, the number of threads is set to the number of
online CPU's. This feature is also documented.
As per Nicolas Pitre's recommendations, the default is still to
run pack-objects single-threaded unless explicitly activated,
either by configuration or by command line parameter.
The routine online_cpus() is a rework of "numcpus.c", written by
one Philip Willoughby <pgw99@doc.ic.ac.uk>. numcpus.c is in the
public domain and can presently be downloaded from
http://csgsoft.doc.ic.ac.uk/numcpus/
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documents the branch.autosetupmerge=always setting and usage of --track
when branching from a local branch.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 34a3e69 (git-branch: default to --track) the default was changed to
true, to help new git users. But yours truly forgot to update the
documentation. This fixes it.
Noticed by Kalle Olavi Niemitalo.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git pack-objects" has the option --max-pack-size to limit the file
size of the packs to a certain amount of bytes. On platforms where
the pack file size is limited by filesystem constraints, it is easy
to forget this option, and this option does not exist for "git gc"
to begin with.
So introduce a config variable to set the default maximum, but make
this overrideable by the command line.
Suggested by Tor Arvid Lund.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CRLF conversion bears a slight chance of corrupting data.
autocrlf=true will convert CRLF to LF during commit and LF to
CRLF during checkout. A file that contains a mixture of LF and
CRLF before the commit cannot be recreated by git. For text
files this is the right thing to do: it corrects line endings
such that we have only LF line endings in the repository.
But for binary files that are accidentally classified as text the
conversion can corrupt data.
If you recognize such corruption early you can easily fix it by
setting the conversion type explicitly in .gitattributes. Right
after committing you still have the original file in your work
tree and this file is not yet corrupted. You can explicitly tell
git that this file is binary and git will handle the file
appropriately.
Unfortunately, the desired effect of cleaning up text files with
mixed line endings and the undesired effect of corrupting binary
files cannot be distinguished. In both cases CRLFs are removed
in an irreversible way. For text files this is the right thing
to do because CRLFs are line endings, while for binary files
converting CRLFs corrupts data.
This patch adds a mechanism that can either warn the user about
an irreversible conversion or can even refuse to convert. The
mechanism is controlled by the variable core.safecrlf, with the
following values:
- false: disable safecrlf mechanism
- warn: warn about irreversible conversions
- true: refuse irreversible conversions
The default is to warn. Users are only affected by this default
if core.autocrlf is set. But the current default of git is to
leave core.autocrlf unset, so users will not see warnings unless
they deliberately chose to activate the autocrlf mechanism.
The safecrlf mechanism's details depend on the git command. The
general principles when safecrlf is active (not false) are:
- we warn/error out if files in the work tree can modified in an
irreversible way without giving the user a chance to backup the
original file.
- for read-only operations that do not modify files in the work tree
we do not not print annoying warnings.
There are exceptions. Even though...
- "git add" itself does not touch the files in the work tree, the
next checkout would, so the safety triggers;
- "git apply" to update a text file with a patch does touch the files
in the work tree, but the operation is about text files and CRLF
conversion is about fixing the line ending inconsistencies, so the
safety does not trigger;
- "git diff" itself does not touch the files in the work tree, it is
often run to inspect the changes you intend to next "git add". To
catch potential problems early, safety triggers.
The concept of a safety check was originally proposed in a similar
way by Linus Torvalds. Thanks to Dimitry Potapov for insisting
on getting the naked LF/autocrlf=true case right.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
This new error mode allows a line to have a carriage return at the
end of the line when checking and fixing trailing whitespace errors.
Some people like to keep CRLF line ending recorded in the repository,
and still want to take advantage of the automated trailing whitespace
stripping. We still show ^M in the diff output piped to "less" to
remind them that they do have the CR at the end, but these carriage
return characters at the end are no longer flagged as errors.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rerere.enabled is _not_ on by default. The command is enabled if rr-cache
exists even when rerere.enabled is missing, and enabled or disabled by
explicitly setting the rerere.enabled variable.
This documents the default values of gc.auto, gc.autopacklimit
fetch.unpacklimit, receive.unpacklimit and transfer.unpacklimit.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are two possible confusions with the color.interactive
description:
1. the short name "interactive" implies that it covers all
interactive commands; let's explicitly make it so, even
though there are no other interactive commands which
currently use it
2. Not all parts of "git add --interactive" are controlled
by color.interactive (specifically, the diffs require
tweaking color.diff). So let's clarify that it applies
only to displays and prompts.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock
Asciidoc configuration:
@@ -149,7 +153,10 @@
# Inline macros.
# Backslash prefix required for escape processing.
# (?s) re flag for line spanning.
-(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
+# Explicit so they can be nested.
+(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
# Anchor: [[[id]]]. Bibliographic anchor.
(?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3
# Anchor: [[id,xreflabel]]
This default regex now matches explicit values, and unfortunately in this
case gitlink was being matched by just 'link', causing the wrong inline
macro template to be applied. By renaming the macro, we can avoid being
matched by the wrong regex.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There was no documentation for the config variables diff.external
and mergetool.<tool>.path.
Noticed by Sebastian Schuberth.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The output of git-status was recently changed to output relative
paths. Setting this variable to false restores the old behavior for
any old-timers that prefer it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is mostly lifted from earlier series by Dan Zwell, but updated to
use "git config --get-color" and "git config --get-colorbool" to make it
simpler and more consistent with commands written in C.
A new configuration color.interactive variable is like color.diff and
color.status, and controls if "git-add -i" uses color.
A set of configuration variables, color.interactive.<slot>, are used to
define what color is used for the prompt, header, and help text.
For perl scripts, Git.pm provides $repo->get_color() method, which takes
the slot name and the default color, and returns the terminal escape
sequence to color the output text. $repo->get_colorbool() method can be
used to check if color is set to be used for a given operation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As well as allowing a default http.proxy option, allow it to be set
per-remote.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The http_proxy / HTTPS_PROXY variables used by curl to control
proxying may not be suitable for git. Allow the user to override them
in the configuration file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calling 'git pull' with the '--rebase' option, it performs a
fetch + rebase instead of a fetch + merge.
This behavior is more desirable than fetch + pull when a topic branch
is ready to be submitted and needs to be update.
fetch + rebase might also be considered a better workflow with shared
repositories in any case, or for contributors to a centrally managed
repository, such as WINE's.
As a convenience, you can set the default behavior for a branch by
defining the config variable branch.<name>.rebase, which is
interpreted as a bool. This setting can be overridden on the command
line by --rebase and --no-rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds description of core.whitespace to the manual page of git-config,
and updates the stale description of whitespace handling in the manual
page of git-apply.
Also demote "strip" to a synonym status for "fix" as the value of --whitespace
option given to git-apply.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Clarify that core.compression provides a system-wide default to
other compression parameters.
* Explain that the default for pack.compression, -1, is "a default
compromise between speed and compression (currently equivalent
to level 6)" according to zlib.h.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* core.loosecompression stated that the default was "0 (best speed)",
when in fact 0 is "no compression", and the default is Z_BEST_SPEED,
which is 1.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes the clean.requireForce configuration default to true.
Too many people are burned by typing "git clean" by mistake when
they meant to say "make clean".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
format.numbered is a tri-state variable. Boolean values enable or
disable numbering by default and "auto" enables number when outputting
more than one patch.
--no-numbered (short: -N) will disable numbering.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is a good idea to use pack index version 2 all the time since it has
proper protection against propagation of certain pack corruptions when
repacking which is not possible with index version 1, as demonstrated
in test t5302.
Hence this config option.
The default is still pack index version 1.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There was an 'l' (ell) instead of a '1' (one) in one of the gitlinks.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This enables per branch configuration of merge options. Currently, the most
useful options to specify per branch are --squash, --summary/--no-summary
and possibly --strategy, but all options are supported.
Note: Options containing whitespace will _not_ be handled correctly. Luckily,
the only option which can include whitespace is --message and it doesn't
make much sense to give that option a default value.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thanks to Johannes Schindelin for review and fixes, and Julian
Phillips for the original C translation.
This changes a few small bits of behavior:
branch.<name>.merge is parsed as if it were the lhs of a fetch
refspec, and does not have to exactly match the actual lhs of a
refspec, so long as it is a valid abbreviation for the same ref.
branch.<name>.merge is no longer ignored if the remote is configured
with a branches/* file. Neither behavior is useful, because there can
only be one ref that gets fetched, but this is more consistant.
Also, fetch prints different information to standard out.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches "git-gc --auto" to consolidate many packs into one
without losing unreachable objects in them by using "repack -A"
when there are too many packfiles that are not marked with *.keep
in the repository. gc.autopacklimit configuration can be used
to set the maximum number of packs a repository is allowed to
have before this mechanism kicks in.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano