summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-10-03git-p4: add optional type specifier to gitConfig readerLibravatar Lars Schneider1-6/+6
The functions "gitConfig" and "gitConfigBool" are almost identical. Make "gitConfig" more generic by adding an optional type specifier. Use the type specifier "--bool" with "gitConfig" to implement "gitConfigBool. This prepares the implementation of other type specifiers such as "--int". Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Acked-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-08Git 2.6-rc1Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-08Merge branch 'jc/builtin-am-signoff-regression-fix'Libravatar Junio C Hamano2-2/+77
Recent "git am" had regression when adding a Signed-off-by line with its "-s" option by an unintended tightening of how an existing trailer block is detected. * jc/builtin-am-signoff-regression-fix: am: match --signoff to the original scripted version
2015-09-06am: match --signoff to the original scripted versionLibravatar Junio C Hamano2-2/+77
Linus noticed that the recently reimplemented "git am -s" defines the trailer block too rigidly, resulting in an unnecessary blank line between the existing sign-offs and his new sign-off. An e-mail submission sent to Linus in real life ends with mixture of sign-offs and commentaries, e.g. title here message here Signed-off-by: Original Author <original@auth.or> [rv: tweaked frotz and nitfol] Signed-off-by: Re Viewer <rv@ew.er> Signed-off-by: Other Reviewer <other@rev.ewer> --- patch here Because the reimplementation reused append_signoff() helper that is used by other codepaths, which is unaware that people intermix such comments with their sign-offs in the trailer block, such a message was judged to end with a non-trailer, resulting in an extra blank line before adding a new sign-off. The original scripted version of "git am" used a lot looser definition, i.e. "if and only if there is no line that begins with Signed-off-by:, add a blank line before adding a new sign-off". For the upcoming release, stop using the append_signoff() in "git am" and reimplement the looser definition used by the scripted version to use only in "git am" to fix this regression in "am" while avoiding new regressions to other users of append_signoff(). In the longer term, we should look into loosening append_signoff() so that other codepaths that add a new sign-off behave the same way as "git am -s", but that is a task for post-release. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-04Sync with maintLibravatar Junio C Hamano0-0/+0
* maint:
2015-09-03Merge branch 'ee/clean-test-fixes' into maintLibravatar Junio C Hamano1-12/+4
* ee/clean-test-fixes: t7300: fix broken && chains
2015-09-03Merge branch 'jk/log-missing-default-HEAD' into maintLibravatar Junio C Hamano2-1/+30
"git init empty && git -C empty log" said "bad default revision 'HEAD'", which was found to be a bit confusing to new users. * jk/log-missing-default-HEAD: log: diagnose empty HEAD more clearly
2015-09-03Merge branch 'cc/trailers-corner-case-fix' into maintLibravatar Junio C Hamano2-3/+39
The "interpret-trailers" helper mistook a multi-paragraph title of a commit log message with a colon in it as the end of the trailer block. * cc/trailers-corner-case-fix: trailer: support multiline title trailer: retitle a test and correct an in-comment message trailer: ignore first line of message
2015-09-03Merge branch ↵Libravatar Junio C Hamano3-5/+15
'dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update' into maint When re-priming the cache-tree opportunistically while committing the in-core index as-is, we mistakenly invalidated the in-core index too aggressively, causing the experimental split-index code to unnecessarily rewrite the on-disk index file(s). * dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update: commit: don't rewrite shared index unnecessarily
2015-09-03Merge branch 'rs/archive-zip-many' into maintLibravatar Junio C Hamano2-5/+134
"git archive" did not use zip64 extension when creating an archive with more than 64k entries, which nobody should need, right ;-)? * rs/archive-zip-many: archive-zip: support more than 65535 entries archive-zip: use a local variable to store the creator version t5004: test ZIP archives with many entries
2015-09-03Merge branch 'jc/calloc-pathspec' into maintLibravatar Junio C Hamano2-2/+2
Minor code cleanup. * jc/calloc-pathspec: ps_matched: xcalloc() takes nmemb and then element size
2015-09-03Merge branch 'ss/fix-config-fd-leak' into maintLibravatar Junio C Hamano1-1/+4
* ss/fix-config-fd-leak: config: close config file handle in case of error
2015-09-03Merge branch 'sg/wt-status-header-inclusion' into maintLibravatar Junio C Hamano2-1/+1
* sg/wt-status-header-inclusion: wt-status: move #include "pathspec.h" to the header
2015-09-03Merge branch 'po/po-readme' into maintLibravatar Junio C Hamano1-0/+19
Doc updates for i18n. * po/po-readme: po/README: Update directions for l10n contributors
2015-09-03Merge branch 'sg/t3020-typofix' into maintLibravatar Junio C Hamano1-1/+1
* sg/t3020-typofix: t3020: fix typo in test description
2015-09-03Merge branch 'as/docfix-reflog-expire-unreachable' into maintLibravatar Junio C Hamano1-1/+1
Docfix. * as/docfix-reflog-expire-unreachable: Documentation/config: fix inconsistent label on gc.*.reflogExpireUnreachable
2015-09-03Merge branch 'nd/fixup-linked-gitdir' into maintLibravatar Junio C Hamano1-2/+2
The code in "multiple-worktree" support that attempted to recover from an inconsistent state updated an incorrect file. * nd/fixup-linked-gitdir: setup: update the right file in multiple checkouts
2015-09-03Merge branch 'jk/rev-list-has-no-notes' into maintLibravatar Junio C Hamano4-0/+9
"git rev-list" does not take "--notes" option, but did not complain when one is given. * jk/rev-list-has-no-notes: rev-list: make it obvious that we do not support notes
2015-09-03Merge branch 'jk/fix-alias-pager-config-key-warnings' into maintLibravatar Junio C Hamano5-12/+43
Because the configuration system does not allow "alias.0foo" and "pager.0foo" as the configuration key, the user cannot use '0foo' as a custom command name anyway, but "git 0foo" tried to look these keys up and emitted useless warnings before saying '0foo is not a git command'. These warning messages have been squelched. * jk/fix-alias-pager-config-key-warnings: config: silence warnings for command names with invalid keys
2015-09-03Merge branch 'nd/dwim-wildcards-as-pathspecs' into maintLibravatar Junio C Hamano1-1/+1
Test updates for Windows. * nd/dwim-wildcards-as-pathspecs: t2019: skip test requiring '*' in a file name non Windows
2015-09-03Merge branch 'sg/help-group' into maintLibravatar Junio C Hamano3-52/+52
We rewrote one of the build scripts in Perl but this reimplements in Bourne shell. * sg/help-group: generate-cmdlist: re-implement as shell script
2015-09-03Merge branch 'ps/t1509-chroot-test-fixup' into maintLibravatar Junio C Hamano1-4/+4
t1509 test that requires a dedicated VM environment had some bitrot, which has been corrected. * ps/t1509-chroot-test-fixup: tests: fix cleanup after tests in t1509-root-worktree tests: fix broken && chains in t1509-root-worktree
2015-09-03Merge branch 'jh/strbuf-read-use-read-in-full' into maintLibravatar Junio C Hamano1-5/+5
strbuf_read() used to have one extra iteration (and an unnecessary strbuf_grow() of 8kB), which was eliminated. * jh/strbuf-read-use-read-in-full: strbuf_read(): skip unnecessary strbuf_grow() at eof
2015-09-03Merge branch 'jk/long-error-messages' into maintLibravatar Junio C Hamano3-29/+21
The codepath to produce error messages had a hard-coded limit to the size of the message, primarily to avoid memory allocation while calling die(). * jk/long-error-messages: vreportf: avoid intermediate buffer vreportf: report to arbitrary filehandles
2015-09-03Merge branch 'cb/open-noatime-clear-errno' into maintLibravatar Junio C Hamano1-1/+4
When trying to see that an object does not exist, a state errno leaked from our "first try to open a packfile with O_NOATIME and then if it fails retry without it" logic on a system that refuses O_NOATIME. This confused us and caused us to die, saying that the packfile is unreadable, when we should have just reported that the object does not exist in that packfile to the caller. * cb/open-noatime-clear-errno: git_open_noatime: return with errno=0 on success
2015-09-03Merge branch 'mh/get-remote-group-fix' into maintLibravatar Junio C Hamano1-8/+6
An off-by-one error made "git remote" to mishandle a remote with a single letter nickname. * mh/get-remote-group-fix: get_remote_group(): use skip_prefix() get_remote_group(): eliminate superfluous call to strcspn() get_remote_group(): rename local variable "space" to "wordlen" get_remote_group(): handle remotes with single-character names
2015-09-03Merge branch 'jk/am-rerere-lock-fix'Libravatar Junio C Hamano5-16/+61
Recent "git am" introduced a double-locking failure when used with the "--3way" option that invokes rerere machinery. * jk/am-rerere-lock-fix: rerere: release lockfile in non-writing functions
2015-09-02Git 2.6-rc0Libravatar Junio C Hamano2-4/+13
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-02Merge branch 'cc/trailers-corner-case-fix'Libravatar Junio C Hamano2-4/+25
The "interpret-trailers" helper mistook a multi-paragraph title of a commit log message with a colon in it as the end of the trailer block. * cc/trailers-corner-case-fix: trailer: support multiline title
2015-09-02Merge branch 'sb/read-cache-one-indent-style-fix'Libravatar Junio C Hamano1-1/+1
* sb/read-cache-one-indent-style-fix: read-cache: fix indentation in read_index_from
2015-09-02Merge branch 'ee/clean-test-fixes'Libravatar Junio C Hamano1-12/+4
* ee/clean-test-fixes: t7300: fix broken && chains
2015-09-02Merge branch 'jk/log-missing-default-HEAD'Libravatar Junio C Hamano2-1/+30
"git init empty && git -C empty log" said "bad default revision 'HEAD'", which was found to be a bit confusing to new users. * jk/log-missing-default-HEAD: log: diagnose empty HEAD more clearly
2015-09-01Ninth batch for 2.6Libravatar Junio C Hamano1-0/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-01Merge branch ↵Libravatar Junio C Hamano3-5/+15
'dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update' When re-priming the cache-tree opportunistically while committing the in-core index as-is, we mistakenly invalidated the in-core index too aggressively, causing the experimental split-index code to unnecessarily rewrite the on-disk index file(s). * dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update: commit: don't rewrite shared index unnecessarily
2015-09-01Merge branch 'rt/remove-hold-lockfile-for-append'Libravatar Junio C Hamano2-57/+7
* rt/remove-hold-lockfile-for-append: lockfile: remove function "hold_lock_file_for_append"
2015-09-01Merge branch 'rs/archive-zip-many'Libravatar Junio C Hamano2-5/+134
"git archive" did not use zip64 extension when creating an archive with more than 64k entries, which nobody should need, right ;-)? * rs/archive-zip-many: archive-zip: support more than 65535 entries archive-zip: use a local variable to store the creator version t5004: test ZIP archives with many entries
2015-09-01Merge branch 'ls/p4-fold-case-client-specs'Libravatar Junio C Hamano2-0/+207
On case insensitive systems, "git p4" did not work well with client specs. * ls/p4-fold-case-client-specs: git-p4: honor core.ignorecase when using P4 client specs
2015-09-01Merge branch 'ah/submodule-typofix-in-error'Libravatar Junio C Hamano1-1/+1
Error string fix. * ah/submodule-typofix-in-error: git-submodule: remove extraneous space from error message
2015-09-01Merge branch 'ah/reflog-typofix-in-error'Libravatar Junio C Hamano1-1/+1
Error string fix. * ah/reflog-typofix-in-error: reflog: add missing single quote to error message
2015-09-01Merge branch 'ah/read-tree-usage-string'Libravatar Junio C Hamano1-1/+1
Usage string fix. * ah/read-tree-usage-string: read-tree: replace bracket set with parentheses to clarify usage
2015-09-01Merge branch 'ah/pack-objects-usage-strings'Libravatar Junio C Hamano1-2/+2
Usage string fix. * ah/pack-objects-usage-strings: pack-objects: place angle brackets around placeholders in usage strings
2015-09-01Merge branch 'br/svn-doc-include-paths-config'Libravatar Junio C Hamano1-0/+3
* br/svn-doc-include-paths-config: git-svn doc: mention "svn-remote.<name>.include-paths"
2015-09-01Merge branch 'nd/fixup-linked-gitdir'Libravatar Junio C Hamano1-2/+2
The code in "multiple-worktree" support that attempted to recover from an inconsistent state updated an incorrect file. * nd/fixup-linked-gitdir: setup: update the right file in multiple checkouts
2015-09-01rerere: release lockfile in non-writing functionsLibravatar Jeff King5-16/+61
There's a bug in builtin/am.c in which we take a lock on MERGE_RR recursively. But rather than fix am.c, this patch fixes the confusing interface from rerere.c that caused the bug. Read on for the gory details. The setup_rerere() function both reads the existing MERGE_RR file, and takes MERGE_RR.lock. In the rerere() and rerere_forget() functions, we end up in write_rr(), which will then commit the lock file. But for functions like rerere_clear() that do not write to MERGE_RR, we expect the caller to have handled setup_rerere(). That caller would then need to release the lockfile, but it can't; the lock struct is local to rerere.c. For builtin/rerere.c, this is OK. We run a single rerere operation and then exit immediately, which has the side effect of rolling back the lockfile. But in builtin/am.c, this is actively wrong. If we run "git am -3 --skip", we call setup-rerere twice without releasing the lock: 1. The "--skip" causes us to call am_rerere_clear(), which calls setup_rerere(), but never drops the lock. 2. We then proceed to the next patch. 3. The "--3way" may cause us to call rerere() to handle conflicts in that patch, but we are already holding the lock. The lockfile code dies with: BUG: prepare_tempfile_object called for active object We could fix this by having rerere_clear() call rollback_lock_file(). But it feels a bit odd for it to roll back a lockfile that it did not itself take. So let's simplify the interface further, and handle setup_rerere in the function itself, taking away the question from the caller over whether they need to do so. We can give rerere_gc() the same treatment, as well (even though it doesn't have any callers besides builtin/rerere.c at this point). Note that these functions don't take flags from their callers to pass along to setup_rerere; that's OK, because the flags would not be meaningful for what they are doing. Both of those functions need to hold the lock because even though they do not write to MERGE_RR, they are still writing and should be protected from a simultaneous "rerere" run. But rerere_remaining(), "rerere diff", and "rerere status" are all read-only operations. They want to setup_rerere(), but do not care about taking the lock in the first place. Since our update of MERGE_RR is the usual atomic rename done by commit_lock_file, they can just do a lockless read. For that, we teach setup_rerere a READONLY flag to avoid the lock. As a bonus, this pushes builtin/rerere.c's setup_rerere call closer to the functions that use it. Which means that "git rerere totally-bogus-command" will no longer silently exit(0) in a repository without rerere enabled. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-31Eighth batch for 2.6Libravatar Junio C Hamano1-0/+39
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-31Merge branch 'sg/describe-contains'Libravatar Junio C Hamano3-6/+14
"git describe" without argument defaulted to describe the HEAD commit, but "git describe --contains" didn't. Arguably, in a repository used for active development, such defaulting would not be very useful as the tip of branch is typically not tagged, but it is better to be consistent. * sg/describe-contains: describe --contains: default to HEAD when no commit-ish is given
2015-08-31Merge branch 'db/push-sign-if-asked'Libravatar Junio C Hamano14-152/+253
The client side codepaths in "git push" have been cleaned up and the user can request to perform an optional "signed push", i.e. sign only when the other end accepts signed push. * db/push-sign-if-asked: push: add a config option push.gpgSign for default signed pushes push: support signing pushes iff the server supports it builtin/send-pack.c: use parse_options API config.c: rename git_config_maybe_bool_text and export it as git_parse_maybe_bool transport: remove git_transport_options.push_cert gitremote-helpers.txt: document pushcert option Documentation/git-send-pack.txt: document --signed Documentation/git-send-pack.txt: wrap long synopsis line Documentation/git-push.txt: document when --signed may fail
2015-08-31Merge branch 'jk/notes-merge-config'Libravatar Junio C Hamano8-25/+187
"git notes merge" can be told with "--strategy=<how>" option how to automatically handle conflicts; this can now be configured by setting notes.mergeStrategy configuration variable. * jk/notes-merge-config: notes: teach git-notes about notes.<name>.mergeStrategy option notes: add notes.mergeStrategy option to select default strategy notes: add tests for --commit/--abort/--strategy exclusivity notes: extract parse_notes_merge_strategy to notes-utils notes: extract enum notes_merge_strategy to notes-utils.h notes: document cat_sort_uniq rewriteMode
2015-08-31Merge branch 'jc/am-state-fix'Libravatar Junio C Hamano10-44/+80
Recent reimplementation of "git am" changed the format of state files kept in $GIT_DIR/rebase-apply/ without meaning to do so, primarily because write_file() API was cumbersome to use and it was easy to mistakenly make text files with incomplete lines. Update write_file() interface to make it harder to misuse. * jc/am-state-fix: write_file(): drop caller-supplied LF from calls to create a one-liner file write_file_v(): do not leave incomplete line at the end write_file(): drop "fatal" parameter builtin/am: make sure state files are text builtin/am: introduce write_state_*() helper functions
2015-08-31Merge branch 'jc/log-p-cc'Libravatar Junio C Hamano1-9/+16
"git log --cc" did not show any patch, even though most of the time the user meant "git log --cc -p -m" to see patch output for commits with a single parent, and combined diff for merge commits. The command is taught to DWIM "--cc" (without "--raw" and other forms of output specification) to "--cc -p -m". * jc/log-p-cc: builtin/log.c: minor reformat log: show merge commit when --cc is given log: when --cc is given, default to -p unless told otherwise log: rename "tweak" helpers