summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2014-06-06Merge branch 'jc/coding-guidelines'Libravatar Junio C Hamano1-5/+145
* jc/coding-guidelines: CodingGuidelines: avoid "test <cond> -a/-o <cond>" CodingGuidelines: on splitting a long line CodingGuidelines: on comparison CodingGuidelines: do not call the conditional statement "if()" CodingGuidelines: give an example for shell function preamble CodingGuidelines: give an example for control statements CodingGuidelines: give an example for redirection CodingGuidelines: give an example for case/esac statement CodingGuidelines: once it is in, it is not worth the code churn
2014-06-06Merge branch 'nd/status-auto-comment-char'Libravatar Junio C Hamano1-0/+3
* nd/status-auto-comment-char: commit: allow core.commentChar=auto for character auto selection config: be strict on core.commentChar
2014-06-06Merge branch 'wk/doc-clarify-upstream'Libravatar Junio C Hamano1-1/+3
* wk/doc-clarify-upstream: Documentation: mention config sources for @{upstream}
2014-06-06Merge branch 'dk/raise-core-deltabasecachelimit'Libravatar Junio C Hamano1-1/+1
The `core.deltabasecachelimit` used to default to 16 MiB , but this proved to be too small, and has been bumped to 96 MiB. * dk/raise-core-deltabasecachelimit: Bump core.deltaBaseCacheLimit to 96m
2014-06-06Merge branch 'mm/pager-less-sans-S'Libravatar Junio C Hamano1-5/+10
Since the very beginning of Git, we gave the LESS environment a default value "FRSX" when we spawn "less" as the pager. "S" (chop long lines instead of wrapping) has been removed from this default set of options, because it is more or less a personal taste thing, as opposed to others that have good justifications (i.e. "R" is very much justified because many kinds of output we produce are colored and "FX" is justified because output we produce is often shorter than a page). Existing users who prefer not to see line-wrapped output may want to set $ git config core.pager "less -S" to restore the traditional behaviour. It is expected that people find output from the most subcommands easier to read with the new default, except for "blame" which tends to produce really long lines. To override the new default only for "git blame", you can do this: $ git config pager.blame "less -S" * mm/pager-less-sans-S: pager: remove 'S' from $LESS by default
2014-06-03First batch for 2.1Libravatar Junio C Hamano1-0/+86
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-03Merge branch 'bg/strbuf-trim'Libravatar Junio C Hamano1-0/+9
* bg/strbuf-trim: api-strbuf.txt: add docs for _trim and _ltrim strbuf: use _rtrim and _ltrim in strbuf_trim
2014-06-03Merge branch 'dt/api-doc-setup-gently'Libravatar Junio C Hamano1-5/+8
* dt/api-doc-setup-gently: docs: document RUN_SETUP_GENTLY and clarify RUN_SETUP
2014-06-03Merge branch 'fc/mergetool-prompt'Libravatar Junio C Hamano1-3/+5
mergetool.prompt used to default to 'true', always causing a confirmation "do you really want to run the tool on this path" to be shown. Among the two purposes the prompt serves, ignore the use case to confirm that the user wants to view particular path with the named tool, and make the prompt only to confirm the choice of the tool made by autodetection and defaulting. For those who configured the tool explicitly, the prompt shown for the latter purpose is simply annoying. Strictly speaking, this is a backward incompatible change and the users need to explicitly set the variable to 'true' if they want to resurrect the now-ignored use case. * fc/mergetool-prompt: mergetool: document the default for --[no-]prompt mergetool: run prompt only if guessed tool
2014-06-03Merge branch 'fc/merge-default-to-upstream'Libravatar Junio C Hamano1-3/+2
"git merge" without argument, even when there is an upstream defined for the current branch, refused to run until merge.defaultToUpstream is set to true. Flip the default of that configuration variable to true. * fc/merge-default-to-upstream: merge: enable defaulttoupstream by default
2014-06-03Merge branch 'mh/ref-transaction'Libravatar Junio C Hamano1-6/+12
Update "update-ref --stdin [-z]" and then introduce a transactional support for (multi-)reference updates. * mh/ref-transaction: (27 commits) ref_transaction_commit(): work with transaction->updates in place struct ref_update: add a type field struct ref_update: add a lock field ref_transaction_commit(): simplify code using temporary variables struct ref_update: store refname as a FLEX_ARRAY struct ref_update: rename field "ref_name" to "refname" refs: remove API function update_refs() update-ref --stdin: reimplement using reference transactions refs: add a concept of a reference transaction update-ref --stdin: harmonize error messages update-ref --stdin: improve the error message for unexpected EOF t1400: test one mistake at a time update-ref --stdin -z: deprecate interpreting the empty string as zeros update-ref.c: extract a new function, parse_next_sha1() t1400: test that stdin -z update treats empty <newvalue> as zeros update-ref --stdin: simplify error messages for missing oldvalues update-ref --stdin: make error messages more consistent update-ref --stdin: improve error messages for invalid values update-ref.c: extract a new function, parse_refname() parse_cmd_verify(): copy old_sha1 instead of evaluating <oldvalue> twice ...
2014-06-03Merge branch 'as/grep-fullname-config'Libravatar Junio C Hamano1-0/+3
Add a configuration variable to force --full-name to be default for "git grep". This may cause regressions on scripted users that do not expect this new behaviour. * as/grep-fullname-config: grep: add grep.fullName config variable
2014-05-30Sync with 1.9.4Libravatar Junio C Hamano2-1/+18
2014-05-30Git 1.9.4Libravatar Junio C Hamano2-1/+18
This is expected to be the final maintenance release for 1.9 series, merging the remaining fixes that are relevant and are already in 2.0. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-28Git 2.0Libravatar Junio C Hamano1-0/+5
2014-05-21Update draft release notes to 2.0Libravatar Junio C Hamano1-9/+5
Hopefully for the last time ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-20RelNotes/2.0.0.txt: Fix several grammar issues, notably a lack of hyphens, ↵Libravatar Jason St. John1-36/+37
double quotes, or articles Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-20Revert "Merge branch 'jc/graduate-remote-hg-bzr' (early part)"Libravatar Junio C Hamano1-0/+7
Instead of showing a warning and working as before, fail and show the message and force immediate upgrade from their upstream repositories when these tools are run, per request from their primary author. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-20CodingGuidelines: avoid "test <cond> -a/-o <cond>"Libravatar Junio C Hamano1-0/+13
The construct is error-prone; "test" being built-in in most modern shells, the reason to avoid "test <cond> && test <cond>" spawning one extra process by using a single "test <cond> -a <cond>" no longer exists. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19Merge branch 'jc/graduate-remote-hg-bzr' (early part)Libravatar Junio C Hamano1-4/+0
* 'jc/graduate-remote-hg-bzr' (early part): remote-helpers: point at their upstream repositories contrib: remote-helpers: add move warnings (v2.0) Revert "Merge branch 'fc/transport-helper-sync-error-fix'"
2014-05-19Revert "Merge branch 'fc/transport-helper-sync-error-fix'"Libravatar Junio C Hamano1-4/+0
This reverts commit d508e4a8e2391ae2596403b6478d01cf3d5f928f, reversing changes made to e42552135a2a396f37053a89f44952ea907870b2. The author of the original topic says he broke the upcoming 2.0 release with something that relates to "synchronization crash regression" while refusing to give further specifics, so this would unfortunately be the safest option for the upcoming release. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19commit: allow core.commentChar=auto for character auto selectionLibravatar Nguyễn Thái Ngọc Duy1-0/+3
When core.commentChar is "auto", the comment char starts with '#' as in default but if it's already in the prepared message, find another char in a small subset. This should stop surprises because git strips some lines unexpectedly. Note that git is not smart enough to recognize '#' as the comment char in custom templates and convert it if the final comment char is different. It thinks '#' lines in custom templates as part of the commit message. So don't use this with custom templates. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19Merge branch 'kb/fast-hashmap'Libravatar Junio C Hamano1-1/+0
* kb/fast-hashmap: Documentation/technical/api-hashmap: remove source highlighting
2014-05-19Documentation/technical/api-hashmap: remove source highlightingLibravatar Anders Kaseorg1-1/+0
The highlighting was pretty, but unfortunately, the failure mode when source-highlight is not installed was that the entire code block disappears. See https://bugs.debian.org/745591, https://bugs.launchpad.net/bugs/1316810. Signed-off-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-13Documentation: mention config sources for @{upstream}Libravatar W. Trevor King1-1/+3
The earlier documentation made vague references to "is set to build on". Flesh that out with references to the config settings, so folks can use git-config(1) to get more detail on what @{upstream} means. For example, @{upstream} does not care about remote.pushdefault or branch.<name>.pushremote. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-09Sync with 1.9.3Libravatar Junio C Hamano1-1/+2
2014-05-09Git 1.9.3Libravatar Junio C Hamano1-1/+2
The third maintenance release for Git 1.9; contains all the fixes that are scheduled to appear in Git 2.0 since 1.9.2. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-08Sync with maintLibravatar Junio C Hamano2-1/+22
* maint: shell doc: remove stray "+" in example Start preparing for 1.9.3
2014-05-08shell doc: remove stray "+" in exampleLibravatar Jonathan Nieder1-1/+1
The git-shell(1) manpage says EXAMPLE To disable interactive logins, displaying a greeting instead: + $ chsh -s /usr/bin/git-shell $ mkdir $HOME/git-shell-commands [...] The stray "+" has been there ever since the example was added in v1.8.3-rc0~210^2 (shell: new no-interactive-login command to print a custom message, 2013-03-09). The "+" sign between paragraphs is needed in asciidoc to attach extra paragraphs to a list item but here it is not needed and ends up rendered as a literal "+". Remove it. A quick search with "grep -e '<p>+' /usr/share/doc/git/html/*.html" doesn't find any other instances of this problem. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-08Start preparing for 1.9.3Libravatar Junio C Hamano1-0/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-07Update draft release notes for 2.0Libravatar Junio C Hamano1-2/+6
Describe one last minute one-liner fix for regression introduced in 1.9, and fix a grave mischaracterization on a recent remote-hg/bzr change, pointed out by Felipe. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-07pager: remove 'S' from $LESS by defaultLibravatar Matthieu Moy1-5/+10
By default, Git used to set $LESS to -FRSX if $LESS was not set by the user. The FRX flags actually make sense for Git (F and X because sometimes the output Git pipes to less is short, and R because Git pipes colored output). The S flag (chop long lines), on the other hand, is not related to Git and is a matter of user preference. Git should not decide for the user to change LESS's default. More specifically, the S flag harms users who review untrusted code within a pager, since a patch looking like: -old code; +new good code; [... lots of tabs ...] malicious code; would appear identical to: -old code; +new good code; Users who prefer the old behavior can still set the $LESS environment variable to -FRSX explicitly, or set core.pager to 'less -S'. The documentation in config.txt is made a bit longer to keep both an example setting the 'S' flag (needed to recover the old behavior) and an example showing how to unset a flag set by Git. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-06RelNotes/2.0.0: Grammar and typo fixesLibravatar Øyvind A. Holm1-5/+5
Signed-off-by: Øyvind A. Holm <sunny@sunbase.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-06api-strbuf.txt: add docs for _trim and _ltrimLibravatar Brian Gesiak1-0/+9
API documentation for strbuf does not document strbuf_trim() or strbuf_ltrim(). Add documentation for these two functions. Signed-off-by: Brian Gesiak <modocache@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-06Bump core.deltaBaseCacheLimit to 96mLibravatar David Kastrup1-1/+1
The default of 16m causes serious thrashing for large delta chains combined with large files. Here are some benchmarks (pu variant of git blame): time git blame -C src/xdisp.c >/dev/null for a repository of Emacs repacked with git gc --aggressive (v1.9, resulting in a window size of 250) located on an SSD drive. The file in question has about 30000 lines, 1Mb of size, and a history with about 2500 commits. 16m (previous default): real 3m33.936s user 2m15.396s sys 1m17.352s 32m: real 3m1.319s user 2m8.660s sys 0m51.904s 64m: real 2m20.636s user 1m55.780s sys 0m23.964s 96m: real 2m5.668s user 1m50.784s sys 0m14.288s 128m: real 2m4.337s user 1m50.764s sys 0m12.832s 192m: real 2m3.567s user 1m49.508s sys 0m13.312s Signed-off-by: David Kastrup <dak@gnu.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02CodingGuidelines: on splitting a long lineLibravatar Junio C Hamano1-0/+55
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02CodingGuidelines: on comparisonLibravatar Junio C Hamano1-0/+27
There are arguments for writing a conditional as "a < b" rather than "b > a", or vice versa. Let's give guidance on which we prefer. See http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126 for the original discussion. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02CodingGuidelines: do not call the conditional statement "if()"Libravatar Junio C Hamano1-1/+1
The point immediately before it is about having SP after the control keyword. Spell it out as 'an "if" statement' instead. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02CodingGuidelines: give an example for shell function preambleLibravatar Junio C Hamano1-3/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02CodingGuidelines: give an example for control statementsLibravatar Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02CodingGuidelines: give an example for redirectionLibravatar Junio C Hamano1-0/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02CodingGuidelines: give an example for case/esac statementLibravatar Junio C Hamano1-1/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02CodingGuidelines: once it is in, it is not worth the code churnLibravatar Junio C Hamano1-0/+8
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02Git 2.0-rc2Libravatar Junio C Hamano1-1/+6
2014-05-02Merge branch 'km/git-svn-workaround-older-getopt-long'Libravatar Junio C Hamano1-0/+3
* km/git-svn-workaround-older-getopt-long: t9117: use --prefix "" instead of --prefix=""
2014-05-02Merge branch 'mk/doc-git-gui-display-untracked'Libravatar Junio C Hamano1-0/+4
* mk/doc-git-gui-display-untracked: Documentation: git-gui: describe gui.displayuntracked
2014-04-30docs: document RUN_SETUP_GENTLY and clarify RUN_SETUPLibravatar David Turner1-5/+8
We only said what happens when we find the Git directory under RUN_SETUP, without saying what happens otherwise. Signed-off-by: David Turner <dturner@twitter.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-25Git 2.0-rc1Libravatar Junio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-24mergetool: document the default for --[no-]promptLibravatar Junio C Hamano1-3/+5
The original motivation of using the prompt was to confirm to run a tool on this particular (as opposed to another) path, but the user can also take the prompt as to confirm to run this (as opposed to some other) tool. The latter of which of course is irritating for those who told which exact tool to use, which is the reason why we are flipping the default. During the review discussion of the patch, many people (including the maintainer) missed that a user can find the prompt useful way to skip running the tool on particular paths. Clarify it by adding a brief half-sentence to the description. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-23t9117: use --prefix "" instead of --prefix=""Libravatar Kyle J. McKay1-0/+3
Versions of Perl's Getopt::Long module before 2.37 do not contain this fix that first appeared in Getopt::Long version 2.37: * Bugfix: With gnu_compat, --foo= will no longer trigger "Option requires an argument" but return the empty string. Instead of using --prefix="" use --prefix "" when testing an explictly empty prefix string in order to work with older versions of Perl's Getopt::Long module. Also add a paragraph on this workaround to the documentation of git-svn itself. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-19 11:06:26 +0000