summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)Author
2014-06-16Merge branch 'jk/argv-array-for-child-process'Junio C Hamano
* jk/argv-array-for-child-process: argv-array: drop "detach" code get_importer: use run-command's internal argv_array get_exporter: use argv_array get_helper: use run-command's internal argv_array git_connect: use argv_array run_column_filter: use argv_array run-command: store an optional argv_array
2014-06-16Merge branch 'cc/replace-edit'Junio C Hamano
"git replace" learns a new "--edit" option. * cc/replace-edit: Documentation: replace: describe new --edit option replace: add --edit to usage string replace: add tests for --edit replace: die early if replace ref already exists replace: refactor checking ref validity replace: make sure --edit results in a different object replace: add --edit option replace: factor object resolution out of replace_object replace: use OPT_CMDMODE to handle modes replace: refactor command-mode determination
2014-06-16Merge branch 'mt/patch-id-stable' (early part)Junio C Hamano
* 'mt/patch-id-stable' (early part): patch-id-test: test stable and unstable behaviour patch-id: make it stable against hunk reordering test doc: test_write_lines does not split its arguments test: add test_write_lines helper
2014-06-10patch-id: make it stable against hunk reorderingMichael S. Tsirkin
Patch id changes if users reorder file diffs that make up a patch. As the result is functionally equivalent, a different patch id is surprising to many users. In particular, reordering files using diff -O is helpful to make patches more readable (e.g. API header diff before implementation diff). Add an option to change patch-id behaviour making it stable against these kinds of patch change: calculate SHA1 hash for each hunk separately and sum all hashes (using a symmetrical sum) to get patch id We use a 20byte sum and not xor - since xor would give 0 output for patches that have two identical diffs, which isn't all that unlikely (e.g. append the same line in two places). The new behaviour is enabled - when patchid.stable is true - when --stable flag is present Using a new flag --unstable or setting patchid.stable to false force the historical behaviour. In the documentation, clarify that patch ID can now be a sum of hashes, not a hash. Document how command line and config options affect the behaviour. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-09Update draft release notes to 2.1Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-06Second batch for 2.1Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-06Merge branch 'ss/howto-manage-trunk'Junio C Hamano
* ss/howto-manage-trunk: How to keep a project's canonical history correct.
2014-06-06Merge branch 'jj/command-line-adjective'Junio C Hamano
* jj/command-line-adjective: Documentation: use "command-line" when used as a compound adjective, and fix other minor grammatical issues
2014-06-06Merge branch 'jc/coding-guidelines'Junio C Hamano
* 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'Junio C Hamano
* 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'Junio C Hamano
* wk/doc-clarify-upstream: Documentation: mention config sources for @{upstream}
2014-06-06Merge branch 'dk/raise-core-deltabasecachelimit'Junio C Hamano
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'Junio C Hamano
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.1Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-03Merge branch 'bg/strbuf-trim'Junio C Hamano
* 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'Junio C Hamano
* dt/api-doc-setup-gently: docs: document RUN_SETUP_GENTLY and clarify RUN_SETUP
2014-06-03Merge branch 'fc/mergetool-prompt'Junio C Hamano
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'Junio C Hamano
"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'Junio C Hamano
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'Junio C Hamano
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.4Junio C Hamano
2014-05-30Git 1.9.4v1.9.4Junio C Hamano
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-28How to keep a project's canonical history correct.Stephen P. Smith
During the mail thread about "Pull is mostly evil" a user asked how the first parent could become reversed. This howto explains how the first parent can get reversed when viewed by the project and then explains a method to keep the history correct. Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-28Git 2.0v2.0.0Junio C Hamano
2014-05-21Documentation: use "command-line" when used as a compound adjective, and fix ↵Jason St. John
other minor grammatical issues Signed-off-by: Jason St. John <jstjohn@purdue.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-21Update draft release notes to 2.0Junio C Hamano
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, ↵Jason St. John
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)"Junio C Hamano
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>"Junio C Hamano
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-20Merge branch 'jc/graduate-remote-hg-bzr' (early part)Junio C Hamano
* '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-20Revert "Merge branch 'fc/transport-helper-sync-error-fix'"Junio C Hamano
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-19Documentation: replace: describe new --edit optionChristian Couder
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19commit: allow core.commentChar=auto for character auto selectionNguyễn Thái Ngọc Duy
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'Junio C Hamano
* kb/fast-hashmap: Documentation/technical/api-hashmap: remove source highlighting
2014-05-19Documentation/technical/api-hashmap: remove source highlightingAnders Kaseorg
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-15argv-array: drop "detach" codeJeff King
The argv_array_detach function (and associated free() function) was really only useful for transferring ownership of the memory to a "struct child_process". Now that we have an internal argv_array in that struct, there are no callers left. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-15run-command: store an optional argv_arrayJeff King
All child_process structs need to point to an argv. For flexibility, we do not mandate the use of a dynamic argv_array. However, because the child_process does not own the memory, this can make memory management with a separate argv_array difficult. For example, if a function calls start_command but not finish_command, the argv memory must persist. The code needs to arrange to clean up the argv_array separately after finish_command runs. As a result, some of our code in this situation just leaks the memory. To help such cases, this patch adds a built-in argv_array to the child_process, which gets cleaned up automatically (both in finish_command and when start_command fails). Callers may use it if they choose, but can continue to use the raw argv if they wish. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-13Documentation: mention config sources for @{upstream}W. Trevor King
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.3Junio C Hamano
2014-05-09Git 1.9.3v1.9.3Junio C Hamano
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 maintJunio C Hamano
* maint: shell doc: remove stray "+" in example Start preparing for 1.9.3
2014-05-08shell doc: remove stray "+" in exampleJonathan Nieder
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.3Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-07Update draft release notes for 2.0Junio C Hamano
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 defaultMatthieu Moy
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-07RelNotes/2.0.0: Grammar and typo fixesØyvind A. Holm
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 _ltrimBrian Gesiak
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 96mDavid Kastrup
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 lineJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02CodingGuidelines: on comparisonJunio C Hamano
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>