aboutsummaryrefslogtreecommitdiff
path: root/Documentation/config.txt
Commit message (Collapse)AuthorAge
* Sync with 'maint'Junio C Hamano2013-02-25
|\ | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Merge branch 'jc/mention-tracking-for-pull-default' into maintJunio C Hamano2013-02-25
| |\ | | | | | | | | | | | | * jc/mention-tracking-for-pull-default: doc: mention tracking for pull.default
| * | Documentation: "advice" is uncountableGreg Price2013-02-25
| | | | | | | | | | | | | | | | | | | | | | | | "Advice" is a mass noun, not a count noun; it's not ordinarily pluralized. Signed-off-by: Greg Price <price@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | Merge branch 'ss/help-htmlpath-config-doc' into maintJunio C Hamano2013-01-28
| |\ \ | | | | | | | | | | | | | | | | * ss/help-htmlpath-config-doc: config.txt: Document help.htmlpath config parameter
* | \ \ Merge branch 'jc/mention-tracking-for-pull-default'Junio C Hamano2013-02-18
|\ \ \ \ | | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | We stopped mentioning `tracking` is a deprecated but supported synonym for `upstream` in pull.default even though we have no intention of removing the support for it. * jc/mention-tracking-for-pull-default: doc: mention tracking for pull.default
| * | | doc: mention tracking for pull.defaultJunio C Hamano2013-01-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When looking at a configuration file edited long time ago, a user may find 'pull.default = tracking' and wonder what it means, but earlier we stopped mentioning this value, even though the code still support it and more importantly, we have no intention to force old timers to update their configuration files. Instead of not mentioning it, add it to the description in a way that makes it clear that users have no reason to add new uses of it preferring over 'upstream', by not listing it as a separate item on the same footing as other values but as a deprecated synonym of the 'upstream' in its description. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'jc/hidden-refs'Junio C Hamano2013-02-17
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow the server side to redact the refs/ namespace it shows to the client. Will merge to 'master'. * jc/hidden-refs: upload/receive-pack: allow hiding ref hierarchies upload-pack: simplify request validation upload-pack: share more code
| * | | | upload/receive-pack: allow hiding ref hierarchiesJunio C Hamano2013-02-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A repository may have refs that are only used for its internal bookkeeping purposes that should not be exposed to the others that come over the network. Teach upload-pack to omit some refs from its initial advertisement by paying attention to the uploadpack.hiderefs multi-valued configuration variable. Do the same to receive-pack via the receive.hiderefs variable. As a convenient short-hand, allow using transfer.hiderefs to set the value to both of these variables. Any ref that is under the hierarchies listed on the value of these variable is excluded from responses to requests made by "ls-remote", "fetch", etc. (for upload-pack) and "push" (for receive-pack). Because these hidden refs do not count as OUR_REF, an attempt to fetch objects at the tip of them will be rejected, and because these refs do not get advertised, "git push :" will not see local branches that have the same name as them as "matching" ones to be sent. An attempt to update/delete these hidden refs with an explicit refspec, e.g. "git push origin :refs/hidden/22", is rejected. This is not a new restriction. To the pusher, it would appear that there is no such ref, so its push request will conclude with "Now that I sent you all the data, it is time for you to update the refs. I saw that the ref did not exist when I started pushing, and I want the result to point at this commit". The receiving end will apply the compare-and-swap rule to this request and rejects the push with "Well, your update request conflicts with somebody else; I see there is such a ref.", which is the right thing to do. Otherwise a push to a hidden ref will always be "the last one wins", which is not a good default. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'ta/doc-no-small-caps'Junio C Hamano2013-02-05
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update documentation to change "GIT" which was a poor-man's small caps to "Git". The latter was the intended spelling. Also change "git" spelled in all-lowercase to "Git" when it refers to the system as the whole or the concept it embodies, as opposed to the command the end users would type. * ta/doc-no-small-caps: Documentation: StGit is the right spelling, not StGIT Documentation: describe the "repository" in repository-layout Documentation: add a description for 'gitfile' to glossary Documentation: do not use undefined terms git-dir and git-file Documentation: the name of the system is 'Git', not 'git' Documentation: avoid poor-man's small caps GIT
| * | | | | Documentation: the name of the system is 'Git', not 'git'Thomas Ackermann2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | Merge branch 'jc/push-reject-reasons'Junio C Hamano2013-02-04
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Improve error and advice messages given locally when "git push" refuses when it cannot compute fast-forwardness by separating these cases from the normal "not a fast-forward; merge first and push again" case. * jc/push-reject-reasons: push: finishing touches to explain REJECT_ALREADY_EXISTS better push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE push: further simplify the logic to assign rejection reason push: further clean up fields of "struct ref"
| * | | | | | push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCEJunio C Hamano2013-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we push to update an existing ref, if: * the object at the tip of the remote is not a commit; or * the object we are pushing is not a commit, it won't be correct to suggest to fetch, integrate and push again, as the old and new objects will not "merge". We should explain that the push must be forced when there is a non-committish object is involved in such a case. If we do not have the current object at the tip of the remote, we do not even know that object, when fetched, is something that can be merged. In such a case, suggesting to pull first just like non-fast-forward case may not be technically correct, but in practice, most such failures are seen when you try to push your work to a branch without knowing that somebody else already pushed to update the same branch since you forked, so "pull first" would work as a suggestion most of the time. And if the object at the tip is not a commit, "pull first" will fail, without making any permanent damage. As a side effect, it also makes the error message the user will get during the next "push" attempt easier to understand, now the user is aware that a non-commit object is involved. In these cases, the current code already rejects such a push on the client end, but we used the same error and advice messages as the ones used when rejecting a non-fast-forward push, i.e. pull from there and integrate before pushing again. Introduce new rejection reasons and reword the messages appropriately. [jc: with help by Peff on message details] Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | Merge branch 'jc/custom-comment-char'Junio C Hamano2013-02-04
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow a configuration variable core.commentchar to customize the character used to comment out the hint lines in the edited text from the default '#'. * jc/custom-comment-char: Allow custom "comment char"
| * | | | | | | Allow custom "comment char"Junio C Hamano2013-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some users do want to write a line that begin with a pound sign, #, in their commit log message. Many tracking system recognise a token of #<bugid> form, for example. The support we offer these use cases is not very friendly to the end users. They have a choice between - Don't do it. Avoid such a line by rewrapping or indenting; and - Use --cleanup=whitespace but remove all the hint lines we add. Give them a way to set a custom comment char, e.g. $ git -c core.commentchar="%" commit so that they do not have to do either of the two workarounds. [jc: although I started the topic, all the tests and documentation updates, many of the call sites of the new strbuf_add_commented_*() functions, and the change to git-submodule.sh scripted Porcelain are from Ralf.] Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | Enable minimal stat checkingRobin Rosenberg2013-01-22
| |_|/ / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specifically the fields uid, gid, ctime, ino and dev are set to zero by JGit. Other implementations, eg. Git in cygwin are allegedly also somewhat incompatible with Git For Windows and on *nix platforms the resolution of the timestamps may differ. Any stat checking by git will then need to check content, which may be very slow, particularly on Windows. Since mtime and size is typically enough we should allow the user to tell git to avoid checking these fields if they are set to zero in the index. This change introduces a core.checkstat config option where the the user can select to check all fields (default), or just size and the whole second part of mtime (minimal). Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | Merge branch 'rt/commit-cleanup-config'Junio C Hamano2013-01-20
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a configuration variable to set default clean-up mode other than "strip". * rt/commit-cleanup-config: commit: make default of "cleanup" option configurable
| * | | | | | | commit: make default of "cleanup" option configurableRalf Thielow2013-01-10
| |/ / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default of the "cleanup" option in "git commit" is not configurable. Users who don't want to use the default have to pass this option on every commit since there's no way to configure it. This commit introduces a new config option "commit.cleanup" which can be used to change the default of the "cleanup" option in "git commit". Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | Merge branch 'ap/log-mailmap'Junio C Hamano2013-01-20
|\ \ \ \ \ \ \ | |_|_|/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach commands in the "log" family to optionally pay attention to the mailmap. * ap/log-mailmap: log --use-mailmap: optimize for cases without --author/--committer search log: add log.mailmap configuration option log: grep author/committer using mailmap test: add test for --use-mailmap option log: add --use-mailmap option pretty: use mailmap to display username and email mailmap: add mailmap structure to rev_info and pp mailmap: simplify map_user() interface mailmap: remove email copy and length limitation Use split_ident_line to parse author and committer string-list: allow case-insensitive string list
| * | | | | | log: add log.mailmap configuration optionAntoine Pelisse2013-01-10
| | |_|_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach "log.mailmap" configuration variable to turn "--use-mailmap" option on to "git log", "git show" and "git whatchanged". The "--no-use-mailmap" option from the command line can countermand the setting. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | Merge branch 'ss/help-htmlpath-config-doc'Junio C Hamano2013-01-18
|\ \ \ \ \ \ | |_|/ / / / |/| | | | / | | |_|_|/ | |/| | | | | | | | | | | | | Add missing doc. * ss/help-htmlpath-config-doc: config.txt: Document help.htmlpath config parameter
| * | | | config.txt: Document help.htmlpath config parameterSebastian Staudt2013-01-15
| | |_|/ | |/| | | | | | | | | | | | | | Signed-off-by: Sebastian Staudt <koraktor@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'nd/maint-branch-desc-doc'Junio C Hamano2013-01-09
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach various forms of "format-patch" command line to identify what branch the patches are taken from, so that the branch description is picked up in more cases. * nd/maint-branch-desc-doc: format-patch: pick up branch description when no ref is specified format-patch: pick up correct branch name from symbolic ref t4014: a few more tests on cover letter using branch description branch: delete branch description if it's empty config.txt: a few lines about branch.<name>.description
| * | | | config.txt: a few lines about branch.<name>.descriptionNguyễn Thái Ngọc Duy2013-01-01
| |/ / / | | | | | | | | | | | | | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'wk/submodule-update-remote'Junio C Hamano2013-01-05
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The beginning of 'integrate with the tip of the remote branch, not the commit recorded in the superproject gitlink' support. * wk/submodule-update-remote: submodule add: If --branch is given, record it in .gitmodules submodule update: add --remote for submodule's upstream changes submodule: add get_submodule_config helper funtion
| * | | | submodule update: add --remote for submodule's upstream changesW. Trevor King2012-12-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current `update` command incorporates the superproject's gitlinked SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the options you use, it may checkout $sha1, rebase the $subsha1 onto $sha1, or merge $sha1 into $subsha1. This helps you keep up with changes in the upstream superproject. However, it's also useful to stay up to date with changes in the upstream subproject. Previous workflows for incorporating such changes include the ungainly: $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' With this patch, all of the useful functionality for incorporating superproject changes can be reused to incorporate upstream subproject updates. When you specify --remote, the target $sha1 is replaced with a $sha1 of the submodule's origin/master tracking branch. If you want to merge a different tracking branch, you can configure the `submodule.<name>.branch` option in `.gitmodules`. You can override the `.gitmodules` configuration setting for a particular superproject by configuring the option in that superproject's default configuration (using the usual configuration hierarchy, e.g. `.git/config`, `~/.gitconfig`, etc.). Previous use of submodule.<name>.branch ======================================= Because we're adding a new configuration option, it's a good idea to check if anyone else is already using the option. The foreach-pull example above was described by Ævar in commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Date: Fri May 21 16:10:10 2010 +0000 git-submodule foreach: Add $toplevel variable Gerrit uses the same interpretation for the setting, but because Gerrit has direct access to the subproject repositories, it updates the superproject repositories automatically when a subproject changes. Gerrit also accepts the special value '.', which it expands into the superproject's branch name. Although the --remote functionality is using `submodule.<name>.branch` slightly differently, the effect is the same. The foreach-pull example uses the option to record the name of the local branch to checkout before pulls. The tracking branch to be pulled is recorded in `.git/modules/<name>/config`, which was initialized by the module clone during `submodule add` or `submodule init`. Because the branch name stored in `submodule.<name>.branch` was likely the same as the branch name used during the initial `submodule add`, the same branch will be pulled in each workflow. Implementation details ====================== In order to ensure a current tracking branch state, `update --remote` fetches the submodule's remote repository before calculating the SHA-1. However, I didn't change the logic guarding the existing fetch: if test -z "$nofetch" then # Run fetch only if $sha1 isn't present or it # is not reachable from a ref. (clear_local_git_env; cd "$path" && ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) && test -z "$rev") || git-fetch)) || die "$(eval_gettext "Unable to fetch in submodule path '\$path'")" fi There will not be a double-fetch, because the new $sha1 determined after the `--remote` triggered fetch should always exist in the repository. If it doesn't, it's because some racy process removed it from the submodule's repository and we *should* be re-fetching. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'jk/mailmap-from-blob'Junio C Hamano2013-01-05
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow us to read, and default to read, mailmap files from the tip of the history in bare repositories. This will help running tools like shortlog in server settings. * jk/mailmap-from-blob: mailmap: default mailmap.blob in bare repositories mailmap: fix some documentation loose-ends for mailmap.blob mailmap: clean up read_mailmap error handling mailmap: support reading mailmap from blobs mailmap: refactor mailmap parsing for non-file sources
| * | | | | mailmap: default mailmap.blob in bare repositoriesJeff King2012-12-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The motivation for mailmap.blob is to let users of bare repositories use the mailmap feature, as they would not have a checkout containing the .mailmap file. We can make it even easier for them by just looking in HEAD:.mailmap by default. We can't know for sure that this is where they would keep a mailmap, of course, but it is the best guess (and it matches the non-bare behavior, which reads from HEAD:.mailmap in the working tree). If it's missing, git will silently ignore the setting. We do not do the same magic in the non-bare case, because: 1. In the common case, HEAD:.mailmap will be the same as the .mailmap in the working tree, which is a no-op. 2. In the uncommon case, the user has modified .mailmap but not yet committed it, and would expect the working tree version to take precedence. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | mailmap: support reading mailmap from blobsJeff King2012-12-12
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a bare repository, there isn't a simple way to respect an in-tree mailmap without extracting it to a temporary file. This patch provides a config variable, similar to mailmap.file, which reads the mailmap from a blob in the repository. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'cr/push-force-tag-update'Junio C Hamano2013-01-05
|\ \ \ \ \ | |/ / / / |/| | | / | | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Require "-f" for push to update a tag, even if it is a fast-forward. * cr/push-force-tag-update: push: allow already-exists advice to be disabled push: rename config variable for more general use push: cleanup push rules comment push: clarify rejection of update to non-commit-ish push: require force for annotated tags push: require force for refs under refs/tags/ push: flag updates that require force push: keep track of "update" state separately push: add advice for rejected tag reference push: return reject reasons as a bitset
| * | | push: allow already-exists advice to be disabledChris Rorvick2012-12-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add 'advice.pushAlreadyExists' option to disable the advice shown when an update is rejected for a reference that is not allowed to update at all (verses those that are allowed to fast-forward.) Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | push: rename config variable for more general useChris Rorvick2012-12-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 'pushNonFastForward' advice config can be used to squelch several instances of push-related advice. Rename it to 'pushUpdateRejected' to cover other reject scenarios that are unrelated to fast-forwarding. Retain the old name for compatibility. Signed-off-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'mm/status-push-pull-advise'Junio C Hamano2012-12-04
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | * mm/status-push-pull-advise: document that statusHints affects git checkout
| * | | document that statusHints affects git checkoutMatthieu Moy2012-12-04
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Documentation: move diff.wordRegex from config.txt to diff-config.txtRamkumar Ramachandra2012-11-18
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 19299a8 (Documentation: Move diff.<driver>.* from config.txt to diff-config.txt, 2011-04-07) moved the diff configuration options to diff-config.txt, but forgot about diff.wordRegex, which was left behind in config.txt. Fix this. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'pp/maint-doc-pager-config'Jeff King2012-11-04
|\ \ \ | |/ / |/| | | | | | | | * pp/maint-doc-pager-config: Documentation: improve the example of overriding LESS via core.pager
| * | Documentation: improve the example of overriding LESS via core.pagerPatrick Palka2012-10-29
| |/ | | | | | | | | | | | | | | | | You can override an option set in the LESS variable by simply prefixing the command line option with `-+`. This is more robust than the previous example if the default LESS options are to ever change. Signed-off-by: Patrick Palka <patrick@parcs.ath.cx> Signed-off-by: Jeff King <peff@peff.net>
* | Merge branch 'maint'Junio C Hamano2012-09-17
|\ \ | |/ | | | | | | | | | | | | | | * maint: t/perf: add "trash directory" to .gitignore Add missing -z to git check-attr usage text for consistency with man page git-jump: ignore (custom) prefix in diff mode Documentation: indent-with-non-tab uses "equivalent tabs" not 8 completion: add --no-edit to git-commit
| * Documentation: indent-with-non-tab uses "equivalent tabs" not 8Wesley J. Landaker2012-09-17
| | | | | | | | | | | | | | | | | | Update the documentation of the core.whitespace option "indent-with-non-tab" to correctly reflect that it catches the use of spaces instead of the equivalent tabs, rather than a fixed number. Signed-off-by: Wesley J. Landaker <wjl@icecavern.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'js/grep-patterntype-config'Junio C Hamano2012-08-27
|\ \ | |/ |/| | | | | | | | | | | "grep" learned to use a non-standard pattern type by default if a configuration variable tells it to. * js/grep-patterntype-config: grep: add a grep.patternType configuration setting
| * grep: add a grep.patternType configuration settingJ Smith2012-08-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The grep.extendedRegexp configuration setting enables the -E flag on grep by default but there are no equivalents for the -G, -F and -P flags. Rather than adding an additional setting for grep.fooRegexp for current and future pattern matching options, add a grep.patternType setting that can accept appropriate values for modifying the default grep pattern matching behavior. The current values are "basic", "extended", "fixed", "perl" and "default" for setting -G, -E, -F, -P and the default behavior respectively. When grep.patternType is set to a value other than "default", the grep.extendedRegexp setting is ignored. The value of "default" restores the current default behavior, including the grep.extendedRegexp behavior. Signed-off-by: J Smith <dark.panda@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Merge branch 'pg/maint-1.7.9-am-where-is-patch' into maintJunio C Hamano2012-07-30
| |\ | | | | | | | | | | | | | | | | | | | | | When "git am" failed, old timers knew to check .git/rebase-apply/patch to see what went wrong, but we never told the users about it. * pg/maint-1.7.9-am-where-is-patch: am: indicate where a failed patch is to be found
* | \ Merge branch 'pg/maint-1.7.9-am-where-is-patch'Junio C Hamano2012-07-22
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | When "git am" failed, old timers knew to check .git/rebase-apply/patch to see what went wrong, but we never told the users about it. * pg/maint-1.7.9-am-where-is-patch: am: indicate where a failed patch is to be found
| * | am: indicate where a failed patch is to be foundPaul Gortmaker2012-07-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If "git am" fails to apply something, the end user may need to know where to find the patch that failed to apply, so that the user can do other things (e.g. trying "GNU patch" on it, running "diffstat" to see what it tried to change, etc.) The input to "am" may have contained more than one patch, or the message may have been MIME encoded, and knowing what the user fed to "am" does not help very much for this purpose. Also introduce advice.amworkdir configuration to allow people who learned where to look to squelch this message. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'tb/sanitize-decomposed-utf-8-pathname'Junio C Hamano2012-07-13
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teaches git to normalize pathnames read from readdir(3) and all arguments from the command line into precomposed UTF-8 (assuming that they come as decomposed UTF-8) to work around issues on Mac OS. I think there still are other places that need conversion (e.g. paths that are read from stdin for some commands), but this should be a good first step in the right direction. * tb/sanitize-decomposed-utf-8-pathname: git on Mac OS and precomposed unicode
| * | | git on Mac OS and precomposed unicodeTorsten Bögershausen2012-07-08
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mac OS X mangles file names containing unicode on file systems HFS+, VFAT or SAMBA. When a file using unicode code points outside ASCII is created on a HFS+ drive, the file name is converted into decomposed unicode and written to disk. No conversion is done if the file name is already decomposed unicode. Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same result as open("\x41\xcc\x88",...) with a decomposed "Ä". As a consequence, readdir() returns the file names in decomposed unicode, even if the user expects precomposed unicode. Unlike on HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in precomposed unicode, but readdir() still returns file names in decomposed unicode. When a git repository is stored on a network share using SAMBA, file names are send over the wire and written to disk on the remote system in precomposed unicode, but Mac OS X readdir() returns decomposed unicode to be compatible with its behaviour on HFS+ and VFAT. The unicode decomposition causes many problems: - The names "git add" and other commands get from the end user may often be precomposed form (the decomposed form is not easily input from the keyboard), but when the commands read from the filesystem to see what it is going to update the index with already is on the filesystem, readdir() will give decomposed form, which is different. - Similarly "git log", "git mv" and all other commands that need to compare pathnames found on the command line (often but not always precomposed form; a command line input resulting from globbing may be in decomposed) with pathnames found in the tree objects (should be precomposed form to be compatible with other systems and for consistency in general). - The same for names stored in the index, which should be precomposed, that may need to be compared with the names read from readdir(). NFS mounted from Linux is fully transparent and does not suffer from the above. As Mac OS X treats precomposed and decomposed file names as equal, we can - wrap readdir() on Mac OS X to return the precomposed form, and - normalize decomposed form given from the command line also to the precomposed form, to ensure that all pathnames used in Git are always in the precomposed form. This behaviour can be requested by setting "core.precomposedunicode" configuration variable to true. The code in compat/precomposed_utf8.c implements basically 4 new functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(), precomposed_utf8_closedir() and precompose_argv(). The first three are to wrap opendir(3), readdir(3), and closedir(3) functions. The argv[] conversion allows to use the TAB filename completion done by the shell on command line. It tolerates other tools which use readdir() to feed decomposed file names into git. When creating a new git repository with "git init" or "git clone", "core.precomposedunicode" will be set "false". The user needs to activate this feature manually. She typically sets core.precomposedunicode to "true" on HFS and VFAT, or file systems mounted via SAMBA. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'mm/config-xdg'Junio C Hamano2012-07-09
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach git to read various information from $XDG_CONFIG_HOME/git/ to allow the user to avoid cluttering $HOME. * mm/config-xdg: config: write to $XDG_CONFIG_HOME/git/config file when appropriate Let core.attributesfile default to $XDG_CONFIG_HOME/git/attributes Let core.excludesfile default to $XDG_CONFIG_HOME/git/ignore config: read (but not write) from $XDG_CONFIG_HOME/git/config file
| * | | Let core.attributesfile default to $XDG_CONFIG_HOME/git/attributesHuynh Khoi Nguyen Nguyen2012-06-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This gives the default value for the core.attributesfile variable following the exact same logic of the previous change for the core.excludesfile setting. Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | Let core.excludesfile default to $XDG_CONFIG_HOME/git/ignoreHuynh Khoi Nguyen Nguyen2012-06-25
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To use the feature of core.excludesfile, the user needs: 1. to create such a file, 2. and add configuration variable to point at it. Instead, we can make this a one-step process by choosing a default value which points to a filename in the user's $HOME, that is unlikely to already exist on the system, and only use the presence of the file as a cue that the user wants to use that feature. And we use "${XDG_CONFIG_HOME:-$HOME/.config/git}/ignore" as such a file, in the same directory as the newly added configuration file ("${XDG_CONFIG_HOME:-$HOME/.config/git}/config). The use of this directory is in line with XDG specification as a location to store such application specific files. Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Fix formatting in git-config(1)Andreas Schwab2012-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes two formatting bugs in the git-config documentation: - in the column.ui entry don't indent the last paragraph so that it isn't formatted as a literal paragraph - in the push.default entry separate the last paragraph from the nested list. Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | wt-status.*: better advices for git status addedLucien Kong2012-06-14
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides new informative help messages in the display of 'git status' (at the top) during conflicts, rebase, am, bisect or cherry-pick process. The new messages are not shown when using options such as -s or --porcelain. The messages about the current situation of the user are always displayed but the advices on what the user needs to do in order to resume a rebase/bisect/am/commit after resolving conflicts can be hidden by setting advice.statushints to 'false' in the config file. Thus, information about the updated advice.statushints key are added in Documentation/config.txt. Also, the test t7060-wt-status.sh is now working with the new help messages. Tests about suggestions of "git rm" are also added. Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>