Skip to main content

Browse the archive

swh:1:snp:47f1e8bb459169b0feb652a9c3d9cbabd8526d4a
sort by:
Revision Author Date Message Commit Date
19bf6c9 Michael Haggerty 08 June 2015, 13:40:05 UTC fsck: report errors if reflog entries point at invalid objects Previously, if a reflog entry's old or new SHA-1 was not resolvable to an object, that SHA-1 was silently ignored. Instead, report such cases as errors. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 June 2015, 19:40:36 UTC
d66ae59 Michael Haggerty 08 June 2015, 13:40:04 UTC fsck_handle_reflog_sha1(): new function New function, extracted from fsck_handle_reflog_ent(). The extra is_null_sha1() test for the new reference is currently unnecessary, as reflogs are deleted when the reference itself is deleted. But it doesn't hurt, either. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 June 2015, 19:37:32 UTC
501cf47 Michael Haggerty 03 June 2015, 13:51:59 UTC read_loose_refs(): treat NULL_SHA1 loose references as broken NULL_SHA1 is used to indicate an "invalid object name" throughout our code (and the code of other git implementations), so it is vastly more likely that an on-disk reference was set to this value due to a software bug than that NULL_SHA1 is the legitimate SHA-1 of an actual object. Therefore, if a loose reference has the value NULL_SHA1, consider it to be broken. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 June 2015, 17:35:41 UTC
72dbb36 SZEDER Gábor 08 June 2015, 01:43:31 UTC completion: teach 'scissors' mode to 'git commit --cleanup=' Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 June 2015, 15:46:47 UTC
e654eb2 Eric Sunshine 05 June 2015, 06:42:16 UTC utf8: NO_ICONV: silence uninitialized variable warning The last argument of reencode_string_len() is an 'int *' which is assigned the length of the converted string. When NO_ICONV is defined, however, reencode_string_len() is stubbed out by the macro: #define reencode_string_len(a,b,c,d,e) NULL which never assigns a value to the final argument. When called like this: int n; char *s = reencode_string_len(..., &n); if (s) do_something(s, n); some compilers complain that 'n' is used uninitialized within the conditional. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 June 2015, 22:36:35 UTC
69f9a6e Junio C Hamano 05 June 2015, 19:15:57 UTC Git 2.4.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 June 2015, 19:22:33 UTC
cbac706 Junio C Hamano 05 June 2015, 19:00:29 UTC Merge branch 'dl/branch-error-message' into maint Error messages from "git branch" called remote-tracking branches as "remote branches". * dl/branch-error-message: branch: do not call a "remote-tracking branch" a "remote branch" 05 June 2015, 19:00:29 UTC
c538004 Junio C Hamano 05 June 2015, 19:00:28 UTC Merge branch 'jk/skip-http-tests-under-no-curl' into maint Test clean-up. * jk/skip-http-tests-under-no-curl: tests: skip dav http-push tests under NO_EXPAT=NoThanks t/lib-httpd.sh: skip tests if NO_CURL is defined 05 June 2015, 19:00:28 UTC
e41f8d9 Junio C Hamano 05 June 2015, 19:00:27 UTC Merge branch 'ps/doc-packfile-vs-pack-file' into maint Doc consistency updates. * ps/doc-packfile-vs-pack-file: doc: fix inconsistent spelling of "packfile" pack-protocol.txt: fix insconsistent spelling of "packfile" git-unpack-objects.txt: fix inconsistent spelling of "packfile" git-verify-pack.txt: fix inconsistent spelling of "packfile" 05 June 2015, 19:00:27 UTC
48feda5 Junio C Hamano 05 June 2015, 19:00:26 UTC Merge branch 'fg/document-commit-message-stripping' into maint * fg/document-commit-message-stripping: Documentation: clarify how "git commit" cleans up the edited log message 05 June 2015, 19:00:26 UTC
5c2e654 Junio C Hamano 05 June 2015, 19:00:25 UTC Merge branch 'jk/rerere-forget-check-enabled' into maint "git rerere forget" in a repository without rerere enabled gave a cryptic error message; it should be a silent no-op instead. * jk/rerere-forget-check-enabled: rerere: exit silently on "forget" when rerere is disabled 05 June 2015, 19:00:25 UTC
4cb9fe3 Junio C Hamano 05 June 2015, 19:00:24 UTC Merge branch 'pt/pull-log-n' into maint "git pull --log" and "git pull --no-log" worked as expected, but "git pull --log=20" did not. * pt/pull-log-n: pull: handle --log=<n> 05 June 2015, 19:00:24 UTC
7e46f27 Junio C Hamano 05 June 2015, 19:00:23 UTC Merge branch 'pt/pull-ff-vs-merge-ff' into maint The pull.ff configuration was supposed to override the merge.ff configuration, but it didn't. * pt/pull-ff-vs-merge-ff: pull: parse pull.ff as a bool or string pull: make pull.ff=true override merge.ff 05 June 2015, 19:00:23 UTC
0662990 Junio C Hamano 05 June 2015, 19:00:22 UTC Merge branch 'rs/plug-leak-in-pack-bitmaps' into maint The code to read pack-bitmap wanted to allocate a few hundred pointers to a structure, but by mistake allocated and leaked memory enough to hold that many actual structures. Correct the allocation size and also have it on stack, as it is small enough. * rs/plug-leak-in-pack-bitmaps: pack-bitmaps: plug memory leak, fix allocation size for recent_bitmaps 05 June 2015, 19:00:22 UTC
7c1ff53 Junio C Hamano 05 June 2015, 19:00:22 UTC Merge branch 'ja/tutorial-asciidoctor-fix' into maint A literal block in the tutorial had lines with unequal lengths to delimit it from the rest of the document, which choke GitHub's AsciiDoc renderer. * ja/tutorial-asciidoctor-fix: doc: fix unmatched code fences 05 June 2015, 19:00:22 UTC
413a715 Junio C Hamano 05 June 2015, 19:00:20 UTC Merge branch 'jk/stripspace-asciidoctor-fix' into maint A literal block in the tutorial had lines with unequal lengths to delimit it from the rest of the document, which choke GitHub's AsciiDoc renderer. * jk/stripspace-asciidoctor-fix: doc: fix unmatched code fences in git-stripspace 05 June 2015, 19:00:21 UTC
96b7f93 Junio C Hamano 05 June 2015, 19:00:19 UTC Merge branch 'jk/asciidoc-markup-fix' into maint Various documentation mark-up fixes to make the output more consistent in general and also make AsciiDoctor (an alternative formatter) happier. * jk/asciidoc-markup-fix: doc: convert AsciiDoc {?foo} to ifdef::foo[] doc: put example URLs and emails inside literal backticks doc: drop backslash quoting of some curly braces doc: convert \--option to --option doc/add: reformat `--edit` option doc: fix length of underlined section-title doc: fix hanging "+"-continuation doc: fix unquoted use of "{type}" doc: fix misrendering due to `single quote' 05 June 2015, 19:00:19 UTC
51f319c Junio C Hamano 05 June 2015, 19:00:18 UTC Merge branch 'ps/bundle-verify-arg' into maint "git bundle verify" did not diagnose extra parameters on the command line. * ps/bundle-verify-arg: bundle: verify arguments more strictly 05 June 2015, 19:00:18 UTC
7c997bc Junio C Hamano 05 June 2015, 19:00:17 UTC Merge branch 'mh/write-refs-sooner-2.4' into maint Multi-ref transaction support we merged a few releases ago unnecessarily kept many file descriptors open, risking to fail with resource exhaustion. This is for 2.4.x track. * mh/write-refs-sooner-2.4: ref_transaction_commit(): fix atomicity and avoid fd exhaustion ref_transaction_commit(): remove the local flags variable ref_transaction_commit(): inline call to write_ref_sha1() rename_ref(): inline calls to write_ref_sha1() from this function commit_ref_update(): new function, extracted from write_ref_sha1() write_ref_to_lockfile(): new function, extracted from write_ref_sha1() t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE update-ref: test handling large transactions properly ref_transaction_commit(): fix atomicity and avoid fd exhaustion ref_transaction_commit(): remove the local flags variable ref_transaction_commit(): inline call to write_ref_sha1() rename_ref(): inline calls to write_ref_sha1() from this function commit_ref_update(): new function, extracted from write_ref_sha1() write_ref_to_lockfile(): new function, extracted from write_ref_sha1() t7004: rename ULIMIT test prerequisite to ULIMIT_STACK_SIZE update-ref: test handling large transactions properly 05 June 2015, 19:00:17 UTC
4ba8846 Junio C Hamano 05 June 2015, 19:00:16 UTC Merge branch 'mh/ref-directory-file' into maint The ref API did not handle cases where 'refs/heads/xyzzy/frotz' is removed at the same time as 'refs/heads/xyzzy' is added (or vice versa) very well. * mh/ref-directory-file: reflog_expire(): integrate lock_ref_sha1_basic() errors into ours ref_transaction_commit(): delete extra "the" from error message ref_transaction_commit(): provide better error messages rename_ref(): integrate lock_ref_sha1_basic() errors into ours lock_ref_sha1_basic(): improve diagnostics for ref D/F conflicts lock_ref_sha1_basic(): report errors via a "struct strbuf *err" verify_refname_available(): report errors via a "struct strbuf *err" verify_refname_available(): rename function refs: check for D/F conflicts among refs created in a transaction ref_transaction_commit(): use a string_list for detecting duplicates is_refname_available(): use dirname in first loop struct nonmatching_ref_data: store a refname instead of a ref_entry report_refname_conflict(): inline function entry_matches(): inline function is_refname_available(): convert local variable "dirname" to strbuf is_refname_available(): avoid shadowing "dir" variable is_refname_available(): revamp the comments t1404: new tests of ref D/F conflicts within transactions 05 June 2015, 19:00:16 UTC
5efef30 Junio C Hamano 05 June 2015, 19:00:15 UTC Merge branch 'mg/log-decorate-HEAD' into maint The "log --decorate" enhancement in Git 2.4 that shows the commit at the tip of the current branch e.g. "HEAD -> master", did not work with --decorate=full. * mg/log-decorate-HEAD: log: do not shorten decoration names too early log: decorate HEAD with branch name under --decorate=full, too 05 June 2015, 19:00:15 UTC
5e896a3 Junio C Hamano 05 June 2015, 19:00:14 UTC Merge branch 'sb/t1020-cleanup' into maint There was a commented-out (instead of being marked to expect failure) test that documented a breakage that was fixed since the test was written; turn it into a proper test. * sb/t1020-cleanup: subdirectory tests: code cleanup, uncomment test 05 June 2015, 19:00:14 UTC
e9f767e Junio C Hamano 05 June 2015, 19:00:12 UTC Merge branch 'jc/gitignore-precedence' into maint core.excludesfile (defaulting to $XDG_HOME/git/ignore) is supposed to be overridden by repository-specific .git/info/exclude file, but the order was swapped from the beginning. This belatedly fixes it. * jc/gitignore-precedence: ignore: info/exclude should trump core.excludesfile 05 June 2015, 19:00:13 UTC
2d8bb46 Junio C Hamano 05 June 2015, 19:00:11 UTC Merge branch 'bc/connect-plink' into maint The connection initiation code for "ssh" transport tried to absorb differences between the stock "ssh" and Putty-supplied "plink" and its derivatives, but the logic to tell that we are using "plink" variants were too loose and falsely triggered when "plink" appeared anywhere in the path (e.g. "/home/me/bin/uplink/ssh"). * bc/connect-plink: connect: improve check for plink to reduce false positives t5601: fix quotation error leading to skipped tests connect: simplify SSH connection code path 05 June 2015, 19:00:11 UTC
c7b4de2 Junio C Hamano 05 June 2015, 19:00:10 UTC Merge branch 'ph/rebase-i-redo' into maint "git rebase -i" moved the "current" command from "todo" to "done" a bit too prematurely, losing a step when a "pick" did not even start. * ph/rebase-i-redo: rebase -i: redo tasks that die during cherry-pick 05 June 2015, 19:00:10 UTC
8d5ef5a Junio C Hamano 05 June 2015, 19:00:09 UTC Merge branch 'jk/add-e-kill-editor' into maint "git add -e" did not allow the user to abort the operation by killing the editor. * jk/add-e-kill-editor: add: check return value of launch_editor 05 June 2015, 19:00:09 UTC
a3821a1 Junio C Hamano 05 June 2015, 19:00:08 UTC Merge branch 'mh/clone-verbosity-fix' into maint Git 2.4 broke setting verbosity and progress levels on "git clone" with native transports. * mh/clone-verbosity-fix: clone: call transport_set_verbosity before anything else on the newly created transport 05 June 2015, 19:00:08 UTC
3c91e99 Junio C Hamano 05 June 2015, 19:00:07 UTC Merge branch 'jk/sha1-file-reduce-useless-warnings' into maint * jk/sha1-file-reduce-useless-warnings: sha1_file: squelch "packfile cannot be accessed" warnings 05 June 2015, 19:00:07 UTC
1d93ec9 Junio C Hamano 05 June 2015, 19:00:06 UTC Merge branch 'tb/blame-resurrect-convert-to-git' into maint Some time ago, "git blame" (incorrectly) lost the convert_to_git() call when synthesizing a fake "tip" commit that represents the state in the working tree, which broke folks who record the history with LF line ending to make their project portabile across platforms while terminating lines in their working tree files with CRLF for their platform. * tb/blame-resurrect-convert-to-git: blame: CRLF in the working tree and LF in the repo 05 June 2015, 19:00:06 UTC
bdf204f Junio C Hamano 05 June 2015, 19:00:05 UTC Merge branch 'jc/plug-fmt-merge-msg-leak' into maint * jc/plug-fmt-merge-msg-leak: fmt-merge-msg: plug small leak of commit buffer 05 June 2015, 19:00:05 UTC
d9c82fa Junio C Hamano 05 June 2015, 19:00:03 UTC Merge branch 'pt/xdg-config-path' into maint Code clean-up for xdg configuration path support. * pt/xdg-config-path: path.c: remove home_config_paths() git-config: replace use of home_config_paths() git-commit: replace use of home_config_paths() credential-store.c: replace home_config_paths() with xdg_config_home() dir.c: replace home_config_paths() with xdg_config_home() attr.c: replace home_config_paths() with xdg_config_home() path.c: implement xdg_config_home() t0302: "unreadable" test needs POSIXPERM t0302: test credential-store support for XDG_CONFIG_HOME git-credential-store: support XDG_CONFIG_HOME git-credential-store: support multiple credential files 05 June 2015, 19:00:04 UTC
f551707 Michael Haggerty 03 June 2015, 13:51:58 UTC read_loose_refs(): simplify function logic Make it clearer that there are two possible ways to read the reference, but that we handle read errors uniformly regardless of which way it was read. This refactoring also makes the following change easier to implement. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 June 2015, 18:44:25 UTC
34b935c Jeff King 03 June 2015, 06:39:37 UTC ewah: use less generic macro name The ewah/ewok.h header pollutes the global namespace with "BITS_IN_WORD", without any specific notion that we are talking about the bits in an eword_t. We can give this the more specific name "BITS_IN_EWORD". Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 June 2015, 07:04:01 UTC
414382f Eric Sunshine 03 June 2015, 06:39:17 UTC ewah/bitmap: silence warning about MASK macro redefinition On PowerPC Mac OS X (10.5.8 "Leopard" with Xcode 3.1), system header /usr/include/ppc/param.h[1] pollutes the preprocessor namespace with a macro generically named MASK. This conflicts with the same-named macro in ewah/bitmap.c. We can avoid this conflict by using a more specific name. [1]: Included indirectly via: git-compat-util.h -> sys/sysctl.h -> sys/ucred.h -> sys/param.h -> machine/param.h -> ppc/param.h Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 June 2015, 07:03:03 UTC
055c7e9 Stefan Beller 02 June 2015, 00:02:17 UTC Documentation/technical/pack-protocol: mention http as possible protocol Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 June 2015, 21:59:59 UTC
8afc493 Michael Haggerty 02 June 2015, 15:57:26 UTC for-each-ref: report broken references correctly If there is a loose reference file with invalid contents, "git for-each-ref" incorrectly reports the problem as being a missing object with name NULL_SHA1: $ echo '12345678' >.git/refs/heads/nonsense $ git for-each-ref fatal: missing object 0000000000000000000000000000000000000000 for refs/heads/nonsense With an explicit "--format" string, it can even report that the reference validly points at NULL_SHA1: $ git for-each-ref --format='%(objectname) %(refname)' 0000000000000000000000000000000000000000 refs/heads/nonsense $ echo $? 0 This has been broken since b7dd2d2 for-each-ref: Do not lookup objects when they will not be used (2009-05-27) , which changed for-each-ref from using for_each_ref() to using git_for_each_rawref() in order to avoid looking up the referred-to objects unnecessarily. (When "git for-each-ref" is given a "--format" string that doesn't include information about the pointed-to object, it does not look up the object at all, which makes it considerably faster. Iterating with DO_FOR_EACH_INCLUDE_BROKEN is essential to this optimization because otherwise for_each_ref() would itself need to check whether the object exists as part of its brokenness test.) But for_each_rawref() includes broken references in the iteration, and "git for-each-ref" doesn't itself reject references with REF_ISBROKEN. The result is that broken references are processed *as if* they had the value NULL_SHA1, which is the value stored in entries for broken references. Change "git for-each-ref" to emit warnings for references that are REF_ISBROKEN but to otherwise skip them. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 June 2015, 20:09:16 UTC
c3e23dc Michael Haggerty 02 June 2015, 15:57:25 UTC t6301: new tests of for-each-ref error handling Add tests that for-each-ref correctly reports broken loose reference files and references that point at missing objects. In fact, two of these tests fail, because (1) NULL_SHA1 is not recognized as an invalid reference value, and (2) for-each-ref doesn't respect REF_ISBROKEN. Fixes to come. Note that when for-each-ref is run with a --format option that doesn't require the object to be looked up, then we should still notice if a loose reference file is corrupt or contains NULL_SHA1, but we don't notice if it points at a missing object because we don't do an object lookup. This is OK. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 June 2015, 20:09:04 UTC
9b7a61d Junio C Hamano 01 June 2015, 17:44:21 UTC format-patch: do not feed tags to clear_commit_marks() "git format-patch --ignore-if-in-upstream A..B", when either A or B is a tag, failed miserably. This is because the code passes the tips it used for traversal to clear_commit_marks(), after running a temporary revision traversal to enumerate the commits on both branches to find if they have commits that make equivalent changes. The revision traversal machinery knows how to enumerate commits reachable starting from a tag, but clear_commit_marks() wants to take nothing but a commit. In the longer term, it might be a more correct fix to teach clear_commit_marks() to do the same "committish to commit" dereferencing that is done in the revision traversal machinery, but for now this fix should suffice. Reported-by: Bruce Korb <bruce.korb@gmail.com> Helped-by: Christian Couder <christian.couder@gmail.com> Helped-by: brian m. carlson <sandals@crustytoothpaste.net> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 June 2015, 23:02:52 UTC
ce4e7b2 Jeff King 01 June 2015, 09:56:40 UTC suppress errors on missing UNINTERESTING links When we are traversing commit parents along the UNINTERESTING side of a revision walk, we do not care if the parent turns out to be missing. That lets us limit traversals using unreachable and possibly incomplete sections of history. However, we do still print error messages about the missing commits; this patch suppresses the error, as well. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 June 2015, 16:29:51 UTC
daf7d86 Jeff King 01 June 2015, 09:56:37 UTC silence broken link warnings with revs->ignore_missing_links We set revs->ignore_missing_links to instruct the revision-walking machinery that we know the history graph may be incomplete. For example, we use it when walking unreachable but recent objects; we want to add what we can, but it's OK if the history is incomplete. However, we still print error messages for the missing objects, which can be confusing. This is not an error, but just a normal situation when transitioning from a repository last pruned by an older git (which can leave broken segments of history) to a more recent one (where we try to preserve whole reachable segments). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 June 2015, 16:29:50 UTC
9cc2b07 Jeff King 01 June 2015, 09:56:26 UTC add quieter versions of parse_{tree,commit} When we call parse_commit, it will complain to stderr if the object does not exist or cannot be read. This means that we may produce useless error messages if this situation is expected (e.g., because the object is marked UNINTERESTING, or because revs->ignore_missing_links is set). We can fix this by adding a new "parse_X_gently" form that takes a flag to suppress the messages. The existing "parse_X" form is already gentle in the sense that it returns an error rather than dying, and we could in theory just add a "quiet" flag to it (with existing callers passing "0"). But doing it this way means we do not have to disturb existing callers. Note also that the new flag is "quiet_on_missing", and not just "quiet". We could add a flag to suppress _all_ errors, but besides being a more invasive change (we would have to pass the flag down to sub-functions, too), there is a good reason not to: we would never want to use it. Missing a linked object is expected in some circumstances, but it is never expected to have a malformed commit, or to get a tree when we wanted a commit. We should always complain about these corruptions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 June 2015, 16:29:42 UTC
e6a268c Stefan Beller 29 May 2015, 18:23:56 UTC glossary: add "remote", "submodule", "superproject" Noticed-by: Philip Oakley <philipoakley@iee.org> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 May 2015, 20:36:47 UTC
fada767 Jeff King 29 May 2015, 06:49:10 UTC setup_git_directory: delay core.bare/core.worktree errors If both core.bare and core.worktree are set, we complain about the bogus config and die. Dying is good, because it avoids commands running and doing damage in a potentially incorrect setup. But dying _there_ is bad, because it means that commands which do not even care about the work tree cannot run. This can make repairing the situation harder: [setup] $ git config core.bare true $ git config core.worktree /some/path [OK, expected.] $ git status fatal: core.bare and core.worktree do not make sense [Hrm...] $ git config --unset core.worktree fatal: core.bare and core.worktree do not make sense [Nope...] $ git config --edit fatal: core.bare and core.worktree do not make sense [Gaaah.] $ git help config fatal: core.bare and core.worktree do not make sense Instead, let's issue a warning about the bogus config when we notice it (i.e., for all commands), but only die when the command tries to use the work tree (by calling setup_work_tree). So we now get: $ git status warning: core.bare and core.worktree do not make sense fatal: unable to set up work tree using invalid config $ git config --unset core.worktree warning: core.bare and core.worktree do not make sense We have to update t1510 to accomodate this; it uses symbolic-ref to check whether the configuration works or not, but of course that command does not use the working tree. Instead, we switch it to use `git status`, as it requires a work-tree, does not need any special setup, and is read-only (so a failure will not adversely affect further tests). In addition, we add a new test that checks the desired behavior (i.e., that running "git config" with the bogus config does in fact work). Reported-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 May 2015, 16:27:27 UTC
7c37a5d Jeff King 29 May 2015, 07:26:48 UTC Makefile: silence perl/PM.stamp recipe Every time we run "make", we update perl/PM.stamp, which contains a list of all of the perl module files (if it's updated, we need to rebuild perl/perl.mak, since the Makefile will not otherwise know about the new files). This means that every time "make" is run, we see: GEN perl/PM.stamp in the output, even though it is not likely to have changed. Let's make this recipe completely silent, as we do for other auto-generated dependency files (e.g., GIT-CFLAGS). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 May 2015, 16:22:19 UTC
a2d25ef Jeff King 29 May 2015, 07:26:30 UTC Makefile: avoid timestamp updates to GIT-BUILD-OPTIONS We force the GIT-BUILD-OPTIONS recipe to run every time "make" is invoked. We must do this to catch new options which may have come from the command-line or environment. However, we actually update the file's timestamp each time the recipe is run, whether anything changed or not. As a result, any files which depend on it (for example, all of the perl scripts, which need to know whether NO_PERL was set) will be re-built every time. Let's do our usual trick of writing to a tempfile, then doing a "cmp || mv" to update the file only when something changed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 May 2015, 16:22:18 UTC
e25c7cc Jeff King 29 May 2015, 07:25:45 UTC Makefile: drop dependency between git-instaweb and gitweb The rule for "git-instaweb" depends on "gitweb". This makes no sense, because: 1. git-instaweb has no build-time dependency on gitweb; it is a run-time dependency 2. gitweb is a directory that we want to recursively make in. As a result, its recipe is marked .PHONY, which causes "make" to rebuild git-instaweb every time it is run. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 May 2015, 16:21:27 UTC
ec48a76 Stefan Beller 27 May 2015, 19:48:01 UTC submodule doc: reorder introductory paragraphs It's better to start the man page with a description of what submodules actually are, instead of saying what they are not. Reorder the paragraphs such that - the first short paragraph introduces the submodule concept, - the second paragraph highlights the usage of the submodule command, - the third paragraph giving background information, and finally - the fourth paragraph discusing alternatives such as subtrees and remotes, which we don't want to be confused with. This ordering deepens the knowledge on submodules with each paragraph. First the basic questions like "How/what" will be answered, while the underlying concepts will be taught at a later time. Making sure it is not confused with subtrees and remotes is not really enhancing knowledge of submodules itself, but rather painting the big picture of git concepts, so you could also argue to have it as the second paragraph. Personally I think this may confuse readers, specially newcomers though. Additionally to reordering the paragraphs, they have been slightly reworded. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 May 2015, 22:18:11 UTC
fc0aa39 SZEDER Gábor 27 May 2015, 21:52:23 UTC Documentation: include 'merge.branchdesc' for merge and config as well 'merge.branchdesc' is only mentioned in the docs of 'git fmt-merge-msg'. The description of 'merge.log' is already duplicated between 'merge-config.txt' and 'git-fmt-merge-msg.txt'; instead of duplicating the description of another config variable, extract the descriptions of both of these variables from 'git-fmt-merge-msg.txt' into a separate file and include it there and in 'merge-config.txt'. Leave 'merge.summary' only in git-fmt-merge-msg.txt, as it is marked as deprecated. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 May 2015, 19:38:46 UTC
9ca0aaf Junio C Hamano 27 May 2015, 20:30:29 UTC xmmap(): drop "Out of memory?" We show that message with die_errno(), but the OS is ought to know why mmap(2) failed much better than we do. There is no reason for us to say "Out of memory?" here. Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 May 2015, 18:35:25 UTC
0e8771f Jeff King 28 May 2015, 08:03:01 UTC config.c: rewrite ENODEV into EISDIR when mmap fails If we try to mmap a directory, we'll get ENODEV. This translates to "no such device" for the user, which is not very helpful. Since we've just fstat()'d the file, we can easily check whether the problem was a directory to give a better message. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 May 2015, 18:34:06 UTC
1570856 Jeff King 28 May 2015, 07:56:15 UTC config.c: avoid xmmap error messages The config-writing code uses xmmap to map the existing config file, which will die if the map fails. This has two downsides: 1. The error message is not very helpful, as it lacks any context about the file we are mapping: $ mkdir foo $ git config --file=foo some.key value fatal: Out of memory? mmap failed: No such device 2. We normally do not die in this code path; instead, we'd rather report the error and return an appropriate exit status (which is part of the public interface documented in git-config.1). This patch introduces a "gentle" form of xmmap which lets us produce our own error message. We do not want to use mmap directly, because we would like to use the other compatibility elements of xmmap (e.g., handling 0-length maps portably). The end result is: $ git.compile config --file=foo some.key value error: unable to mmap 'foo': No such device $ echo $? 3 Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 May 2015, 18:33:18 UTC
3a1b312 Jeff King 28 May 2015, 07:54:43 UTC config.c: fix mmap leak when writing config We mmap the existing config file, but fail to unmap it if we hit an error. The function already has a shared exit path, so we can fix this by moving the mmap pointer to the function scope and clearing it in the shared exit. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 May 2015, 18:32:04 UTC
a1293ef Jeff King 28 May 2015, 07:54:00 UTC read-cache.c: drop PROT_WRITE from mmap of index Once upon a time, git's in-memory representation of a cache entry actually pointed to the mmap'd on-disk data. So in 520fc24 (Allow writing to the private index file mapping., 2005-04-26), we specified PROT_WRITE so that we could tweak the entries while we run (in our own MAP_PRIVATE copy-on-write version, of course). Later, 7a51ed6 (Make on-disk index representation separate from in-core one, 2008-01-14) stopped doing this; we copy the data into our in-core representation, and then drop the mmap immediately. We can therefore drop the PROT_WRITE flag. It's probably not hurting anything as it is, but it's potentially confusing. Note that we could also mark the mapping as "const" to verify that we never write to it. However, we don't typically do that for our other maps, as it then requires casting to munmap() it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 May 2015, 18:32:04 UTC
8dbf3eb Jeff King 27 May 2015, 20:48:46 UTC diff.h: rename DIFF_PLAIN color slot to DIFF_CONTEXT The latter is a much more descriptive name (and we support "color.diff.context" now). This also updates the name of any local variables which were used to store the color. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 May 2015, 20:54:42 UTC
74b15bf Jeff King 27 May 2015, 07:22:19 UTC diff: accept color.diff.context as a synonym for "plain" The term "plain" is a bit ambiguous; let's allow the more specific "context", but keep "plain" around for compatibility. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 May 2015, 20:54:37 UTC
14f8b9b Jeff King 21 May 2015, 04:16:04 UTC clone: reorder --dissociate and --reference options These options are intimately related, so it makes sense to list them nearby in the "-h" output (they are already adjacent in the manpage). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 May 2015, 19:37:39 UTC
8ade009 Jeff King 21 May 2015, 04:15:19 UTC clone: use OPT_STRING_LIST for --reference Not only does this save us having to implement a custom callback, but it handles "--no-reference" in the usual way (to clear the list). The generic callback does copy the string, which we don't technically need, but that should not hurt anything. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 May 2015, 19:37:28 UTC
9eabf5b Junio C Hamano 26 May 2015, 20:49:59 UTC Git 2.4.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 26 May 2015, 20:49:59 UTC
df08eb3 Junio C Hamano 26 May 2015, 20:49:26 UTC Merge branch 'jk/still-interesting' into maint "git rev-list --objects $old --not --all" to see if everything that is reachable from $old is already connected to the existing refs was very inefficient. * jk/still-interesting: limit_list: avoid quadratic behavior from still_interesting 26 May 2015, 20:49:26 UTC
1e6c8ba Junio C Hamano 26 May 2015, 20:49:24 UTC Merge branch 'jc/hash-object' into maint "hash-object --literally" introduced in v2.2 was not prepared to take a really long object type name. * jc/hash-object: write_sha1_file(): do not use a separate sha1[] array t1007: add hash-object --literally tests hash-object --literally: fix buffer overrun with extra-long object type git-hash-object.txt: document --literally option 26 May 2015, 20:49:25 UTC
5d53433 Junio C Hamano 26 May 2015, 20:49:23 UTC Merge branch 'jk/rebase-quiet-noop' into maint "git rebase --quiet" was not quite quiet when there is nothing to do. * jk/rebase-quiet-noop: rebase: silence "git checkout" for noop rebase 26 May 2015, 20:49:23 UTC
23903b9 Junio C Hamano 26 May 2015, 20:49:22 UTC Merge branch 'sg/complete-decorate-full-not-long' into maint The completion for "log --decorate=" parameter value was incorrect. * sg/complete-decorate-full-not-long: completion: fix and update 'git log --decorate=' options 26 May 2015, 20:49:22 UTC
a2e5c79 Junio C Hamano 26 May 2015, 20:49:20 UTC Merge branch 'jk/filter-branch-use-of-sed-on-incomplete-line' into maint "filter-branch" corrupted commit log message that ends with an incomplete line on platforms with some "sed" implementations that munge such a line. Work it around by avoiding to use "sed". * jk/filter-branch-use-of-sed-on-incomplete-line: filter-branch: avoid passing commit message through sed 26 May 2015, 20:49:20 UTC
6fd5836 Junio C Hamano 26 May 2015, 20:49:19 UTC Merge branch 'jc/daemon-no-ipv6-for-2.4.1' into maint "git daemon" fails to build from the source under NO_IPV6 configuration (regression in 2.4). * jc/daemon-no-ipv6-for-2.4.1: daemon: unbreak NO_IPV6 build regression 26 May 2015, 20:49:19 UTC
cb9ec8e Junio C Hamano 26 May 2015, 20:49:19 UTC Merge branch 'jk/stash-require-clean-index' into maint "git stash pop/apply" forgot to make sure that not just the working tree is clean but also the index is clean. The latter is important as a stash application can conflict and the index will be used for conflict resolution. * jk/stash-require-clean-index: stash: require a clean index to apply t3903: avoid applying onto dirty index t3903: stop hard-coding commit sha1s 26 May 2015, 20:49:19 UTC
af6d7a6 Junio C Hamano 26 May 2015, 20:49:18 UTC Merge branch 'jk/git-no-more-argv0-path-munging' into maint We have prepended $GIT_EXEC_PATH and the path "git" is installed in (typically "/usr/bin") to $PATH when invoking subprograms and hooks for almost eternity, but the original use case the latter tried to support was semi-bogus (i.e. install git to /opt/foo/git and run it without having /opt/foo on $PATH), and more importantly it has become less and less relevant as Git grew more mainstream (i.e. the users would _want_ to have it on their $PATH). Stop prepending the path in which "git" is installed to users' $PATH, as that would interfere the command search order people depend on (e.g. they may not like versions of programs that are unrelated to Git in /usr/bin and want to override them by having different ones in /usr/local/bin and have the latter directory earlier in their $PATH). * jk/git-no-more-argv0-path-munging: stop putting argv[0] dirname at front of PATH 26 May 2015, 20:49:18 UTC
636614f Junio C Hamano 26 May 2015, 03:44:42 UTC Merge branch 'jk/http-backend-deadlock-2.3' into jk/http-backend-deadlock * jk/http-backend-deadlock-2.3: http-backend: spool ref negotiation requests to buffer t5551: factor out tag creation http-backend: fix die recursion with custom handler 26 May 2015, 03:44:42 UTC
7419a03 Junio C Hamano 26 May 2015, 03:44:04 UTC Merge branch 'jk/http-backend-deadlock-2.2' into jk/http-backend-deadlock-2.3 * jk/http-backend-deadlock-2.2: http-backend: spool ref negotiation requests to buffer t5551: factor out tag creation http-backend: fix die recursion with custom handler 26 May 2015, 03:44:04 UTC
6bc0cb5 Jeff King 20 May 2015, 07:37:09 UTC http-backend: spool ref negotiation requests to buffer When http-backend spawns "upload-pack" to do ref negotiation, it streams the http request body to upload-pack, who then streams the http response back to the client as it reads. In theory, git can go full-duplex; the client can consume our response while it is still sending the request. In practice, however, HTTP is a half-duplex protocol. Even if our client is ready to read and write simultaneously, we may have other HTTP infrastructure in the way, including the webserver that spawns our CGI, or any intermediate proxies. In at least one documented case[1], this leads to deadlock when trying a fetch over http. What happens is basically: 1. Apache proxies the request to the CGI, http-backend. 2. http-backend gzip-inflates the data and sends the result to upload-pack. 3. upload-pack acts on the data and generates output over the pipe back to Apache. Apache isn't reading because it's busy writing (step 1). This works fine most of the time, because the upload-pack output ends up in a system pipe buffer, and Apache reads it as soon as it finishes writing. But if both the request and the response exceed the system pipe buffer size, then we deadlock (Apache blocks writing to http-backend, http-backend blocks writing to upload-pack, and upload-pack blocks writing to Apache). We need to break the deadlock by spooling either the input or the output. In this case, it's ideal to spool the input, because Apache does not start reading either stdout _or_ stderr until we have consumed all of the input. So until we do so, we cannot even get an error message out to the client. The solution is fairly straight-forward: we read the request body into an in-memory buffer in http-backend, freeing up Apache, and then feed the data ourselves to upload-pack. But there are a few important things to note: 1. We limit the in-memory buffer to prevent an obvious denial-of-service attack. This is a new hard limit on requests, but it's unlikely to come into play. The default value is 10MB, which covers even the ridiculous 100,000-ref negotation in the included test (that actually caps out just over 5MB). But it's configurable on the off chance that you don't mind spending some extra memory to make even ridiculous requests work. 2. We must take care only to buffer when we have to. For pushes, the incoming packfile may be of arbitrary size, and we should connect the input directly to receive-pack. There's no deadlock problem here, though, because we do not produce any output until the whole packfile has been read. For upload-pack's initial ref advertisement, we similarly do not need to buffer. Even though we may generate a lot of output, there is no request body at all (i.e., it is a GET, not a POST). [1] http://article.gmane.org/gmane.comp.version-control.git/269020 Test-adapted-from: Dennis Kaarsemaker <dennis@kaarsemaker.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 26 May 2015, 03:43:18 UTC
d201a1e Jeff King 22 May 2015, 00:53:36 UTC test_bitmap_walk: free bitmap with bitmap_free Commit f86a374 (pack-bitmap.c: fix a memleak, 2015-03-30) noticed that we leak the "result" bitmap. But we should use "bitmap_free" rather than straight "free", as the former remembers to free the bitmap array pointed to by the struct. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 May 2015, 16:03:04 UTC
bbf431c Patrick Steinhardt 22 May 2015, 06:22:04 UTC doc: fix inconsistent spelling of "packfile" Fix remaining instances where "pack-file" is used instead of "packfile". Some places remain where we still use "pack-file", This is the case when we explicitly refer to a file with a ".pack" extension as opposed to a data source providing a pack data stream. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 May 2015, 16:00:17 UTC
141ff8f Junio C Hamano 22 May 2015, 15:41:31 UTC t5407: use <<- to align the expected output Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 May 2015, 15:41:31 UTC
b12d3e9 Matthieu Moy 22 May 2015, 13:15:49 UTC rebase -i: fix post-rewrite hook with failed exec command Usually, when 'git rebase' stops before completing the rebase, it is to give the user an opportunity to edit a commit (e.g. with the 'edit' command). In such cases, 'git rebase' leaves the sha1 of the commit being rewritten in "$state_dir"/stopped-sha, and subsequent 'git rebase --continue' will call the post-rewrite hook with this sha1 as <old-sha1> argument to the post-rewrite hook. The case of 'git rebase' stopping because of a failed 'exec' command is different: it gives the opportunity to the user to examine or fix the failure, but does not stop saying "here's a commit to edit, use --continue when you're done". So, there's no reason to call the post-rewrite hook for 'exec' commands. If the user did rewrite the commit, it would be with 'git commit --amend' which already called the post-rewrite hook. Fix the behavior to leave no stopped-sha file in case of failed exec command, and teach 'git rebase --continue' to skip record_in_rewritten if no stopped-sha file is found. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 May 2015, 15:39:02 UTC
1d968ca Matthieu Moy 22 May 2015, 13:15:50 UTC rebase -i: demonstrate incorrect behavior of post-rewrite The 'exec' command is sending the current commit to stopped-sha, which is supposed to contain the original commit (before rebase). As a result, if an 'exec' command fails, the next 'git rebase --continue' will send the current commit as <old-sha1> to the post-rewrite hook. The test currently fails with : --- expected.data 2015-05-21 17:55:29.000000000 +0000 +++ [...]post-rewrite.data 2015-05-21 17:55:29.000000000 +0000 @@ -1,2 +1,3 @@ 2362ae8e1b1b865e6161e6f0e165ffb974abf018 488028e9fac0b598b70cbeb594258a917e3f6fab +488028e9fac0b598b70cbeb594258a917e3f6fab 488028e9fac0b598b70cbeb594258a917e3f6fab babc8a4c7470895886fc129f1a015c486d05a351 8edffcc4e69a4e696a1d4bab047df450caf99507 Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 May 2015, 15:39:01 UTC
92de921 Matthieu Moy 18 May 2015, 17:55:58 UTC Documentation/log: clarify sha1 non-abbreviation in log --raw Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2015, 22:28:51 UTC
22570b6 René Scharfe 19 May 2015, 22:13:33 UTC dir: remove unused variable sb It had never been used. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2015, 20:50:22 UTC
5cd83e1 René Scharfe 19 May 2015, 22:13:26 UTC clean: remove unused variable buf It had never been used. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2015, 20:50:21 UTC
dbe44fa René Scharfe 19 May 2015, 21:44:23 UTC use file_exists() to check if a file exists in the worktree Call file_exists() instead of open-coding it. That's shorter, simpler and the intent becomes clearer. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2015, 20:49:10 UTC
5ba2831 Jeff King 20 May 2015, 18:17:46 UTC stash: recognize "--help" for subcommands If you run "git stash --help", you get the help for stash (this magic is done by the git wrapper itself). But if you run "git stash drop --help", you get an error. We cannot show help specific to "stash drop", of course, but we can at least give the user the normal stash manpage. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2015, 20:47:41 UTC
d6cc2df Jeff King 20 May 2015, 18:01:32 UTC stash: complain about unknown flags The option parser for git-stash stuffs unknown flags into the $FLAGS variable, where they can be accessed by the individual commands. However, most commands do not even look at these extra flags, leading to unexpected results like this: $ git stash drop --help Dropped refs/stash@{0} (e6cf6d80faf92bb7828f7b60c47fc61c03bd30a1) We should notice the extra flags and bail. Rather than annotate each command to reject a non-empty $FLAGS variable, we can notice that "stash show" is the only command that actually _wants_ arbitrary flags. So we switch the default mode to reject unknown flags, and let stash_show() opt into the feature. Reported-by: Vincent Legoll <vincent.legoll@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2015, 20:47:30 UTC
cc969c8 Jeff King 20 May 2015, 07:36:43 UTC t5551: factor out tag creation One of our tests in t5551 creates a large number of tags, and jumps through some hoops to do it efficiently. Let's factor that out into a function so we can make other similar tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2015, 17:38:31 UTC
5c2a581 Michael Coleman 20 May 2015, 02:41:17 UTC Documentation/git-commit: grammofix Signed-off-by: Michael Coleman <michael.karl.coleman@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 May 2015, 04:20:58 UTC
599dc76 René Scharfe 18 May 2015, 23:24:09 UTC pack-bitmaps: plug memory leak, fix allocation size for recent_bitmaps Use an automatic variable for recent_bitmaps, an array of pointers. This way we don't allocate too much and don't have to free the memory at the end. The old code over-allocated because it reserved enough memory to store all of the structs it is only pointing to and never freed it. 160 64-bit pointers take up 1280 bytes, which is not too much to be placed on the stack. MAX_XOR_OFFSET is turned into a preprocessor constant to make it constant enough for use in an non-variable array declaration. Noticed-by: Stefan Beller <stefanbeller@gmail.com> Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 May 2015, 16:31:09 UTC
822f0c4 Mike Hommey 12 May 2015, 04:30:16 UTC clone: call transport_set_verbosity before anything else on the newly created transport Commit 2879bc3 made the progress and verbosity options sent to remote helper earlier than they previously were. But nothing else after that would send updates if the value is changed later on with transport_set_verbosity. While for fetch and push, transport_set_verbosity is the first thing that is done after creating the transport, it was not the case for clone. So commit 2879bc3 broke changing progress and verbosity for clone, for urls requiring a remote helper only (so, not git:// urls, for instance). Moving transport_set_verbosity to just after the transport is created works around the issue. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 May 2015, 16:05:55 UTC
66d2e04 Stefan Beller 18 May 2015, 21:10:26 UTC subdirectory tests: code cleanup, uncomment test Back when these tests were written, we wanted to make sure that Git notices it is in a bare repository and "git show -s HEAD" would refrain from complaining that HEAD might mean a file it sees in its current working directory (because it does not). But the version of Git back then didn't behave well, without (doubly) being told that it is inside a bare repository by exporting "GIT_DIR=.". The form of the test we originally wanted to have was left commented out as a reminder. Nowadays the test as originally intended works, so add it to the test suite. We'll keep the old test that explicitly sets GIT_DIR=. to make sure that use case will not regress. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 May 2015, 22:22:49 UTC
838d6a9 David Turner 18 May 2015, 18:08:46 UTC clean: only lstat files in pathspec Even though "git clean" takes pathspec to limit the part of the working tree to be cleaned, it checked the paths it encounters during its directory traversal with lstat(2), before checking if the path is within the pathspec. Ignore paths outside pathspec and proceed without checking with lstat(2). Even if such a path is unreadable due to e.g. EPERM, "git clean" should not care. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 May 2015, 21:04:15 UTC
d89df36 Matthieu Moy 18 May 2015, 17:55:57 UTC Documentation/log: clarify what --raw means There are several "raw formats", and describing --raw as "Generate the raw format" in the documentation for git-log seems to imply that it generates the raw *log* format. Clarify the wording by saying "raw diff format" explicitly, and make a special-case for "git log": "git log --raw" does not just change the format, it shows something which is not shown by default. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 May 2015, 20:42:52 UTC
db9bb28 Paul Tan 18 May 2015, 13:45:42 UTC pull: parse pull.ff as a bool or string Since b814da8 (pull: add pull.ff configuration, 2014-01-15) git-pull supported setting --(no-)ff via the pull.ff configuration value. However, as it only matches the string values of "true" and "false", it does not support other boolean aliases such as "on", "off", "1", "0". This is inconsistent with the merge.ff setting, which supports these aliases. Fix this by using the bool_or_string_config function to retrieve the value of pull.ff. Signed-off-by: Paul Tan <pyokagan@gmail.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 May 2015, 18:22:38 UTC
eb8dc05 Paul Tan 18 May 2015, 13:45:41 UTC pull: make pull.ff=true override merge.ff Since b814da8 (pull: add pull.ff configuration, 2014-01-15), running git-pull with the configuration pull.ff=false or pull.ff=only is equivalent to passing --no-ff and --ff-only to git-merge. However, if pull.ff=true, no switch is passed to git-merge. This leads to the confusing behavior where pull.ff=false or pull.ff=only is able to override merge.ff, while pull.ff=true is unable to. Fix this by adding the --ff switch if pull.ff=true, and add a test to catch future regressions. Furthermore, clarify in the documentation that pull.ff overrides merge.ff. Signed-off-by: Paul Tan <pyokagan@gmail.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 May 2015, 18:22:27 UTC
5061a44 Paul Tan 18 May 2015, 13:39:56 UTC pull: handle --log=<n> Since efb779f (merge, pull: add '--(no-)log' command line option, 2008-04-06) git-pull supported the (--no-)log switch and would pass it to git-merge. 96e9420 (merge: Make '--log' an integer option for number of shortlog entries, 2010-09-08) implemented support for the --log=<n> switch, which would explicitly set the number of shortlog entries. However, git-pull does not recognize this option, and will instead pass it to git-fetch, leading to "unknown option" errors. Fix this by matching --log=* in addition to --log and --no-log. Implement a test for this use case. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 May 2015, 18:19:36 UTC
f6a1e1e Jim Hill 18 May 2015, 00:41:45 UTC sha1_file: pass empty buffer to index empty file `git add` of an empty file with a filter pops complaints from `copy_fd` about a bad file descriptor. This traces back to these lines in sha1_file.c:index_core: if (!size) { ret = index_mem(sha1, NULL, size, type, path, flags); The problem here is that content to be added to the index can be supplied from an fd, or from a memory buffer, or from a pathname. This call is supplying a NULL buffer pointer and a zero size. Downstream logic takes the complete absence of a buffer to mean the data is to be found elsewhere -- for instance, these, from convert.c: if (params->src) { write_err = (write_in_full(child_process.in, params->src, params->size) < 0); } else { write_err = copy_fd(params->fd, child_process.in); } ~If there's a buffer, write from that, otherwise the data must be coming from an open fd.~ Perfectly reasonable logic in a routine that's going to write from either a buffer or an fd. So change `index_core` to supply an empty buffer when indexing an empty file. There's a patch out there that instead changes the logic quoted above to take a `-1` fd to mean "use the buffer", but it seems to me that the distinction between a missing buffer and an empty one carries intrinsic semantics, where the logic change is adapting the code to handle incorrect arguments. Signed-off-by: Jim Hill <gjthill@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 May 2015, 17:15:20 UTC
3890dae Patrick Steinhardt 17 May 2015, 06:56:54 UTC pack-protocol.txt: fix insconsistent spelling of "packfile" Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 May 2015, 18:25:00 UTC
4667391 Patrick Steinhardt 17 May 2015, 06:56:53 UTC git-unpack-objects.txt: fix inconsistent spelling of "packfile" Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 May 2015, 18:24:58 UTC
d017a45 Patrick Steinhardt 17 May 2015, 06:56:52 UTC git-verify-pack.txt: fix inconsistent spelling of "packfile" Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 May 2015, 18:24:57 UTC
7253a02 Jeff King 15 May 2015, 06:29:27 UTC http-backend: fix die recursion with custom handler When we die() in http-backend, we call a custom handler that writes an HTTP 500 response to stdout, then reports the error to stderr. Our routines for writing out the HTTP response may themselves die, leading to us entering die() again. When it was originally written, that was OK; our custom handler keeps a variable to notice this and does not recurse. However, since cd163d4 (usage.c: detect recursion in die routines and bail out immediately, 2012-11-14), the main die() implementation detects recursion before we even get to our custom handler, and bails without printing anything useful. We can handle this case by doing two things: 1. Installing a custom die_is_recursing handler that allows us to enter up to one level of recursion. Only the first call to our custom handler will try to write out the error response. So if we die again, that is OK. If we end up dying more than that, it is a sign that we are in an infinite recursion. 2. Reporting the error to stderr before trying to write out the HTTP response. In the current code, if we do die() trying to write out the response, we'll exit immediately from this second die(), and never get a chance to output the original error (which is almost certainly the more interesting one; the second die is just going to be along the lines of "I tried to write to stdout but it was closed"). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 May 2015, 18:13:47 UTC
0544574 Jeff King 14 May 2015, 19:20:52 UTC rerere: exit silently on "forget" when rerere is disabled If you run "git rerere forget foo" in a repository that does not have rerere enabled, git hits an internal error: $ git init -q $ git rerere forget foo fatal: BUG: attempt to commit unlocked object The problem is that setup_rerere() will not actually take the lock if the rerere system is disabled. We should notice this and return early. We can return with a success code here, because we know there is nothing to forget. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 May 2015, 19:33:15 UTC
19d122b Paul Tan 13 May 2015, 10:06:47 UTC pull: remove --tags error in no merge candidates case Since 441ed41 ("git pull --tags": error out with a better message., 2007-12-28), git pull --tags would print a different error message if git-fetch did not return any merge candidates: It doesn't make sense to pull all tags; you probably meant: git fetch --tags This is because at that time, git-fetch --tags would override any configured refspecs, and thus there would be no merge candidates. The error message was thus introduced to prevent confusion. However, since c5a84e9 (fetch --tags: fetch tags *in addition to* other stuff, 2013-10-30), git fetch --tags would fetch tags in addition to any configured refspecs. Hence, if any no merge candidates situation occurs, it is not because --tags was set. As such, this special error message is now irrelevant. To prevent confusion, remove this error message. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 May 2015, 16:52:51 UTC
d0258b9 Jeff King 14 May 2015, 04:34:48 UTC doc: convert AsciiDoc {?foo} to ifdef::foo[] The former seems to just be syntactic sugar for the latter. And as it's sugar that AsciiDoctor doesn't understand, it would be nice to avoid it. Since there are only two spots, and the resulting source is not significantly harder to read, it's worth doing. Note that this does slightly affect the generated HTML (it has an extra newline), but the rendered result for both HTML and docbook should be the same (since the newline is not syntactically significant there). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 May 2015, 16:38:29 UTC
aaa7e0d Junio C Hamano 13 May 2015, 21:11:43 UTC Git 2.4.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 May 2015, 21:11:43 UTC
a379f25 Junio C Hamano 13 May 2015, 21:05:56 UTC Merge branch 'sb/line-log-plug-pairdiff-leak' into maint * sb/line-log-plug-pairdiff-leak: line-log.c: fix a memleak 13 May 2015, 21:05:56 UTC
back to top