summaryrefslogtreecommitdiff
path: root/Documentation/config.txt
AgeCommit message (Collapse)AuthorFilesLines
2007-03-18Limit the size of the new delta_base_cacheLibravatar Shawn O. Pearce1-0/+13
The new configuration variable core.deltaBaseCacheLimit allows the user to control how much memory they are willing to give to Git for caching base objects of deltas. This is not normally meant to be a user tweakable knob; the "out of the box" settings are meant to be suitable for almost all workloads. We default to 16 MiB under the assumption that the cache is not meant to consume all of the user's available memory, and that the cache's main purpose was to cache trees, for faster path limiters during revision traversal. Since trees tend to be relatively small objects, this relatively small limit should still allow a large number of objects. On the other hand we don't want the cache to start storing 200 different versions of a 200 MiB blob, as this could easily blow the entire address space of a 32 bit process. We evict OBJ_BLOB from the cache first (credit goes to Junio) as we want to favor OBJ_TREE within the cache. These are the objects that have the highest inflate() startup penalty, as they tend to be small and thus don't have that much of a chance to ammortize that penalty over the entire data. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-18mergetool: Add support for vimdiff.Libravatar James Bowes1-1/+1
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2007-03-16git-fetch, git-branch: Support local --track via a special remote '.'Libravatar Paolo Bonzini1-0/+4
This patch adds support for a dummy remote '.' to avoid having to declare a fake remote like [remote "local"] url = . fetch = refs/heads/*:refs/heads/* Such a builtin remote simplifies the operation of "git-fetch", which will populate FETCH_HEAD but will not pretend that two repositories are in use, will not create a thin pack, and will not perform any useless remapping of names. The speed improvement is around 20%, and it should improve more if "git-fetch" is converted to a builtin. To this end, git-parse-remote is grown with a new kind of remote, 'builtin'. In git-fetch.sh, we treat the builtin remote specially in that it needs no pack/store operations. In fact, doing git-fetch on a builtin remote will simply populate FETCH_HEAD appropriately. The patch also improves of the --track/--no-track support, extending it so that branch.<name>.remote items referring '.' can be created. Finally, it fixes a typo in git-checkout.sh. Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-13Add git-mergetool to run an appropriate merge conflict resolution programLibravatar Theodore Ts'o1-0/+5
The git-mergetool program can be used to automatically run an appropriate merge resolution program to resolve merge conflicts. It will automatically run one of kdiff3, tkdiff, meld, xxdiff, or emacs emerge programs. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2007-03-04Merge branch 'js/symlink'Libravatar Junio C Hamano1-0/+7
* js/symlink: Tell multi-parent diff about core.symlinks. Handle core.symlinks=false case in merge-recursive. Add core.symlinks to mark filesystems that do not support symbolic links.
2007-03-03Merge branch 'maint'Libravatar Junio C Hamano1-0/+5
* maint: Unset NO_C99_FORMAT on Cygwin. Fix a "pointer type missmatch" warning. Fix some "comparison is always true/false" warnings. Fix an "implicit function definition" warning. Fix a "label defined but unreferenced" warning. Document the config variable format.suffix git-merge: fail correctly when we cannot fast forward. builtin-archive: use RUN_SETUP Fix git-gc usage note
2007-03-03Document the config variable format.suffixLibravatar Johannes Schindelin1-0/+5
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-02Add core.symlinks to mark filesystems that do not support symbolic links.Libravatar Johannes Sixt1-0/+7
Some file systems that can host git repositories and their working copies do not support symbolic links. But then if the repository contains a symbolic link, it is impossible to check out the working copy. This patch enables partial support of symbolic links so that it is possible to check out a working copy on such a file system. A new flag core.symlinks (which is true by default) can be set to false to indicate that the filesystem does not support symbolic links. In this case, symbolic links that exist in the trees are checked out as small plain files, and checking in modifications of these files preserve the symlink property in the database (as long as an entry exists in the index). Of course, this does not magically make symbolic links work on such defective file systems; hence, this solution does not help if the working copy relies on that an entry is a real symbolic link. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-26Documentation: document remote.<name>.tagoptLibravatar Aneesh Kumar K.V1-0/+4
Update config.txt with info regarding tagopt option Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-24Merge branch 'js/etc-config'Libravatar Junio C Hamano1-1/+2
* js/etc-config: Make tests independent of global config files config: read system-wide defaults from /etc/gitconfig
2007-02-24Merge branch 'maint'Libravatar Junio C Hamano1-4/+11
* maint: diff-patch: Avoid emitting double-slashes in textual patch. Reword git-am 3-way fallback failure message. Limit filename for format-patch core.legacyheaders: Use the description used in RelNotes-1.5.0 git-show-ref --verify: Fail if called without a reference Conflicts: builtin-show-ref.c diff.c
2007-02-24core.legacyheaders: Use the description used in RelNotes-1.5.0Libravatar Santi Béjar1-4/+11
It explains what it does and why, and says how to use the new format. Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22Merge branch 'maint'Libravatar Junio C Hamano1-0/+12
* maint: git-diff: fix combined diff Fix 'git commit -a' in a newly initialized repository Include git-gui credits file in dist. Document the new core.bare configuration option.
2007-02-21Document the new core.bare configuration option.Libravatar Shawn O. Pearce1-0/+12
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-20Allow git-remote to update named groups of remotesLibravatar Theodore Ts'o1-4/+8
In response to a feature request from Shawn Pearce, this patch allows a user to update a named group of remotes by using "git remote update <group>", where the group is defined in the config file by remotes.<group>. The default if the named group is not specified is now fetched group remotes.default, instead of remote.fetch, which is what had been previously used. In addition, if remotes.default is not defined, all remotes defined in the config file will be used, as before, but there is now also possible to request that a particular repository to be skipped by default by using the boolean configuration parameter remote.<name>.skipDefaultUpdate. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-19config: read system-wide defaults from /etc/gitconfigLibravatar Johannes Schindelin1-1/+2
The settings in /etc/gitconfig can be overridden in ~/.gitconfig, which in turn can be overridden in .git/config. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-19Teach git-remote to update existing remotes by fetching from themLibravatar Theodore Ts'o1-0/+4
This allows users to use the command "git remote update" to update all remotes that are being tracked in the repository. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13git-gc: run pack-refs by default unless the repo is bareLibravatar Johannes Schindelin1-0/+11
The config variable gc.packrefs is tristate now: "true", "false" and "notbare", where "notbare" is the default. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-10Allow aliases to expand to shell commandsLibravatar Theodore Ts'o1-0/+6
If the alias expansion is prefixed with an exclamation point, treat it as a shell command which is run using system(3). Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03Assorted typo fixesLibravatar Pavel Roskin1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince1-1/+1
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-28Documentation/config.txt: Fix documentation of colour config tweaks.Libravatar Mark Wooding1-10/+16
* The description of valid colour specifications was rather incomplete, so fix it so that it actually describes colour specs as accepted by color_parse(). * The list of colour items allowed in color.diff.BLAH was missing the `commit' and `whitespace' entries. Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-27Allow the tag signing key to be specified in the config fileLibravatar Andy Parkins1-0/+7
I did this: $ git tag -s test-sign gpg: skipped "Andy Parkins <andyparkins@gmail.com>": secret key not available gpg: signing failed: secret key not available failed to sign the tag with GPG. The problem is that I have used the comment field in my key's UID definition. $ gpg --list-keys andy pub 1024D/4F712F6D 2003-08-14 uid Andy Parkins (Google) <andyparkins@gmail.com> So when git-tag looks for "Andy Parkins <andyparkins@gmail.com>"; obviously it's not going to be found. There shouldn't be a requirement that I use the same form of my name in my git repository and my gpg key - I might want to be formal (Andrew) in my gpg key and informal (Andy) in the repository. Further I might have multiple keys in my keyring, and might want to use one that doesn't match up with the address I use in commit messages. This patch adds a configuration entry "user.signingkey" which, if present, will be passed to the "-u" switch for gpg, allowing the tag signing key to be overridden. If the entry is not present, the fallback is the original method, which means existing behaviour will continue untouched. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-24make --upload-pack option to git-fetch configurableLibravatar Uwe Kleine-König1-1/+5
This introduces the config item remote.<name>.uploadpack to override the default value (which is "git-upload-pack"). Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-24Consolidate {receive,fetch}.unpackLimitLibravatar Junio C Hamano1-0/+5
This allows transfer.unpackLimit to specify what these two configuration variables want to set. We would probably want to deprecate the two separate variables, as I do not see much point in specifying them independently. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-24fetch-pack: remove --keep-auto and make it the default.Libravatar Junio C Hamano1-0/+10
This makes git-fetch over git native protocol to automatically decide to keep the downloaded pack if the fetch results in more than 100 objects, just like receive-pack invoked by git-push does. This logic is disabled when --keep is explicitly given from the command line, so that a very small clone still keeps the downloaded pack as before. The 100 threshold can be adjusted with fetch.unpacklimit configuration. We might want to introduce transfer.unpacklimit to consolidate the two unpacklimit variables, which will be a topic for the next patch. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-24Documentation/config.txt: Correct info about subsection nameLibravatar Jakub Narebski1-2/+2
Contrary to variable values, in subsection names parsing character escape codes (besides literal escaping of " as \", and \ as \\) is not performed; subsection name cannot contain newlines. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-22Documentation/config.txt: Document config file syntax betterLibravatar Jakub Narebski1-7/+69
Separate part of Documentation/config.txt which deals with git config file syntax into "Syntax" subsection, and expand it. Add information about subsections, boolean values, escaping and escape sequences in string values, and continuing variable value on the next line. Add also proxy settings to config file example to show example of partially enclosed in double quotes string value. Parts based on comments by Junio C Hamano, Johannes Schindelin, config.c, and the smb.conf(5) man page. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-19make --exec=... option to git-push configurableLibravatar Uwe Kleine-König1-0/+4
Having to specify git push --exec=... is annoying if you cannot have git-receivepack in your PATH on the remote side (or don't want to). This introduces the config item remote.<name>.receivepack to override the default value (which is "git-receive-pack"). Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-16Document where configuration files are in config.txtLibravatar Junio C Hamano1-1/+6
Talking about what the files contain without talking about where they are does not help new users. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-14Allow the user to control the verbosity of merge-recursive.Libravatar Shawn O. Pearce1-0/+7
Junio C Hamano <junkio@cox.net> writes: > > I think the output from merge-recursive can be categorized into 5 > verbosity levels: > > 1. "CONFLICT", "Rename", "Adding here instead due to D/F conflict" > (outermost) > > 2. "Auto-merged successfully" (outermost) > > 3. The first "Merging X with Y". > > 4. outermost "Merging:\ntitle1\ntitle2". > > 5. outermost "found N common ancestors\nancestor1\nancestor2\n..." > and anything from inner merge. > > I would prefer the default verbosity level to be 2 (that is, show > both 1 and 2). and this change makes it so. I think level 3 is probably pointless as its only one line of output above level 2, but I can see how some users may want to view it but not view the slightly more verbose output of level 4. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12use 'init' instead of 'init-db' for shipped docs and toolsLibravatar Nicolas Pitre1-1/+1
While 'init-db' still is and probably will always remain a valid git command for obvious backward compatibility reasons, it would be a good idea to move shipped tools and docs to using 'init' instead. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-07Merge branch 'sp/mmap'Libravatar Junio C Hamano1-0/+28
* sp/mmap: (27 commits) Spell default packedgitlimit slightly differently Increase packedGit{Limit,WindowSize} on 64 bit systems. Update packedGit config option documentation. mmap: set FD_CLOEXEC for file descriptors we keep open for mmap() pack-objects: fix use of use_pack(). Fix random segfaults in pack-objects. Cleanup read_cache_from error handling. Replace mmap with xmmap, better handling MAP_FAILED. Release pack windows before reporting out of memory. Default core.packdGitWindowSize to 1 MiB if NO_MMAP. Test suite for sliding window mmap implementation. Create pack_report() as a debugging aid. Support unmapping windows on 'temporary' packfiles. Improve error message when packfile mmap fails. Ensure core.packedGitWindowSize cannot be less than 2 pages. Load core configuration in git-verify-pack. Fully activate the sliding window pack access. Unmap individual windows rather than entire files. Document why header parsing won't exceed a window. Loop over pack_windows when inflating/accessing data. ... Conflicts: cache.h pack-check.c
2007-01-06Increase packedGit{Limit,WindowSize} on 64 bit systems.Libravatar Shawn O. Pearce1-6/+10
If we have a 64 bit address space we can easily afford to commit a larger amount of virtual address space to pack file access. So on these platforms we should increase the default settings of core.packedGit{Limit,WindowSize} to something that will better handle very large projects. Thanks to Andy Whitcroft for pointing out that we can safely increase these defaults on such systems. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-03Add documentation for git-branch's color configuration.Libravatar Brian Gernhardt1-6/+18
Added color.branch and color.branch.<slot> to configuration list. Style copied from color.status and meanings derived from the code. Moved the color meanings from color.diff.<slot> to color.branch.<slot> since the latter comes first alphabetically. Added --color and --no-color to git-branch's usage and documentation. Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-30Update packedGit config option documentation.Libravatar Shawn O. Pearce1-2/+6
Corrected minor typos and documented the new k/m/g suffix for core.packedGitWindowSize and core.packedGitLimit. [jc: with a minor markup fix.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-30Merge branch 'master' into sp/mmapLibravatar Junio C Hamano1-7/+7
* master: Documentation/config.txt (and repo-config manpage): mark-up fix. Teach Git how to parse standard power of 2 suffixes. Use /dev/null for update hook stdin. Redirect update hook stdout to stderr. Remove unnecessary argc parameter from run_command_v. Automatically detect a bare git repository. Replace "GIT_DIR" with GIT_DIR_ENVIRONMENT. Use PATH_MAX constant for --bare. Force core.filemode to false on Cygwin. Fix formatting for urls section of fetch, pull, and push manpages Fix yet another subtle xdl_merge() bug i18n: drop "encoding" header in the output after re-coding. commit-tree: cope with different ways "utf-8" can be spelled. Move commit reencoding parameter parsing to revision.c Documentation: minor rewording for git-log and git-show pages. Documentation: i18n commit log message notes. t3900: test log --encoding=none commit re-encoding: fix confusion between no and default conversion.
2006-12-30Documentation/config.txt (and repo-config manpage): mark-up fix.Libravatar Junio C Hamano1-7/+7
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-29Fully activate the sliding window pack access.Libravatar Shawn O. Pearce1-0/+11
This finally turns on the sliding window behavior for packfile data access by mapping limited size windows and chaining them under the packed_git->windows list. We consider a given byte offset to be within the window only if there would be at least 20 bytes (one hash worth of data) accessible after the requested offset. This range selection relates to the contract that use_pack() makes with its callers, allowing them to access one hash or one object header without needing to call use_pack() for every byte of data obtained. In the worst case scenario we will map the same page of data twice into memory: once at the end of one window and once again at the start of the next window. This duplicate page mapping will happen only when an object header or a delta base reference is spanned over the end of a window and is always limited to just one page of duplication, as no sane operating system will ever have a page size smaller than a hash. I am assuming that the possible wasted page of virtual address space is going to perform faster than the alternatives, which would be to copy the object header or ref delta into a temporary buffer prior to parsing, or to check the window range on every byte during header parsing. We may decide to revisit this decision in the future since this is just a gut instinct decision and has not actually been proven out by experimental testing. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-29Introduce new config option for mmap limit.Libravatar Shawn O. Pearce1-0/+9
Rather than hardcoding the maximum number of bytes which can be mmapped from pack files we should make this value configurable, allowing the end user to increase or decrease this limit on a per-repository basis depending on the size of the repository and the capabilities of their operating system. In general users should not need to manually tune such a low-level setting within the core code, but being able to artifically limit the number of bytes which we can mmap at once from pack files will make it easier to craft test cases for the new mmap sliding window implementation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-28Merge branch 'jc/utf8'Libravatar Junio C Hamano1-0/+4
* jc/utf8: t3900: test conversion to non UTF-8 as well Rename t3900 test vector file UTF-8: introduce i18n.logoutputencoding. Teach log family --encoding i18n.logToUTF8: convert commit log message to UTF-8 Move encoding conversion routine out of mailinfo to utf8.c Conflicts: commit.c
2006-12-27UTF-8: introduce i18n.logoutputencoding.Libravatar Junio C Hamano1-0/+4
It is plausible for somebody to want to view the commit log in a different encoding from i18n.commitencoding -- the project's policy may be UTF-8 and the user may be using a commit message hook to run iconv to conform to that policy (and either not have i18n.commitencoding to default to UTF-8 or have it explicitly set to UTF-8). Even then, Latin-1 may be more convenient for the usual pager and the terminal the user uses. The new variable i18n.logoutputencoding is used in preference to i18n.commitencoding to decide what encoding to recode the log output in when git-log and friends formats the commit log message. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-27git-reflog: gc.* configuration and documentation.Libravatar Junio C Hamano1-0/+9
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-27rerere gc: honor configuration and document itLibravatar Junio C Hamano1-0/+10
Two configuration to control the expiration of rerere records are introduced and documented. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-18Add config example with respect to branchLibravatar Aneesh Kumar K.V1-0/+5
Update config.txt with example with respect to branch config variable. This give a better idea regarding how branch names are expected. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Align section headers of 'git status' to new 'git add'.Libravatar Shawn O. Pearce1-2/+2
Now that 'git add' is considered a first-class UI for 'update-index' and that the 'git add' documentation states "Even modified files must be added to the set of changes about to be committed" we should make the output of 'git status' align with that documentation and common usage. So now we see a status output such as: # Added but not yet committed: # (will commit) # # new file: x # # Changed but not added: # (use "git add file1 file2" to include for commit) # # modified: x # # Untracked files: # (use "git add" on files to include for commit) # # y which just reads better in the context of using 'git add' to manipulate a commit (and not a checkin, whatever the heck that is). We also now support 'color.status.added' as an alias for the existing 'color.status.updated', as this alias more closely aligns with the current output and documentation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-15Enable reflogs by default in any repository with a working directory.Libravatar Shawn O. Pearce1-2/+5
New and experienced Git users alike are finding out too late that they forgot to enable reflogs in the current repository, and cannot use the information stored within it to recover from an incorrectly entered command such as `git reset --hard HEAD^^^` when they really meant HEAD^^ (aka HEAD~2). So enable reflogs by default in all future versions of Git, unless the user specifically disables it with: [core] logAllRefUpdates = false in their .git/config or ~/.gitconfig. We only enable reflogs in repositories that have a working directory associated with them, as shared/bare repositories do not have an easy means to prune away old log entries, or may fail logging entirely if the user's gecos information is not valid during a push. This heuristic was suggested on the mailing list by Junio. Documentation was also updated to indicate the new default behavior. We probably should start to teach usuing the reflog to recover from mistakes in some of the tutorial material, as new users are likely to make a few along the way and will feel better knowing they can recover from them quickly and easily, without fsck-objects' lost+found features. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-13config documentation: group color items together.Libravatar Junio C Hamano1-18/+18
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-13Allow subcommand.color and color.subcommand color configurationLibravatar Andy Parkins1-6/+6
While adding colour to the branch command it was pointed out that a config option like "branch.color" conflicts with the pre-existing "branch.something" namespace used for specifying default merge urls and branches. The suggested solution was to flip the order of the components to "color.branch", which I did for colourising branch. This patch does the same thing for - git-log (color.diff) - git-status (color.status) - git-diff (color.diff) - pager (color.pager) I haven't removed the old config options; but they should probably be deprecated and eventually removed to prevent future namespace collisions. I've done this deprecation by changing the documentation for the config file to match the new names; and adding the "color.XXX" options to contrib/completion/git-completion.bash. Unfortunately git-svn reads "diff.color" and "pager.color"; which I don't like to change unilaterally. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-08Add branch.*.merge warning and documentation updateLibravatar Josef Weidendorfer1-2/+9
This patch clarifies the meaning of the branch.*.merge option. Previously, if branch.*.merge was specified but did not match any ref, the message "No changes." was not really helpful regarding the misconfiguration. This patch adds a warning for this. Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>