summaryrefslogtreecommitdiff
path: root/Documentation/config.txt
AgeCommit message (Collapse)AuthorFilesLines
2016-08-03Merge branch 'jk/push-progress'Libravatar Junio C Hamano1-0/+9
"git push" and "git clone" learned to give better progress meters to the end user who is waiting on the terminal. * jk/push-progress: receive-pack: send keepalives during quiet periods receive-pack: turn on connectivity progress receive-pack: relay connectivity errors to sideband receive-pack: turn on index-pack resolving progress index-pack: add flag for showing delta-resolution progress clone: use a real progress meter for connectivity check check_connected: add progress flag check_connected: relay errors to alternate descriptor check_everything_connected: use a struct with named options check_everything_connected: convert to argv_array rev-list: add optional progress reporting check_everything_connected: always pass --quiet to rev-list
2016-08-03Merge branch 'sb/push-options'Libravatar Junio C Hamano1-2/+7
"git push" learned to accept and pass extra options to the receiving end so that hooks can read and react to them. * sb/push-options: add a test for push options push: accept push options receive-pack: implement advertising and receiving push options push options: {pre,post}-receive hook learns about push options
2016-07-25Merge branch 'jc/renormalize-merge-kill-safer-crlf'Libravatar Junio C Hamano1-7/+5
"git merge" with renormalization did not work well with merge-recursive, due to "safer crlf" conversion kicking in when it shouldn't. * jc/renormalize-merge-kill-safer-crlf: merge: avoid "safer crlf" during recording of merge results convert: unify the "auto" handling of CRLF
2016-07-20receive-pack: send keepalives during quiet periodsLibravatar Jeff King1-0/+9
After a client has sent us the complete pack, we may spend some time processing the data and running hooks. If the client asked us to be quiet, receive-pack won't send any progress data during the index-pack or connectivity-check steps. And hooks may or may not produce their own progress output. In these cases, the network connection is totally silent from both ends. Git itself doesn't care about this (it will wait forever), but other parts of the system (e.g., firewalls, load-balancers, etc) might hang up the connection. So we'd like to send some sort of keepalive to let the network and the client side know that we're still alive and processing. We can use the same trick we did in 05e9515 (upload-pack: send keepalive packets during pack computation, 2013-09-08). Namely, we will send an empty sideband data packet every `N` seconds that we do not relay any stderr data over the sideband channel. As with 05e9515, this means that we won't bother sending keepalives when there's actual progress data, but will kick in when it has been disabled (or if there is a lull in the progress data). The concept is simple, but the details are subtle enough that they need discussing here. Before the client sends us the pack, we don't want to do any keepalives. We'll have sent our ref advertisement, and we're waiting for them to send us the pack (and tell us that they support sidebands at all). While we're receiving the pack from the client (or waiting for it to start), there's no need for keepalives; it's up to them to keep the connection active by sending data. Moreover, it would be wrong for us to do so. When we are the server in the smart-http protocol, we must treat our connection as half-duplex. So any keepalives we send while receiving the pack would potentially be buffered by the webserver. Not only does this make them useless (since they would not be delivered in a timely manner), but it could actually cause a deadlock if we fill up the buffer with keepalives. (It wouldn't be wrong to send keepalives in this phase for a full-duplex connection like ssh; it's simply pointless, as it is the client's responsibility to speak). As soon as we've gotten all of the pack data, then the client is waiting for us to speak, and we should start keepalives immediately. From here until the end of the connection, we send one any time we are not otherwise sending data. But there's a catch. Receive-pack doesn't know the moment we've gotten all the data. It passes the descriptor to index-pack, who reads all of the data, and then starts resolving the deltas. We have to communicate that back. To make this work, we instruct the sideband muxer to enable keepalives in three phases: 1. In the beginning, not at all. 2. While reading from index-pack, wait for a signal indicating end-of-input, and then start them. 3. Afterwards, always. The signal from index-pack in phase 2 has to come over the stderr channel which the muxer is reading. We can't use an extra pipe because the portable run-command interface only gives us stderr and stdout. Stdout is already used to pass the .keep filename back to receive-pack. We could also send a signal there, but then we would find out about it in the main thread. And the keepalive needs to be done by the async muxer thread (since it's the one writing sideband data back to the client). And we can't reliably signal the async thread from the main thread, because the async code sometimes uses threads and sometimes uses forked processes. Therefore the signal must come over the stderr channel, where it may be interspersed with other random human-readable messages from index-pack. This patch makes the signal a single NUL byte. This is easy to parse, should not appear in any normal stderr output, and we don't have to worry about any timing issues (like seeing half the signal bytes in one read(), and half in a subsequent one). This is a bit ugly, but it's simple to code and should work reliably. Another option would be to stop using an async thread for muxing entirely, and just poll() both stderr and stdout of index-pack from the main thread. This would work for index-pack (because we aren't doing anything useful in the main thread while it runs anyway). But it would make the connectivity check and the hook muxers much more complicated, as they need to simultaneously feed the sub-programs while reading their stderr. The index-pack phase is the only one that needs this signaling, so it could simply behave differently than the other two. That would mean having two separate implementations of copy_to_sideband (and the keepalive code), though. And it still doesn't get rid of the signaling; it just means we can write a nicer message like "END_OF_INPUT" or something on stdout, since we don't have to worry about separating it from the stderr cruft. One final note: this signaling trick is only done with index-pack, not with unpack-objects. There's no point in doing it for the latter, because by definition it only kicks in for a small number of objects, where keepalives are not as useful (and this conveniently lets us avoid duplicating the implementation). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-19Merge branch 'nd/fetch-ref-summary'Libravatar Junio C Hamano1-0/+5
Improve the look of the way "git fetch" reports what happened to each ref that was fetched. * nd/fetch-ref-summary: fetch: reduce duplicate in ref update status lines with placeholder fetch: align all "remote -> local" output fetch: change flag code for displaying tag update and deleted ref fetch: refactor ref update status formatting code git-fetch.txt: document fetch output
2016-07-19Merge branch 'nd/connect-ssh-command-config'Libravatar Junio C Hamano1-0/+7
A new configuration variable core.sshCommand has been added to specify what value for GIT_SSH_COMMAND to use per repository. * nd/connect-ssh-command-config: connect: read $GIT_SSH_COMMAND from config file
2016-07-14receive-pack: implement advertising and receiving push optionsLibravatar Stefan Beller1-2/+7
The pre/post receive hook may be interested in more information from the user. This information can be transmitted when both client and server support the "push-options" capability, which when used is a phase directly after update commands ended by a flush pkt. Similar to the atomic option, the server capability can be disabled via the `receive.advertisePushOptions` config variable. While documenting this, fix a nit in the `receive.advertiseAtomic` wording. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13Merge branch 'mm/doc-tt'Libravatar Junio C Hamano1-20/+20
More mark-up updates to typeset strings that are expected to literally typed by the end user in fixed-width font. * mm/doc-tt: doc: typeset HEAD and variants as literal CodingGuidelines: formatting HEAD in documentation doc: typeset long options with argument as literal doc: typeset '--' as literal doc: typeset long command-line options as literal doc: typeset short command-line options as literal Documentation/git-mv.txt: fix whitespace indentation
2016-07-11Merge branch 'jk/ansi-color'Libravatar Junio C Hamano1-21/+28
The output coloring scheme learned two new attributes, italic and strike, in addition to existing bold, reverse, etc. * jk/ansi-color: color: support strike-through attribute color: support "italic" attribute color: allow "no-" for negating attributes color: refactor parse_attr add skip_prefix_mem helper doc: refactor description of color format color: fix max-size comment
2016-07-06connect: read $GIT_SSH_COMMAND from config fileLibravatar Nguyễn Thái Ngọc Duy1-0/+7
Similar to $GIT_ASKPASS or $GIT_PROXY_COMMAND, we also read from config file first then fall back to $GIT_SSH_COMMAND. This is useful for selecting different private keys targetting the same host (e.g. github) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06Merge branch 'jk/upload-pack-hook'Libravatar Junio C Hamano1-0/+15
"upload-pack" allows a custom "git pack-objects" replacement when responding to "fetch/clone" via the uploadpack.packObjectsHook. * jk/upload-pack-hook: upload-pack: provide a hook for running pack-objects t1308: do not get fooled by symbolic links to the source tree config: add a notion of "scope" config: return configset value for current_config_ functions config: set up config_source for command-line config git_config_parse_parameter: refactor cleanup code git_config_with_options: drop "found" counting
2016-07-06convert: unify the "auto" handling of CRLFLibravatar Torsten Bögershausen1-7/+5
Before this change, $ echo "* text=auto" >.gitattributes $ echo "* eol=crlf" >>.gitattributes would have the same effect as $ echo "* text" >.gitattributes $ git config core.eol crlf Since the 'eol' attribute had higher priority than 'text=auto', this may corrupt binary files and is not what most users expect to happen. Make the 'eol' attribute to obey 'text=auto' and now $ echo "* text=auto" >.gitattributes $ echo "* eol=crlf" >>.gitattributes behaves the same as $ echo "* text=auto" >.gitattributes $ git config core.eol crlf In other words, $ echo "* text=auto eol=crlf" >.gitattributes has the same effect as $ git config core.autocrlf true and $ echo "* text=auto eol=lf" >.gitattributes has the same effect as $ git config core.autocrlf input Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06fetch: reduce duplicate in ref update status lines with placeholderLibravatar Nguyễn Thái Ngọc Duy1-0/+5
In the "remote -> local" line, if either ref is a substring of the other, the common part in the other string is replaced with "*". For example abc -> origin/abc refs/pull/123/head -> pull/123 become abc -> origin/* refs/*/head -> pull/123 Activated with fetch.output=compact. For the record, this output is not perfect. A single giant ref can push all refs very far to the right and likely be wrapped around. We may have a few options: - exclude these long lines smarter - break the line after "->", exclude it from column width calculation - implement a new format, { -> origin/}foo, which makes the problem go away at the cost of a bit harder to read - reverse all the arrows so we have "* <- looong-ref", again still hard to read. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset long command-line options as literalLibravatar Matthieu Moy1-16/+16
Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset short command-line options as literalLibravatar Matthieu Moy1-4/+4
It was common in our documentation to surround short option names with forward quotes, which renders as italic in HTML. Instead, use backquotes which renders as monospace. This is one more step toward conformance to Documentation/CodingGuidelines. This was obtained with: perl -pi -e "s/'(-[a-z])'/\`\$1\`/g" *.txt Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-27Merge branch 'tr/doc-tt'Libravatar Junio C Hamano1-42/+42
The documentation set has been updated so that literal commands, configuration variables and environment variables are consistently typeset in fixed-width font and bold in manpages. * tr/doc-tt: doc: change configuration variables format doc: more consistency in environment variables format doc: change environment variables format doc: clearer rule about formatting literals
2016-06-23color: support strike-through attributeLibravatar Jeff King1-2/+3
This is the only remaining attribute that is commonly supported (at least by xterm) that we don't support. Let's add it for completeness. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-23color: support "italic" attributeLibravatar Jeff King1-4/+5
We already support bold, underline, and similar attributes. Let's add italic to the mix. According to the Wikipedia page on ANSI colors, this attribute is "not widely supported", but it does seem to work on my xterm. We don't have to bump the maximum color size because we were already over-allocating it (but we do adjust the comment appropriately). Requested-by: Simon Courtois <scourtois@cubyx.fr> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-23color: allow "no-" for negating attributesLibravatar Jeff King1-1/+1
Using "no-bold" rather than "nobold" is easier to read and more natural to type (to me, anyway, even though I was the person who introduced "nobold" in the first place). It's easy to allow both. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-23doc: refactor description of color formatLibravatar Jeff King1-21/+26
This is a general cleanup of the description of colors in git-config, mostly to address inaccuracies and confusion that had grown over time: - you can have many attributes, not just one - the discussion flip-flopped between colors and attributes; now we discuss everything about colors, then everything about attributes - many concepts were lumped into the first paragraph, making it hard to read, and especially to find the actual lists of colors and attributes. I stopped short of breaking those out into their own lists, as it seemed like an excessive use of vertical screen real estate. - we introduced negated attributes, but then the next paragraph basically explains how each item starts off with no attributes. So why would one need negated attributes? We now explain. - minor typo, language, and typography fixes Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20Merge branch 'ew/fast-import-unpack-limit'Libravatar Junio C Hamano1-0/+9
"git fast-import" learned the same performance trick to avoid creating too small a packfile as "git fetch" and "git push" have, using *.unpackLimit configuration. * ew/fast-import-unpack-limit: fast-import: invalidate pack_id references after loosening fast-import: implement unpack limit
2016-06-08doc: change configuration variables formatLibravatar Tom Russello1-13/+13
This change configuration variables that where in italic style to monospace font according to the guideline. It was obtained with grep '[[:alpha:]]*\.[[:alpha:]]*::$' config.txt | \ sed -e 's/::$//' -e 's/\./\\\\./' | \ xargs -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-08doc: more consistency in environment variables formatLibravatar Tom Russello1-6/+6
Wrap with backticks (monospaced font) unwrapped or single-quotes wrapped (italic type) environment variables which are followed by the word "environment". It was obtained with: perl -pi -e "s/\'?(\\\$?[0-9A-Z\_]+)\'?(?= environment ?)/\`\1\`/g" *.txt One of the main purposes is to stick to the CodingGuidelines as possible so that people writting new documentation by mimicking the existing are more likely to have it right (even if they didn't read the CodingGuidelines). Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-08doc: change environment variables formatLibravatar Tom Russello1-23/+23
This change GIT_* variables that where in italic style to monospaced font according to the guideline. It was obtained with perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt One of the main purposes is to stick to the CodingGuidelines as possible so that people writting new documentation by mimicking the existing are more likely to have it right (even if they didn't read the CodingGuidelines). Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06Merge branch 'tb/core-eol-fix' into maintLibravatar Junio C Hamano1-3/+3
A couple of bugs around core.autocrlf have been fixed. * tb/core-eol-fix: convert.c: ident + core.autocrlf didn't work t0027: test cases for combined attributes convert: allow core.autocrlf=input and core.eol=crlf t0027: make commit_chk_wrnNNO() reliable
2016-06-02upload-pack: provide a hook for running pack-objectsLibravatar Jeff King1-0/+15
When upload-pack serves a client request, it turns to pack-objects to do the heavy lifting of creating a packfile. There's no easy way to intercept the call to pack-objects, but there are a few good reasons to want to do so: 1. If you're debugging a client or server issue with fetching, you may want to store a copy of the generated packfile. 2. If you're gathering data from real-world fetches for performance analysis or debugging, storing a copy of the arguments and stdin lets you replay the pack generation at your leisure. 3. You may want to insert a caching layer around pack-objects; it is the most CPU- and memory-intensive part of serving a fetch, and its output is a pure function[1] of its input, making it an ideal place to consolidate identical requests. This patch adds a simple "hook" interface to intercept calls to pack-objects. The new test demonstrates how it can be used for debugging (using it for caching is a straightforward extension; the tricky part is writing the actual caching layer). This hook is unlike the normal hook scripts found in the "hooks/" directory of a repository. Because we promise that upload-pack is safe to run in an untrusted repository, we cannot execute arbitrary code or commands found in the repository (neither in hooks/, nor in the config). So instead, this hook is triggered from a config variable that is explicitly ignored in the per-repo config. The config variable holds the actual shell command to run as the hook. Another approach would be to simply treat it as a boolean: "should I respect the upload-pack hooks in this repo?", and then run the script from "hooks/" as we usually do. However, that isn't as flexible; there's no way to run a hook approved by the site administrator (e.g., in "/etc/gitconfig") on a repository whose contents are not trusted. The approach taken by this patch is more fine-grained, if a little less conventional for git hooks (it does behave similar to other configured commands like diff.external, etc). [1] Pack-objects isn't _actually_ a pure function. Its output depends on the exact packing of the object database, and if multi-threading is used for delta compression, can even differ racily. But for the purposes of caching, that's OK; of the many possible outputs for a given input, it is sufficient only that we output one of them. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31Merge branch 'bn/http-cookiefile-config' into maintLibravatar Junio C Hamano1-2/+3
"http.cookieFile" configuration variable clearly wants a pathname, but we forgot to treat it as such by e.g. applying tilde expansion. * bn/http-cookiefile-config: http: expand http.cookieFile as a path Documentation: config: improve word ordering for http.cookieFile
2016-05-29Merge branch 'rj/log-decorate-auto'Libravatar Junio C Hamano1-1/+4
We forgot to add "git log --decorate=auto" to documentation when we added the feature back in v2.1.0 timeframe. * rj/log-decorate-auto: log: document the --decorate=auto option
2016-05-27log: document the --decorate=auto optionLibravatar Ramsay Jones1-1/+4
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-26Merge branch 'jc/linkgit-fix' into maintLibravatar Junio C Hamano1-2/+2
Many 'linkgit:<git documentation page>' references were broken, which are all fixed with this. * jc/linkgit-fix: Documentation: fix linkgit references
2016-05-26Merge branch 'js/windows-dotgit' into maintLibravatar Junio C Hamano1-0/+6
On Windows, .git and optionally any files whose name starts with a dot are now marked as hidden, with a core.hideDotFiles knob to customize this behaviour. * js/windows-dotgit: mingw: remove unnecessary definition mingw: introduce the 'core.hideDotFiles' setting
2016-05-26Merge branch 'bn/config-doc-tt-varnames' into maintLibravatar Junio C Hamano1-21/+29
Doc formatting fixes. * bn/config-doc-tt-varnames: config: consistently format $variables in monospaced font config: describe 'pathname' value type
2016-05-23Merge branch 'pb/commit-verbose-config'Libravatar Junio C Hamano1-0/+4
"git commit" learned to pay attention to "commit.verbose" configuration variable and act as if "--verbose" option was given from the command line. * pb/commit-verbose-config: commit: add a commit.verbose config variable t7507-commit-verbose: improve test coverage by testing number of diffs parse-options.c: make OPTION_COUNTUP respect "unspecified" values t/t7507: improve test coverage t0040-parse-options: improve test coverage test-parse-options: print quiet as integer t0040-test-parse-options.sh: fix style issues
2016-05-23Merge branch 'xy/format-patch-base'Libravatar Junio C Hamano1-0/+4
"git format-patch" learned a new "--base" option to record what (public, well-known) commit the original series was built on in its output. * xy/format-patch-base: format-patch: introduce format.useAutoBase configuration format-patch: introduce --base=auto option format-patch: add '--base' option to record base tree info patch-ids: make commit_patch_id() a public helper function
2016-05-23Merge branch 'tb/core-eol-fix'Libravatar Junio C Hamano1-3/+3
A couple of bugs around core.autocrlf have been fixed. * tb/core-eol-fix: convert.c: ident + core.autocrlf didn't work t0027: test cases for combined attributes convert: allow core.autocrlf=input and core.eol=crlf t0027: make commit_chk_wrnNNO() reliable
2016-05-17Merge branch 'js/windows-dotgit'Libravatar Junio C Hamano1-0/+6
On Windows, .git and optionally any files whose name starts with a dot are now marked as hidden, with a core.hideDotFiles knob to customize this behaviour. * js/windows-dotgit: mingw: remove unnecessary definition mingw: introduce the 'core.hideDotFiles' setting
2016-05-17Merge branch 'jc/linkgit-fix'Libravatar Junio C Hamano1-2/+2
Many 'linkgit:<git documentation page>' references were broken, which are all fixed with this. * jc/linkgit-fix: Documentation: fix linkgit references
2016-05-17Merge branch 'bn/config-doc-tt-varnames'Libravatar Junio C Hamano1-11/+11
Doc formatting fixes. * bn/config-doc-tt-varnames: config: consistently format $variables in monospaced font
2016-05-17Merge branch 'jc/config-pathname-type'Libravatar Junio C Hamano1-11/+19
Consolidate description of tilde-expansion that is done to configuration variables that take pathname to a single place. * jc/config-pathname-type: config: describe 'pathname' value type
2016-05-17Merge branch 'bn/http-cookiefile-config'Libravatar Junio C Hamano1-2/+3
"http.cookieFile" configuration variable clearly wants a pathname, but we forgot to treat it as such by e.g. applying tilde expansion. * bn/http-cookiefile-config: http: expand http.cookieFile as a path Documentation: config: improve word ordering for http.cookieFile
2016-05-17Merge branch 'ab/hooks'Libravatar Junio C Hamano1-0/+17
A new configuration variable core.hooksPath allows customizing where the hook directory is. * ab/hooks: hooks: allow customizing where the hook directory is githooks.txt: minor improvements to the grammar & phrasing githooks.txt: amend dangerous advice about 'update' hook ACL githooks.txt: improve the intro section
2016-05-11fast-import: implement unpack limitLibravatar Eric Wong1-0/+9
With many incremental imports, small packs become highly inefficient due to the need to readdir scan and load many indices to locate even a single object. Frequent repacking and consolidation may be prohibitively expensive in terms of disk I/O, especially in large repositories where the initial packs were aggressively optimized and marked with .keep files. In those cases, users may be better served with loose objects and relying on "git gc --auto". This changes the default behavior of fast-import for small imports found in test cases, so adjustments to t9300 were necessary. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-11mingw: introduce the 'core.hideDotFiles' settingLibravatar Johannes Schindelin1-0/+6
On Unix (and Linux), files and directories whose names start with a dot are usually not shown by default. This convention is used by Git: the .git/ directory should be left alone by regular users, and only accessed through Git itself. On Windows, no such convention exists. Instead, there is an explicit flag to mark files or directories as hidden. In the early days, Git for Windows did not mark the .git/ directory (or for that matter, any file or directory whose name starts with a dot) hidden. This lead to quite a bit of confusion, and even loss of data. Consequently, Git for Windows introduced the core.hideDotFiles setting, with three possible values: true, false, and dotGitOnly, defaulting to marking only the .git/ directory as hidden. The rationale: users do not need to access .git/ directly, and indeed (as was demonstrated) should not really see that directory, either. However, not all dot files should be hidden by default, as e.g. Eclipse does not show them (and the user would therefore be unable to see, say, a .gitattributes file). In over five years since the last attempt to bring this patch into core Git, a slightly buggy version of this patch has served Git for Windows' users well: no single report indicated problems with the hidden .git/ directory, and the stream of problems caused by the previously non-hidden .git/ directory simply stopped. The bugs have been fixed during the process of getting this patch upstream. Note that there is a funny quirk we have to pay attention to when creating hidden files: we use Win32's _wopen() function which transmogrifies its arguments and hands off to Win32's CreateFile() function. That latter function errors out with ERROR_ACCESS_DENIED (the equivalent of EACCES) when the equivalent of the O_CREAT flag was passed and the file attributes (including the hidden flag) do not match an existing file's. And _wopen() accepts no parameter that would be transmogrified into said hidden flag. Therefore, we simply try again without O_CREAT. A slightly different method is required for our fopen()/freopen() function as we cannot even *remove* the implicit O_CREAT flag. Therefore, we briefly mark existing files as unhidden when opening them via fopen()/freopen(). The ERROR_ACCESS_DENIED error can also be triggered by opening a file that is marked as a system file (which is unlikely to be tracked in Git), and by trying to create a file that has *just* been deleted and is awaiting the last open handles to be released (which would be handled better by the "Try again?" logic, a story for a different patch series, though). In both cases, it does not matter much if we try again without the O_CREAT flag, read: it does not hurt, either. For details how ERROR_ACCESS_DENIED can be triggered, see https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858 Original-patch-by: Erik Faye-Lund <kusmabite@gmail.com> Initial-Test-By: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-10Merge branch 'ew/doc-split-pack-disables-bitmap'Libravatar Junio C Hamano1-4/+8
Doc update. * ew/doc-split-pack-disables-bitmap: pack-objects: warn on split packs disabling bitmaps
2016-05-10commit: add a commit.verbose config variableLibravatar Pranit Bauva1-0/+4
Add commit.verbose configuration variable as a convenience for those who always prefer --verbose. Add tests to check the behavior introduced by this commit and also to verify that behavior of status doesn't break because of this commit. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-09Documentation: fix linkgit referencesLibravatar Junio C Hamano1-2/+2
There are a handful of incorrect "linkgit:<page>[<section>]" instances in our documentation set. * Some have an extra colon after "linkgit:"; fix them by removing the extra colon; * Some refer to a page outside the Git suite, namely curl(1); fix them by using the `curl(1)` that already appears on the same page for the same purpose of referring the readers to its manual page. * Some spell the name of the page incorrectly, e.g. "rev-list" when they mean "git-rev-list"; fix them. * Some list the manual section incorrectly; fix them to make sure they match what is at the top of the target of the link. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-06Merge branch 'js/http-custom-headers'Libravatar Junio C Hamano1-0/+6
HTTP transport clients learned to throw extra HTTP headers at the server, specified via http.extraHeader configuration variable. * js/http-custom-headers: http: support sending custom HTTP headers
2016-05-05config: consistently format $variables in monospaced fontLibravatar Brian Norris1-11/+11
We don't consistently use `backticks` for formatting shell variables. This patch improves the consistency on shell variables (and a few nearby mentions of "gpg" commands), though it still doesn't straighten out the use of "quotes." Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-04hooks: allow customizing where the hook directory isLibravatar Ævar Arnfjörð Bjarmason1-0/+17
Change the hardcoded lookup for .git/hooks/* to optionally lookup in $(git config core.hooksPath)/* instead. This is essentially a more intrusive version of the git-init ability to specify hooks on init time via init templates. The difference between that facility and this feature is that this can be set up after the fact via e.g. ~/.gitconfig or /etc/gitconfig to apply for all your personal repositories, or all repositories on the system. I plan on using this on a centralized Git server where users can create arbitrary repositories under /gitroot, but I'd like to manage all the hooks that should be run centrally via a unified dispatch mechanism. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-04http: expand http.cookieFile as a pathLibravatar Brian Norris1-1/+2
This should handle .gitconfig files that specify things like: [http] cookieFile = "~/.gitcookies" Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>