aboutsummaryrefslogtreecommitdiffstats
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2018-02-13Merge branch 'jk/daemon-fixes'Junio C Hamano3-11/+101
Assorted fixes to "git daemon". * jk/daemon-fixes: daemon: fix length computation in newline stripping t/lib-git-daemon: add network-protocol helpers daemon: handle NULs in extended attribute string daemon: fix off-by-one in logging extended attributes t/lib-git-daemon: record daemon log t5570: use ls-remote instead of clone for interp tests
2018-02-13Merge branch 'pw/sequencer-in-process-commit'Junio C Hamano6-9/+176
The sequencer infrastructure is shared across "git cherry-pick", "git rebase -i", etc., and has always spawned "git commit" when it needs to create a commit. It has been taught to do so internally, when able, by reusing the codepath "git commit" itself uses, which gives performance boost for a few tens of percents in some sample scenarios. * pw/sequencer-in-process-commit: sequencer: run 'prepare-commit-msg' hook t7505: add tests for cherry-pick and rebase -i/-p t7505: style fixes sequencer: assign only free()able strings to gpg_sign sequencer: improve config handling t3512/t3513: remove KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1 sequencer: try to commit without forking 'git commit' sequencer: load commit related config sequencer: simplify adding Signed-off-by: trailer commit: move print_commit_summary() to libgit commit: move post-rewrite code to libgit Add a function to update HEAD after creating a commit commit: move empty message checks to libgit t3404: check intermediate squash messages
2018-02-13Merge branch 'nd/shared-index-fix'Junio C Hamano1-0/+19
Code clean-up. * nd/shared-index-fix: read-cache: don't write index twice if we can't write shared index read-cache.c: move tempfile creation/cleanup out of write_shared_index read-cache.c: change type of "temp" in write_shared_index()
2018-02-13Merge branch 'tg/split-index-fixes'Junio C Hamano1-0/+19
The split-index mode had a few corner case bugs fixed. * tg/split-index-fixes: travis: run tests with GIT_TEST_SPLIT_INDEX split-index: don't write cache tree with null oid entries read-cache: fix reading the shared index for other repos
2018-02-13Merge branch 'jt/http-redact-cookies'Junio C Hamano1-0/+33
The http tracing code, often used to debug connection issues, learned to redact potentially sensitive information from its output so that it can be more safely sharable. * jt/http-redact-cookies: http: support omitting data from traces http: support cookie redaction when tracing
2018-02-13Merge branch 'nd/trace-with-env'Junio C Hamano2-0/+46
The tracing machinery learned to report tweaking of environment variables as well. * nd/trace-with-env: run-command.c: print new cwd in trace_run_command() run-command.c: print env vars in trace_run_command() run-command.c: print program 'git' when tracing git_cmd mode run-command.c: introduce trace_run_command() trace.c: move strbuf_release() out of print_trace_line() trace: avoid unnecessary quoting sq_quote_argv: drop maxlen parameter
2018-02-13Merge branch 'cl/t9001-cleanup'Junio C Hamano1-10/+7
Test clean-up. * cl/t9001-cleanup: t9001: use existing helper in send-email test
2018-02-13Merge branch 'jh/partial-clone'Junio C Hamano3-0/+310
The machinery to clone & fetch, which in turn involves packing and unpacking objects, have been told how to omit certain objects using the filtering mechanism introduced by the jh/object-filtering topic, and also mark the resulting pack as a promisor pack to tolerate missing objects, taking advantage of the mechanism introduced by the jh/fsck-promisors topic. * jh/partial-clone: t5616: test bulk prefetch after partial fetch fetch: inherit filter-spec from partial clone t5616: end-to-end tests for partial clone fetch-pack: restore save_commit_buffer after use unpack-trees: batch fetching of missing blobs clone: partial clone partial-clone: define partial clone settings in config fetch: support filters fetch: refactor calculation of remote list fetch-pack: test support excluding large blobs fetch-pack: add --no-filter fetch-pack, index-pack, transport: partial clone upload-pack: add object filtering for partial clone
2018-02-13Merge branch 'jh/fsck-promisors'Junio C Hamano1-0/+343
In preparation for implementing narrow/partial clone, the machinery for checking object connectivity used by gc and fsck has been taught that a missing object is OK when it is referenced by a packfile specially marked as coming from trusted repository that promises to make them available on-demand and lazily. * jh/fsck-promisors: gc: do not repack promisor packfiles rev-list: support termination at promisor objects sha1_file: support lazily fetching missing objects introduce fetch-object: fetch one promisor object index-pack: refactor writing of .keep files fsck: support promisor objects as CLI argument fsck: support referenced promisor objects fsck: support refs pointing to promisor objects fsck: introduce partialclone extension extension.partialclone: introduce partial clone extension
2018-02-13Merge branch 'ab/simplify-perl-makefile'Junio C Hamano2-2/+2
The build procedure for perl/ part has been greatly simplified by weaning ourselves off of MakeMaker. * ab/simplify-perl-makefile: perl: treat PERLLIB_EXTRA as an extra path again perl: avoid *.pmc and fix Error.pm further Makefile: replace perl/Makefile.PL with simple make rules
2018-01-25daemon: fix length computation in newline strippingJeff King1-0/+15
When git-daemon gets a pktline request, we strip off any trailing newline, replacing it with a NUL. Clients prior to 5ad312bede (in git v1.4.0) would send: git-upload-pack repo.git\n and we need to strip it off to understand their request. After 5ad312bede, we send the host attribute but no newline, like: git-upload-pack repo.git\0host=example.com\0 Both of these are parsed correctly by git-daemon. But if some client were to combine the two: git-upload-pack repo.git\n\0host=example.com\0 we don't parse it correctly. The problem is that we use the "len" variable to record the position of the NUL separator, but then decrement it when we strip the newline. So we start with: git-upload-pack repo.git\n\0host=example.com\0 ^-- len and end up with: git-upload-pack repo.git\0\0host=example.com\0 ^-- len This is arguably correct, since "len" tells us the length of the initial string, but we don't actually use it for that. What we do use it for is finding the offset of the extended attributes; they used to be at len+1, but are now at len+2. We can solve that by just leaving "len" where it is. We don't have to care about the length of the shortened string, since we just treat it like a C string. No version of Git ever produced such a string, but it seems like the daemon code meant to handle this case (and it seems like a reasonable thing for somebody to do in a 3rd-party implementation). Reported-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25t/lib-git-daemon: add network-protocol helpersJeff King2-1/+58
All of our git-protocol tests rely on invoking the client and having it make a request of a server. That gives a nice real-world test of how the two behave together, but it doesn't leave any room for testing how a server might react to _other_ clients. Let's add a few test helper functions which can be used to manually conduct a git-protocol conversation with a remote git-daemon: 1. To connect to a remote git-daemon, we need something like "netcat". But not everybody will have netcat. And even if they do, the behavior with respect to half-duplex shutdowns is not portable (openbsd netcat has "-N", with others you must rely on "-q 1", which is racy). Here we provide a "fake_nc" that is capable of doing a client-side netcat, with sane half-duplex semantics. It relies on perl's IO::Socket::INET. That's been in the base distribution since 5.6.0, so it's probably available everywhere. But just to be on the safe side, we'll add a prereq. 2. To help tests speak and read pktline, this patch adds packetize() and depacketize() functions. I've put fake_nc() into lib-git-daemon.sh, since that's really the only server where we'd need to use a network socket. Whereas the pktline helpers may be of more general use, so I've added them to test-lib-functions.sh. Programs like upload-pack speak pktline, but can talk directly over stdio without a network socket. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25daemon: handle NULs in extended attribute stringJeff King1-3/+5
If we receive a request with extended attributes after the NUL, we try to write those attributes to the log. We do so with a "%s" format specifier, which will only show characters up to the first NUL. That's enough for printing a "host=" specifier. But since dfe422d04d (daemon: recognize hidden request arguments, 2017-10-16) we may have another NUL, followed by protocol parameters, and those are not logged at all. Let's cut out the attempt to show the whole string, and instead log when we parse individual attributes. We could leave the "extended attributes (%d bytes) exist" part of the log, which in theory could alert us to attributes that fail to parse. But anything we don't parse as a "host=" parameter gets blindly added to the "protocol" attribute, so we'd see it in that part of the log. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25daemon: fix off-by-one in logging extended attributesJeff King1-0/+11
If receive a request like: git-upload-pack /foo.git\0host=localhost we mark the offset of the NUL byte as "len", and then log the bytes after the NUL with a "%.*s" placeholder, using "pktlen - len" as the length, and "line + len + 1" as the start of the string. This is off-by-one, since the start of the string skips past the separating NUL byte, but the adjusted length includes it. Fortunately this doesn't actually read past the end of the buffer, since "%.*s" will stop when it hits a NUL. And regardless of what is in the buffer, packet_read() will always add an extra NUL terminator for safety. As an aside, the git.git client sends an extra NUL after a "host" field, too, so we'd generally hit that one first, not the one added by packet_read(). You can see this in the test output which reports 15 bytes, even though the string has only 14 bytes of visible data. But the point is that even a client sending unusual data could not get us to read past the end of the buffer, so this is purely a cosmetic fix. Reported-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25t/lib-git-daemon: record daemon logJeff King1-4/+12
When we start git-daemon for our tests, we send its stderr log stream to a named pipe. We synchronously read the first line to make sure that the daemon started, and then dump the rest to descriptor 4. This is handy for debugging test output with "--verbose", but the tests themselves can't access the log data. Let's dump the log into a file, as well, so that future tests can check the log. There are a few subtleties worth calling out here: - we'll continue to send output to descriptor 4 for viewing/debugging, which would imply swapping out "cat" for "tee". But we want to ensure that there's no buffering, and "tee" doesn't have a standard way to ask for that. So we'll use a shell loop around "read" and "printf" instead. That ensures that after a request has been served, the matching log entries will have made it to the file. - the existing first-line shell loop used read/echo. We'll switch to consistently using "read -r" and "printf" to relay data as faithfully as possible. - we open the logfile for append, rather than just output. That makes it OK for tests to truncate the logfile without restarting the daemon (the OS will atomically seek to the end of the file when outputting each line). That allows tests to look at the log without worrying about pollution from earlier tests. Helped-by: Lucas Werkmeister <mail@lucaswerkmeister.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25t5570: use ls-remote instead of clone for interp testsJeff King1-6/+3
We don't actually care about the clone operation here; we just want to know if we were able to actually contact the remote repository. Using ls-remote does that more efficiently, and without us having to worry about managing the tmp.git directory. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-24sequencer: run 'prepare-commit-msg' hookPhillip Wood1-4/+4
Commit 356ee4659b ("sequencer: try to commit without forking 'git commit'", 2017-11-24) forgot to run the 'prepare-commit-msg' hook when creating the commit. Fix this by writing the commit message to a different file and running the hook. Using a different file means that if the commit is cancelled the original message file is unchanged. Also move the checks for an empty commit so the order matches 'git commit'. Reported-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-24t7505: add tests for cherry-pick and rebase -i/-pPhillip Wood3-4/+157
Check that cherry-pick and rebase call the 'prepare-commit-msg' hook correctly. The expected values for the hook arguments are taken to match the current master branch. I think there is scope for improving the arguments passed so they make a bit more sense - for instance cherry-pick currently passes different arguments depending on whether the commit message is being edited. Also the arguments for rebase could be improved. Commit 7c4188360ac ("rebase -i: proper prepare-commit-msg hook argument when squashing", 2008-10-3) apparently changed things so that when squashing rebase would pass 'squash' as the argument to the hook but that has been lost. I think that it would make more sense to pass 'message' for revert and cherry-pick -x/-s (i.e. cases where there is a new message or the current message in modified by the command), 'squash' when squashing with a new message and 'commit HEAD/CHERRY_PICK_HEAD' otherwise (picking and squashing without a new message). Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-24t7505: style fixesPhillip Wood1-6/+8
Fix the indentation and style of the hook script in preparation for further changes. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-24read-cache: don't write index twice if we can't write shared indexNguyễn Thái Ngọc Duy1-0/+19
In a0a967568e ("update-index --split-index: do not split if $GIT_DIR is read only", 2014-06-13), we tried to make sure we can still write an index, even if the shared index can not be written. We did so by just calling 'do_write_locked_index()' just before 'write_shared_index()'. 'do_write_locked_index()' always at least closes the tempfile nowadays, and used to close or commit the lockfile if COMMIT_LOCK or CLOSE_LOCK were given at the time this feature was introduced. COMMIT_LOCK or CLOSE_LOCK is passed in by most callers of 'write_locked_index()'. After calling 'write_shared_index()', we call 'write_split_index()', which calls 'do_write_locked_index()' again, which then tries to use the closed lockfile again, but in fact fails to do so as it's already closed. This eventually leads to a segfault. Make sure to write the main index only once. [nd: most of the commit message and investigation done by Thomas, I only tweaked the solution a bit] Helped-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-23Merge branch 'nd/add-i-ignore-submodules'Junio C Hamano1-0/+48
"git add -p" was taught to ignore local changes to submodules as they do not interfere with the partial addition of regular changes anyway. * nd/add-i-ignore-submodules: add--interactive: ignore submodule changes except HEAD
2018-01-23Merge branch 'mm/send-email-fallback-to-local-mail-address'Junio C Hamano3-94/+19
Instead of maintaining home-grown email address parsing code, ship a copy of reasonably recent Mail::Address to be used as a fallback in 'git send-email' when the platform lacks it. * mm/send-email-fallback-to-local-mail-address: send-email: add test for Linux's get_maintainer.pl perl/Git: remove now useless email-address parsing code send-email: add and use a local copy of Mail::Address
2018-01-23Merge branch 'tg/stash-with-pathspec-fix'Junio C Hamano1-0/+32
"git stash -- <pathspec>" incorrectly blew away untracked files in the directory that matched the pathspec, which has been corrected. * tg/stash-with-pathspec-fix: stash: don't delete untracked files that match pathspec
2018-01-23Merge branch 'sb/submodule-update-reset-fix'Junio C Hamano1-2/+17
When resetting the working tree files recursively, the working tree of submodules are now also reset to match. * sb/submodule-update-reset-fix: submodule: submodule_move_head omits old argument in forced case unpack-trees: oneway_merge to update submodules t/lib-submodule-update.sh: fix test ignoring ignored files in submodules t/lib-submodule-update.sh: clarify test
2018-01-23Merge branch 'ab/commit-m-with-fixup'Junio C Hamano1-1/+8
"git commit --fixup" did not allow "-m<message>" option to be used at the same time; allow it to annotate resulting commit with more text. * ab/commit-m-with-fixup: commit: add support for --fixup <commit> -m"<extra message>" commit doc: document that -c, -C, -F and --fixup with -m error
2018-01-23Merge branch 'cc/codespeed'Junio C Hamano2-54/+137
"perf" test output can be sent to codespeed server. * cc/codespeed: perf/run: read GIT_PERF_REPO_NAME from perf.repoName perf/run: learn to send output to codespeed server perf/run: learn about perf.codespeedOutput perf/run: add conf_opts argument to get_var_from_env_or_config() perf/aggregate: implement codespeed JSON output perf/aggregate: refactor printing results perf/aggregate: fix checking ENV{GIT_PERF_SUBSECTION}
2018-01-23Merge branch 'ab/perf-grep-threads'Junio C Hamano2-21/+86
More perf tests for threaded grep * ab/perf-grep-threads: perf: amend the grep tests to test grep.threads
2018-01-23Merge branch 'sb/diff-blobfind-pickaxe'Junio C Hamano1-0/+68
"diff" family of commands learned "--find-object=<object-id>" option to limit the findings to changes that involve the named object. * sb/diff-blobfind-pickaxe: diff: use HAS_MULTI_BITS instead of counting bits manually diff: properly error out when combining multiple pickaxe options diffcore: add a pickaxe option to find a specific blob diff: introduce DIFF_PICKAXE_KINDS_MASK diff: migrate diff_flags.pickaxe_ignore_case to a pickaxe_opts bit diff.h: make pickaxe_opts an unsigned bit field
2018-01-23Merge branch 'jk/abort-clone-with-existing-dest'Junio C Hamano1-26/+74
"git clone $there $here" is allowed even when here directory exists as long as it is an empty directory, but the command incorrectly removed it upon a failure of the operation. * jk/abort-clone-with-existing-dest: clone: do not clean up directories we didn't create clone: factor out dir_exists() helper t5600: modernize style t5600: fix outdated comment about unborn HEAD
2018-01-23Merge branch 'jc/merge-symlink-ours-theirs'Junio C Hamano1-0/+32
"git merge -Xours/-Xtheirs" learned to use our/their version when resolving a conflicting updates to a symbolic link. * jc/merge-symlink-ours-theirs: merge: teach -Xours/-Xtheirs to symbolic link merge
2018-01-23Merge branch 'nd/ita-wt-renames-in-status'Junio C Hamano1-0/+72
"git status" after moving a path in the working tree (hence making it appear "removed") and then adding with the -N option (hence making that appear "added") detected it as a rename, but did not report the old and new pathnames correctly. * nd/ita-wt-renames-in-status: wt-status.c: handle worktree renames wt-status.c: rename rename-related fields in wt_status_change_data wt-status.c: catch unhandled diff status codes wt-status.c: coding style fix Use DIFF_DETECT_RENAME for detect_rename assignments t2203: test status output with porcelain v2 format
2018-01-23Merge branch 'dk/describe-all-output-fix'Junio C Hamano1-1/+5
An old regression in "git describe --all $annotated_tag^0" has been fixed. * dk/describe-all-output-fix: describe: prepend "tags/" when describing tags with embedded name
2018-01-21Merge branch 'bc/hash-algo' into maintJunio C Hamano1-0/+17
* bc/hash-algo: t5601-clone: test case-conflicting files on case-insensitive filesystem repository: pre-initialize hash algo pointer
2018-01-21t5601-clone: test case-conflicting files on case-insensitive filesystemEric Sunshine1-0/+17
A recently introduced regression caused a segfault at clone time on case-insensitive filesystems when filenames differing only in case are present. This bug has already been fixed (repository: pre-initialize hash algo pointer, 2018-01-18), but it's not the first time similar problems have arisen. Therefore, introduce a test to catch this case and protect against future regressions. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-19http: support omitting data from tracesJonathan Tan1-0/+12
GIT_TRACE_CURL provides a way to debug what is being sent and received over HTTP, with automatic redaction of sensitive information. But it also logs data transmissions, which significantly increases the log file size, sometimes unnecessarily. Add an option "GIT_TRACE_CURL_NO_DATA" to allow the user to omit such data transmissions. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-19http: support cookie redaction when tracingJonathan Tan1-0/+21
When using GIT_TRACE_CURL, Git already redacts the "Authorization:" and "Proxy-Authorization:" HTTP headers. Extend this redaction to a user-specified list of cookies, specified through the "GIT_REDACT_COOKIES" environment variable. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-19run-command.c: print env vars in trace_run_command()Nguyễn Thái Ngọc Duy2-0/+46
Occasionally submodule code could execute new commands with GIT_DIR set to some submodule. GIT_TRACE prints just the command line which makes it hard to tell that it's not really executed on this repository. Print the env delta (compared to parent environment) in this case. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-19split-index: don't write cache tree with null oid entriesThomas Gummerer1-0/+19
In a96d3cc3f6 ("cache-tree: reject entries with null sha1", 2017-04-21) we made sure that broken cache entries do not get propagated to new trees. Part of that was making sure not to re-use an existing cache tree that includes a null oid. It did so by dropping the cache tree in 'do_write_index()' if one of the entries contains a null oid. In split index mode however, there are two invocations to 'do_write_index()', one for the shared index and one for the split index. The cache tree is only written once, to the split index. As we only loop through the elements that are effectively being written by the current invocation, that may not include the entry with a null oid in the split index (when it is already written to the shared index), where we write the cache tree. Therefore in split index mode we may still end up writing the cache tree, even though there is an entry with a null oid in the index. Fix this by checking for null oids in prepare_to_write_split_index, where we loop the entries of the shared index as well as the entries for the split index. This fixes t7009 with GIT_TEST_SPLIT_INDEX. Also add a new test that's more specifically showing the problem. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-16add--interactive: ignore submodule changes except HEADNguyễn Thái Ngọc Duy1-0/+48
For 'add -i' and 'add -p', the only action we can take on a dirty submodule entry is update the index with a new value from its HEAD. The content changes inside (from its own index, untracked files...) do not matter, at least until 'git add -i' learns about launching a new interactive add session inside a submodule. Ignore all other submodules changes except HEAD. This reduces the number of entries the user has to check through in 'git add -i', and the number of 'no' they have to answer to 'git add -p' when dirty submodules are present. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-12t9001: use existing helper in send-email testChristian Ludwig1-10/+7
Use the wrapper function around the sed statement like everywhere else in the test. Unfortunately the wrapper function is defined pretty late. Move the wrapper to the top of the test file, so future users have it available right away. Signed-off-by: Christian Ludwig <chrissicool@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-11Merge branch 'js/test-with-ws-in-path'Junio C Hamano1-4/+4
Hot fix to a test. * js/test-with-ws-in-path: t3900: add some more quotes
2018-01-10t3900: add some more quotesBeat Bolli1-4/+4
In 89a70b80 ("t0302 & t3900: add forgotten quotes", 2018-01-03), quotes were added to protect against spaces in $HOME. In the test_when_finished command, two files are deleted which must be quoted individually. [jc: with \$HOME in the test_when_finished command quoted, as pointed out by j6t]. Signed-off-by: Beat Bolli <dev+git@drbeat.li> Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-10Merge branch 'js/perl-path-workaround-in-tests'Junio C Hamano1-1/+16
* js/perl-path-workaround-in-tests: mingw: handle GITPERLLIB in t0021 in a Windows-compatible way
2018-01-10Merge branch 'ew/empty-merge-with-dirty-index'Junio C Hamano1-0/+50
"git merge -s recursive" did not correctly abort when the index is dirty, if the merged tree happened to be the same as the current HEAD, which has been fixed. * ew/empty-merge-with-dirty-index: merge-recursive: do not look at the index during recursive merge
2018-01-10Merge branch 'js/fix-merge-arg-quoting-in-rebase-p'Junio C Hamano1-0/+14
"git rebase -p -X<option>" did not propagate the option properly down to underlying merge strategy backend. * js/fix-merge-arg-quoting-in-rebase-p: rebase -p: fix quoting when calling `git merge`
2018-01-10mingw: handle GITPERLLIB in t0021 in a Windows-compatible wayJohannes Schindelin1-1/+16
Git's assumption that all path lists are colon-separated is not only wrong on Windows, it is not even an assumption that is compatible with POSIX. In the interest of time, let's not try to fix this properly but simply work around the obvious breakage on Windows, where the MSYS2 Bash used by Git for Windows to interpret the Git's Unix shell scripts will automagically convert path lists in the environment to semicolon-separated lists of Windows paths (with drive letter and the corresponding colon and all that jazz). In other words, we simply look whether there is a semicolon in GITPERLLIB and split by semicolons if found instead of colons. This is not fool-proof, of course, as the path list could consist of a single path. But that is not the case in Git for Windows' test suite, there are always two paths in GITPERLLIB. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-09Merge branch 'bw/protocol-v1'Junio C Hamano1-6/+4
Test fix for a topic already in 'master'. * bw/protocol-v1: http: fix v1 protocol tests with apache httpd < 2.4
2018-01-09Merge branch 'js/test-with-ws-in-path'Junio C Hamano5-10/+10
Test fixes. * js/test-with-ws-in-path: t0302 & t3900: add forgotten quotes Allow the test suite to pass in a directory whose name contains spaces
2018-01-09Merge branch 'ew/empty-merge-with-dirty-index-maint' into ↵Junio C Hamano1-0/+50
ew/empty-merge-with-dirty-index * ew/empty-merge-with-dirty-index-maint: merge-recursive: do not look at the index during recursive merge
2018-01-09merge-recursive: do not look at the index during recursive mergeJunio C Hamano1-0/+50
When merging another branch into ours, if their tree is the same as the common ancestor's, we can declare that our tree represents the result of three-way merge. In such a case, the recursive merge backend incorrectly used to create a commit out of our index, even when the index has changes. A recent fix attempted to prevent this by adding a comparison between "our" tree and the index, but forgot that this check must be restricted only to the outermost merge. Inner merges performed by the recursive backend across merge bases are by definition made from scratch without having any local changes added to the index. The call to index_has_changes() during an inner merge is working on the index that has no relation to the merge being performed, preventing legitimate merges from getting carried out. Fix it by limiting the check to the outermost merge. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-08stash: don't delete untracked files that match pathspecThomas Gummerer1-0/+32
Currently when 'git stash push -- <pathspec>' is used, untracked files that match the pathspec will be deleted, even though they do not end up in a stash anywhere. This is because the original commit introducing the pathspec feature in git stash push (df6bba0937 ("stash: teach 'push' (and 'create_stash') to honor pathspec", 2017-02-28)) used the sequence of 'git reset <pathspec> && git ls-files --modified <pathspec> | git checkout-index && git clean <pathspec>'. The intention was to emulate what 'git reset --hard -- <pathspec>' would do. The call to 'git clean' was supposed to clean up the files that were unstaged by 'git reset'. This would work fine if the pathspec doesn't match any files that were untracked before 'git stash push -- <pathspec>'. However if <pathspec> matches a file that was untracked before invoking the 'stash' command, all untracked files matching the pathspec would inadvertently be deleted as well, even though they wouldn't end up in the stash, and are therefore lost. This behaviour was never what was intended, only blobs that also end up in the stash should be reset to their state in HEAD, previously untracked files should be left alone. To achieve this, first match what's in the index and what's in the working tree by adding all changes to the index, ask diff-index what changed between HEAD and the current index, and then apply that patch in reverse to get rid of the changes, which includes removal of added files and resurrection of removed files. Reported-by: Reid Price <reid.price@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-08send-email: add test for Linux's get_maintainer.plAlex Bennée1-0/+19
We had a regression that broke Linux's get_maintainer.pl. Using Mail::Address to parse email addresses fixed it, but let's protect against future regressions. Note that we need --cc-cmd to be relative because this option doesn't accept spaces in script names (probably to allow --cc-cmd="executable --option"), while --smtp-server needs to be absolute. Patch-edited-by: Matthieu Moy <git@matthieu-moy.fr> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Matthieu Moy <git@matthieu-moy.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-08perl/Git: remove now useless email-address parsing codeMatthieu Moy2-94/+0
We now use Mail::Address unconditionaly, hence parse_mailboxes is now dead code. Remove it and its tests. Signed-off-by: Matthieu Moy <git@matthieu-moy.fr> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05Merge branch 'jh/memihash-opt'Junio C Hamano1-1/+1
Squelch compiler warning. * jh/memihash-opt: t/helper/test-lazy-name-hash: fix compilation
2018-01-05Merge branch 'tb/test-lint-wc-l'Junio C Hamano1-0/+1
Test update. * tb/test-lint-wc-l: check-non-portable-shell.pl: `wc -l` may have leading WS
2018-01-05Merge branch 'ld/p4-multiple-shelves'Junio C Hamano1-10/+14
"git p4" update. * ld/p4-multiple-shelves: git-p4: update multiple shelved change lists
2018-01-05Merge branch 'ew/empty-merge-with-dirty-index'Junio C Hamano1-5/+21
"git merge -s recursive" did not correctly abort when the index is dirty, if the merged tree happened to be the same as the current HEAD, which has been fixed. * ew/empty-merge-with-dirty-index: merge-recursive: avoid incorporating uncommitted changes in a merge move index_has_changes() from builtin/am.c to merge.c for reuse t6044: recursive can silently incorporate dirty changes in a merge
2018-01-05Merge branch 'jk/test-suite-tracing'Junio C Hamano3-18/+40
Assorted fixes around running tests with "-x" tracing option. * jk/test-suite-tracing: t/Makefile: introduce TEST_SHELL_PATH test-lib: make "-x" work with "--verbose-log" t5615: avoid re-using descriptor 4 test-lib: silence "-x" cleanup under bash
2018-01-05submodule: submodule_move_head omits old argument in forced caseStefan Beller1-0/+14
When using hard reset or forced checkout with the option to recurse into submodules, the submodules need to be reset, too. It turns out that we need to omit the duplicate old argument to read-tree in all forced cases to omit the 2 way merge and use the more assertive behavior of reading the specific new tree into the index and updating the working tree. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05t/lib-submodule-update.sh: fix test ignoring ignored files in submodulesStefan Beller1-0/+1
It turns out that the test replacing a submodule with a file with the submodule containing an ignored file is incorrectly titled, because the test put the file in place, but never ignored that file. When having an untracked file Instead of an ignored file in the submodule, git should refuse to remove the submodule, but that is a bug in the implementation of recursing into submodules, such that the test just passed, removing the untracked file. Fix the test first; in a later patch we'll fix gits behavior, that will make sure untracked files are not deleted. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05t/lib-submodule-update.sh: clarify testStefan Beller1-2/+2
Keep the local branch name as the upstream branch name to avoid confusion. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05perf/run: read GIT_PERF_REPO_NAME from perf.repoNameChristian Couder1-0/+3
The GIT_PERF_REPO_NAME env variable is used in the `aggregate.perl` script to set the 'environment' field in the JSON Codespeed output. Let's make it easy to set this variable by setting it in a config file. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05perf/run: learn to send output to codespeed serverChristian Couder1-1/+11
Let's make it possible to set in a config file the URL of a codespeed server. And then let's make the `run` script send the perf test results to this URL at the end of the tests. This should make is possible to easily automate the process of running perf tests and having their results available in Codespeed. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05perf/run: learn about perf.codespeedOutputChristian Couder1-1/+6
Let's make it possible to set in a config file the output format (regular or codespeed) of the perf tests. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05perf/run: add conf_opts argument to get_var_from_env_or_config()Christian Couder1-5/+6
Let's make it possible to use `git config` type specifiers like `--int` or `--bool`, so that config values are converted to the canonical form and easier to use. This additional argument is now the fourth argument of get_var_from_env_or_config() instead of the fifth because we want the default value argument to be unset if it is not passed, and this is simpler if it is the last argument. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05perf/aggregate: implement codespeed JSON outputChristian Couder1-2/+62
Codespeed (https://github.com/tobami/codespeed/) is an open source project that can be used to track how some software performs over time. It stores performance test results in a database and can show nice graphs and charts on a web interface. As it can be interesting to use Codespeed to see how Git performance evolves over time and releases, let's implement a Codespeed output in "perf/aggregate.perl". Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05perf/aggregate: refactor printing resultsChristian Couder1-46/+50
As we want to implement another kind of output than the current output for the perf test results, let's refactor the existing code that outputs the results in its own print_default_results() function. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05perf/aggregate: fix checking ENV{GIT_PERF_SUBSECTION}Christian Couder1-1/+1
The way we check ENV{GIT_PERF_SUBSECTION} could trigger comparison between undef and "" that may be flagged by use of strict & warnings. Let's fix that. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05rebase -p: fix quoting when calling `git merge`Johannes Schindelin1-0/+14
It has been reported that strategy arguments are not passed to `git merge` correctly when rebasing interactively, preserving merges. The reason is that the strategy arguments are already quoted, and then quoted again. This fixes https://github.com/git-for-windows/git/issues/1321 Original-patch-by: Kim Gybels <kgybels@infogroep.be> Also-reported-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-04diffcore: add a pickaxe option to find a specific blobStefan Beller1-0/+68
Sometimes users are given a hash of an object and they want to identify it further (ex.: Use verify-pack to find the largest blobs, but what are these? or [1]) One might be tempted to extend git-describe to also work with blobs, such that `git describe <blob-id>` gives a description as '<commit-ish>:<path>'. This was implemented at [2]; as seen by the sheer number of responses (>110), it turns out this is tricky to get right. The hard part to get right is picking the correct 'commit-ish' as that could be the commit that (re-)introduced the blob or the blob that removed the blob; the blob could exist in different branches. Junio hinted at a different approach of solving this problem, which this patch implements. Teach the diff machinery another flag for restricting the information to what is shown. For example: $ ./git log --oneline --find-object=v2.0.0:Makefile b2feb64309 Revert the whole "ask curl-config" topic for now 47fbfded53 i18n: only extract comments marked with "TRANSLATORS:" we observe that the Makefile as shipped with 2.0 was appeared in v1.9.2-471-g47fbfded53 and in v2.0.0-rc1-5-gb2feb6430b. The reason why these commits both occur prior to v2.0.0 are evil merges that are not found using this new mechanism. [1] https://stackoverflow.com/questions/223678/which-commit-has-this-blob [2] https://public-inbox.org/git/20171028004419.10139-1-sbeller@google.com/ Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-04http: fix v1 protocol tests with apache httpd < 2.4Todd Zullinger1-6/+4
The apache config used by tests was updated to use the SetEnvIf directive to set the Git-Protocol header in 19113a26b6 ("http: tell server that the client understands v1", 2017-10-16). Setting the Git-Protocol header is restricted to httpd >= 2.4, but mod_setenvif and the SetEnvIf directive work with lower versions, at least as far back as 2.0, according to the httpd documentation: https://httpd.apache.org/docs/2.0/mod/mod_setenvif.html Drop the restriction. Tested with httpd 2.2 and 2.4. Signed-off-by: Todd Zullinger <tmz@pobox.com> Acked-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-04perf: amend the grep tests to test grep.threadsÆvar Arnfjörð Bjarmason2-21/+86
Ever since 5b594f457a ("Threaded grep", 2010-01-25) the number of threads git-grep uses under PTHREADS has been hardcoded to 8, but there's no performance test to check whether this is an optimal setting. Amend the existing tests for the grep engines to support a mode where this can be tested, e.g.: GIT_PERF_GREP_THREADS='1 8 16' GIT_PERF_LARGE_REPO=~/g/linux ./run p782* Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-03t0302 & t3900: add forgotten quotesJohannes Schindelin2-5/+5
When cleaning up files in the $HOME directory, it really makes sense to quote the path, especially in Git's test suite, where the HOME directory is *guaranteed* to contain spaces in its name. It would appear that those two tests pass even without cleaning up the files, but really more by pure chance than by design (the cleanup seems not actually to be necessary). However, if anybody would have a left-over `trash/` directory in Git's `t/` directory, these tests would fail, because they would all of a sudden try to delete that directory, but without the `-r` (recursive) flag. That is how this issue was found. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-03Allow the test suite to pass in a directory whose name contains spacesJohannes Schindelin3-5/+5
It is totally legitimate to clone Git's source code anywhere, including into, say, directories whose name (or the name of its absolute path) contains spaces. However, a couple of tests failed to anticipate this, for lack of quoting (or in one instance, for failure to expect more than one space in the absolute path of the TEST_DIRECTORY). This can be easily verified by calling these commands in your current clone: git clone . with\ spaces cd with\ spaces make -j15 test Let's fix this. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-03clone: do not clean up directories we didn't createJeff King1-5/+51
Once upon a time, git-clone would refuse to write into a directory that it did not itself create. The cleanup routines for a failed clone could therefore just remove the git and worktree dirs completely. In 55892d2398 (Allow cloning to an existing empty directory, 2009-01-11), we learned to write into an existing directory. Which means that doing: mkdir foo git clone will-fail foo ends up deleting foo. This isn't a huge catastrophe, since by definition foo must be empty. But it's somewhat confusing; we should leave the filesystem as we found it. Because we know that the only directory we'll write into is an empty one, we can handle this case by just passing the KEEP_TOPLEVEL flag to our recursive delete (if we could write into populated directories, we'd have to keep track of what we wrote and what we did not, which would be much harder). Note that we need to handle the work-tree and git-dir separately, though, as only one might exist (and the new tests in t5600 cover all cases). Reported-by: Stephan Janssen <sjanssen@you-get.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-03t5600: modernize styleJeff King1-23/+25
This is an old script which could use some updating before we add to it: - use the standard line-breaking: test_expect_success 'title' ' body ' - run all code inside test_expect blocks to catch unexpected failures in setup steps - use "test_commit -C" instead of manually entering sub-repo - use test_when_finished for cleanup steps - test_path_is_* as appropriate Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-03t5600: fix outdated comment about unborn HEADJeff King1-1/+1
Back when this test was written, git-clone could not handle a repository without any commits. These days it works fine, and this comment is out of date. At first glance it seems like we could just drop this code entirely now, but it's necessary for the final test, which was added later. That test corrupts the repository by temporarily removing its objects, which means we need to have some objects to move. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-03merge: teach -Xours/-Xtheirs to symbolic link mergeJunio C Hamano1-0/+32
The -Xours/-Xtheirs merge options were originally defined as a way to "force" the resolution of 3way textual merge conflicts to take one side without using your editor, hence did not even trigger in situations where you would normally not get the <<< === >>> conflict markers. This was improved for binary files back in 2012 with a944af1d ("merge: teach -Xours/-Xtheirs to binary ll-merge driver", 2012-09-08). Teach a similar trick to the codepath that deals with merging two conflicting changes to symbolic links. Signed-off-by: Junio C Hamano <gitster@pobox.com> Tested-by: Yaroslav Halchenko <yoh@onerussian.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-28Merge branch 'sb/describe-blob'Junio C Hamano2-1/+112
"git describe" was taught to dig trees deeper to find a <commit-ish>:<path> that refers to a given blob object. * sb/describe-blob: builtin/describe.c: describe a blob builtin/describe.c: factor out describe_commit builtin/describe.c: print debug statements earlier builtin/describe.c: rename `oid` to avoid variable shadowing revision.h: introduce blob/tree walking in order of the commits list-objects.c: factor out traverse_trees_and_blobs t6120: fix typo in test name
2017-12-28Merge branch 'hi/merge-verify-sig-config'Junio C Hamano2-0/+126
"git merge" learned to pay attention to merge.verifySignatures configuration variable and pretend as if '--verify-signatures' option was given from the command line. * hi/merge-verify-sig-config: t5573, t7612: clean up after unexpected success of 'pull' and 'merge' t: add tests for pull --verify-signatures merge: add config option for verifySignatures
2017-12-28Merge branch 'bp/fsmonitor'Junio C Hamano1-2/+1
Test fix. * bp/fsmonitor: p7519: improve check for prerequisite WATCHMAN
2017-12-28Merge branch 'tz/lib-git-svn-svnserve-tests'Junio C Hamano1-11/+13
* tz/lib-git-svn-svnserve-tests: t/lib-git-svn.sh: improve svnserve tests with parallel make test t/lib-git-svn: cleanup inconsistent tab/space usage
2017-12-28Merge branch 'ew/svn-crlf'Junio C Hamano1-0/+27
"git svn" has been updated to strip CRs in the commit messages, as recent versions of Subversion rejects them. * ew/svn-crlf: git-svn: convert CRLF to LF in commit message to SVN
2017-12-28Merge branch 'cc/skip-to-optional-val'Junio C Hamano1-48/+62
Introduce a helper to simplify code to parse a common pattern that expects either "--key" or "--key=<something>". * cc/skip-to-optional-val: t4045: reindent to make helpers readable diff: add tests for --relative without optional prefix value diff: use skip_to_optional_arg_default() in parsing --relative diff: use skip_to_optional_arg_default() diff: use skip_to_optional_arg() index-pack: use skip_to_optional_arg() git-compat-util: introduce skip_to_optional_arg()
2017-12-27wt-status.c: handle worktree renamesNguyễn Thái Ngọc Duy1-0/+60
Before 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist in index" - 2016-10-24) there are never "new files" in the index, which essentially disables rename detection because we only detect renames when a new file appears in a diff pair. After that commit, an i-t-a entry can appear as a new file in "git diff-files". But the diff callback function in wt-status.c does not handle this case and produces incorrect status output. PS. The reader may notice that this patch adds a new xstrdup() but not a free(). Yes we leak memory (the same for head_path). But wt_status so far has been short lived, this leak should not matter in practice. Noticed-by: Alex Vandiver <alexmv@dropbox.com> Helped-by: Igor Djordjevic <igor.d.djordjevic@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-27t2203: test status output with porcelain v2 formatNguyễn Thái Ngọc Duy1-0/+12
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-27Merge branch 'sb/test-helper-excludes'Junio C Hamano1-41/+5
Simplify the ignore rules for t/helper directory. * sb/test-helper-excludes: t/helper: ignore everything but sources
2017-12-27Merge branch 'es/clone-shared-worktree'Junio C Hamano1-0/+6
"git clone --shared" to borrow from a (secondary) worktree did not work, even though "git clone --local" did. Both are now accepted. * es/clone-shared-worktree: clone: support 'clone --shared' from a worktree
2017-12-27Merge branch 'jt/decorate-api'Junio C Hamano3-0/+85
A few structures and variables that are implementation details of the decorate API have been renamed and then the API got documented better. * jt/decorate-api: decorate: clean up and document API
2017-12-27Merge branch 'es/worktree-checkout-hook'Junio C Hamano1-0/+29
"git worktree add" learned to run the post-checkout hook, just like "git checkout" does, after the initial checkout. * es/worktree-checkout-hook: worktree: invoke post-checkout hook (unless --no-checkout)
2017-12-27Merge branch 'lb/rebase-i-short-command-names'Junio C Hamano1-0/+22
With a configuration variable rebase.abbreviateCommands set, "git rebase -i" produces the todo list with a single-letter command names. * lb/rebase-i-short-command-names: sequencer.c: drop 'const' from function return type t3404: add test case for abbreviated commands rebase -i: learn to abbreviate command names rebase -i -x: add exec commands via the rebase--helper rebase -i: update functions to use a flags parameter rebase -i: replace reference to sha1 with oid rebase -i: refactor transform_todo_ids rebase -i: set commit to null in exec commands Documentation: use preferred name for the 'todo list' script Documentation: move rebase.* configs to new file
2017-12-27Merge branch 'tb/check-crlf-for-safe-crlf'Junio C Hamano1-5/+72
The "safe crlf" check incorrectly triggered for contents that does not use CRLF as line endings, which has been corrected. * tb/check-crlf-for-safe-crlf: t0027: Adapt the new MIX tests to Windows convert: tighten the safe autocrlf handling
2017-12-27Merge branch 'jh/object-filtering'Junio C Hamano2-0/+600
In preparation for implementing narrow/partial clone, the object walking machinery has been taught a way to tell it to "filter" some objects from enumeration. * jh/object-filtering: rev-list: support --no-filter argument list-objects-filter-options: support --no-filter list-objects-filter-options: fix 'keword' typo in comment pack-objects: add list-objects filtering rev-list: add list-objects filtering support list-objects: filter objects in traverse_commit_list oidset: add iterator methods to oidset oidmap: add oidmap iterator methods dir: allow exclusions from blob in addition to file
2017-12-27describe: prepend "tags/" when describing tags with embedded nameDaniel Knittl-Frank1-1/+5
The man page of the "git describe" command explains the expected output when using the --all option, i.e. the full reference path is shown, including heads/ or tags/ prefix. When 212945d4a85dfa172ea55ec73b1d830ef2d8582f ("Teach git-describe to verify annotated tag names before output") made Git favor the embedded name of annotated tags, it accidentally changed the output format when the --all flag is given, only printing the tag's name without the prefix. Check if --all was specified and re-add the "tags/" prefix for this special case to fix the regresssion. Signed-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22sequencer: assign only free()able strings to gpg_signJohannes Schindelin1-0/+10
The gpg_sign member of the replay_opts structure is of type `char *`, meaning that the sequencer deems the string to which gpg_sign points to be under its custody, i.e. it needs to be free()d by the sequencer. Therefore, let's only assign malloc()ed buffers to it. Reported-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22git-p4: update multiple shelved change listsLuke Diamand1-10/+14
--update-shelve can now be specified multiple times on the command-line, to update multiple shelved changelists in a single submit. This then means that a git patch series can be mirrored to a sequence of shelved changelists, and (relatively easily) kept in sync as changes are made in git. Note that Perforce does not really support overlapping shelved changelists where one change touches the files modified by another. Trying to do this will result in merge conflicts. Signed-off-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22commit: add support for --fixup <commit> -m"<extra message>"Ævar Arnfjörð Bjarmason1-1/+8
Add support for supplying the -m option with --fixup. Doing so has errored out ever since --fixup was introduced. Before this, the only way to amend the fixup message while committing was to use --edit and amend it in the editor. The use-case for this feature is one of: * Leaving a quick note to self when creating a --fixup commit when it's not self-evident why the commit should be squashed without a note into another one. * (Ab)using the --fixup feature to "fix up" commits that have already been pushed to a branch that doesn't allow non-fast-forwards, i.e. just noting "this should have been part of that other commit", and if the history ever got rewritten in the future the two should be combined. In such a case you might want to leave a small message, e.g. "forgot this part, which broke XYZ". With this, --fixup <commit> -m"More" -m"Details" will result in a commit message like: !fixup <subject of <commit>> More Details The reason the test being added here seems to squash "More" at the end of the subject line of the commit being fixed up is because the test code is using "%s%b" so the body immediately follows the subject, it's not a bug in this code, and other tests t7500-commit.sh do the same thing. When the --fixup option was initially added the "Option -m cannot be combined" error was expanded from -c, -C and -F to also include --fixup[1] Those options could also support combining with -m, but given what they do I can't think of a good use-case for doing that, so I have not made the more invasive change of splitting up the logic in commit.c to first act on those, and then on -m options. 1. d71b8ba7c9 ("commit: --fixup option for use with rebase --autosquash", 2010-11-02) Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22check-non-portable-shell.pl: `wc -l` may have leading WSTorsten Bögershausen1-0/+1
Test scripts count number of lines in an output and check it againt its expectation. fb3340a6 ("test-lib: introduce test_line_count to measure files", 2010-10-31) introduced a helper to show a failure in such a test in a more readable way than comparing `wc -l` output with a number. Besides, on some platforms, "$(wc -l <file)" is padded with leading whitespace on the left, so test "$(wc -l <file)" = 4 would not work (most notably on macosX); the users of test_line_count helper would not suffer from such a portability glitch. Add a check in check-non-portable-shell.pl to find '"' between `wc -l` and '=' and hint the user about test_line_count(). Signed-off-by: Torsten Bögershausen <tboegi@web.de> Reviewed-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22Merge branch 'ew/empty-merge-with-dirty-index-maint' into ↵Junio C Hamano1-5/+21
ew/empty-merge-with-dirty-index * ew/empty-merge-with-dirty-index-maint: merge-recursive: avoid incorporating uncommitted changes in a merge move index_has_changes() from builtin/am.c to merge.c for reuse t6044: recursive can silently incorporate dirty changes in a merge
2017-12-22merge-recursive: avoid incorporating uncommitted changes in a mergeElijah Newren1-1/+1
builtin/merge.c contains this important requirement for merge strategies: /* * At this point, we need a real merge. No matter what strategy * we use, it would operate on the index, possibly affecting the * working tree, and when resolved cleanly, have the desired * tree in the index -- this means that the index must be in * sync with the head commit. The strategies are responsible * to ensure this. */ merge-recursive does not do this check directly, instead it relies on unpack_trees() to do it. However, merge_trees() has a special check for the merge branch exactly matching the merge base; when it detects that situation, it returns early without calling unpack_trees(), because it knows that the HEAD commit already has the correct result. Unfortunately, it didn't check that the index matched HEAD, so after it returned, the outer logic ended up creating a merge commit that included something other than HEAD. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22t6044: recursive can silently incorporate dirty changes in a mergeElijah Newren1-5/+21
The recursive merge strategy has some special handling when the tree for the merge branch exactly matches the merge base, but that code path is missing checks for the index having changes relative to HEAD. Add a testcase covering this scenario. Reported-by: Andreas Krey <a.krey@gmx.de> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-22t/helper/test-lazy-name-hash: fix compilationStefan Beller1-1/+1
I was compiling origin/master today with DEVELOPER compiler flags and was greeted by: t/helper/test-lazy-init-name-hash.c: In function ‘cmd_main’: t/helper/test-lazy-init-name-hash.c:172:5: error: ‘nr_threads_used’ may be used uninitilized in this function [-Werror=maybe-uninitialized] printf("avg [size %8d] [single %f] %c [multi %f %d]\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ nr, ~~~ (double)avg_single/1000000000, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (avg_single < avg_multi ? '<' : '>'), ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (double)avg_multi/1000000000, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ nr_threads_used); ~~~~~~~~~~~~~~~~ t/helper/test-lazy-init-name-hash.c:115:6: note: ‘nr_threads_used’ was declared here int nr_threads_used; ^~~~~~~~~~~~~~~ I do not see how we can arrive at that line without having `nr_threads_used` initialized, as we'd have `count > 1` (which asserts that we ran the loop above at least once, such that it *should* be initialized). Just clear the variable at the beginning of the function to squelch the warning. Signed-off-by: Stefan Beller <sbeller@google.com> Acked-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-19t5573, t7612: clean up after unexpected success of 'pull' and 'merge'Junio C Hamano2-8/+17
The previous steps added test_when_finished to tests that run 'git pull' or 'git merge' with expectation of success, so that the test after them can start from a known state even when their 'git pull' invocation unexpectedly fails. However, tests that run 'git pull' or 'git merge' expecting it not to succeed forgot to protect later tests the same way---if they unexpectedly succeed, the test after them would start from an unexpected state. Reset and checkout the initial commit after all these tests, whether they expect their invocations to succeed or fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-19Merge branch 'ar/unconfuse-three-dots'Junio C Hamano18-9/+401
Ancient part of codebase still shows dots after an abbreviated object name just to show that it is not a full object name, but these ellipses are confusing to people who newly discovered Git who are used to seeing abbreviated object names and find them confusing with the range syntax. * ar/unconfuse-three-dots: t2020: test variations that matter t4013: test new output from diff --abbrev --raw diff: diff_aligned_abbrev: remove ellipsis after abbreviated SHA-1 value t4013: prepare for upcoming "diff --raw --abbrev" output format change checkout: describe_detached_head: remove ellipsis after committish print_sha1_ellipsis: introduce helper Documentation: user-manual: limit usage of ellipsis Documentation: revisions: fix typo: "three dot" ---> "three-dot" (in line with "two-dot").
2017-12-19Merge branch 'tg/worktree-create-tracking'Junio C Hamano1-0/+130
The way "git worktree add" determines what branch to create from where and checkout in the new worktree has been updated a bit. * tg/worktree-create-tracking: add worktree.guessRemote config option worktree: add --guess-remote flag to add subcommand worktree: make add <path> <branch> dwim worktree: add --[no-]track option to the add subcommand worktree: add can be created from any commit-ish checkout: factor out functions to new lib file
2017-12-19Merge branch 'bw/submodule-config-cleanup'Junio C Hamano1-0/+17
Recent update to the submodule configuration code broke "diff-tree" by accidentally stopping to read from the index upfront. * bw/submodule-config-cleanup: diff-tree: read the index so attribute checks work in bare repositories
2017-12-19Merge branch 'bw/pathspec-match-submodule-boundary'Junio C Hamano1-0/+19
An v2.12-era regression in pathspec match logic, which made it look into submodule tree even when it is not desired, has been fixed. * bw/pathspec-match-submodule-boundary: pathspec: only match across submodule boundaries when requested
2017-12-19Merge branch 'jt/diff-anchored-patience'Junio C Hamano1-0/+94
"git diff" learned a variant of the "--patience" algorithm, to which the user can specify which 'unique' line to be used as anchoring points. * jt/diff-anchored-patience: diff: support anchoring line(s)
2017-12-19Merge branch 'en/rename-progress'Junio C Hamano1-0/+15
Historically, the diff machinery for rename detection had a hardcoded limit of 32k paths; this is being lifted to allow users trade cycles with a (possibly) easier to read result. * en/rename-progress: diffcore-rename: make diff-tree -l0 mean -l<large> sequencer: show rename progress during cherry picks diff: remove silent clamp of renameLimit progress: fix progress meters when dealing with lots of work sequencer: warn when internal merge may be suboptimal due to renameLimit
2017-12-19builtin/describe.c: describe a blobStefan Beller1-0/+34
Sometimes users are given a hash of an object and they want to identify it further (ex.: Use verify-pack to find the largest blobs, but what are these? or [1]) When describing commits, we try to anchor them to tags or refs, as these are conceptually on a higher level than the commit. And if there is no ref or tag that matches exactly, we're out of luck. So we employ a heuristic to make up a name for the commit. These names are ambiguous, there might be different tags or refs to anchor to, and there might be different path in the DAG to travel to arrive at the commit precisely. When describing a blob, we want to describe the blob from a higher layer as well, which is a tuple of (commit, deep/path) as the tree objects involved are rather uninteresting. The same blob can be referenced by multiple commits, so how we decide which commit to use? This patch implements a rather naive approach on this: As there are no back pointers from blobs to commits in which the blob occurs, we'll start walking from any tips available, listing the blobs in-order of the commit and once we found the blob, we'll take the first commit that listed the blob. For example git describe --tags v0.99:Makefile conversion-901-g7672db20c2:Makefile tells us the Makefile as it was in v0.99 was introduced in commit 7672db20. The walking is performed in reverse order to show the introduction of a blob rather than its last occurrence. [1] https://stackoverflow.com/questions/223678/which-commit-has-this-blob Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-18p7519: improve check for prerequisite WATCHMANRené Scharfe1-2/+1
The return code of command -v with a non-existing command is 1 in bash and 127 in dash. Use that return code directly to allow the script to work with dash and without watchman (e.g. on Debian). While at it stop redirecting the output. stderr is redirected to /dev/null by test_lazy_prereq already, and stdout can actually be useful -- the path of the found watchman executable is sent there, but it's shown only if the script was run with --verbose. Signed-off-by: Rene Scharfe <l.s.r@web.de> Acked-by: Ben Peart <benpeart@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-14t/lib-git-svn.sh: improve svnserve tests with parallel make testTodd Zullinger1-2/+4
Setting SVNSERVE_PORT enables several tests which require a local svnserve daemon to be run (in t9113 & t9126). The tests share setup of the local svnserve via `start_svnserve()`. The function uses svnserve's `--listen-once` option, which causes svnserve to accept one connection on the port, serve it, and exit. When running the tests in parallel this fails if one test tries to start svnserve while the other is still running. Use the test number as the svnserve port (similar to httpd tests) to avoid port conflicts. Developers can set GIT_TEST_SVNSERVE to any value other than 'false' or 'auto' to enable these tests. Acked-by: Eric Wong <e@80x24.org> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Todd Zullinger <tmz@pobox.com>
2017-12-14t/lib-git-svn: cleanup inconsistent tab/space usageTodd Zullinger1-11/+11
Acked-by: Eric Wong <e@80x24.org> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Todd Zullinger <tmz@pobox.com>
2017-12-14Merge branch 'svn-crlf' of git://bogomips.org/git-svn into ew/svn-crlfJunio C Hamano1-0/+27
* 'svn-crlf' of git://bogomips.org/git-svn: git-svn: convert CRLF to LF in commit message to SVN
2017-12-14git-svn: convert CRLF to LF in commit message to SVNEric Wong1-0/+27
Subversion since 1.6 does not accept CR characters in the commit message, so filter it out on our end before 'git svn dcommit' sets the svn:log property. Reported-by: Brian Bennett <Brian.Bennett@Transamerica.com> Signed-off-by: Eric Wong <e@80x24.org>
2017-12-13Merge branch 'ds/for-each-file-in-obj-micro-optim'Junio C Hamano1-0/+4
The code to iterate over loose object files got optimized. * ds/for-each-file-in-obj-micro-optim: sha1_file: use strbuf_add() instead of strbuf_addf()
2017-12-13Merge branch 'tg/t-readme-updates'Junio C Hamano1-4/+6
Developer doc updates. * tg/t-readme-updates: t/README: document test_cmp_rev t/README: remove mention of adding copyright notices
2017-12-13Merge branch 'ab/pcre2-grep'Junio C Hamano3-0/+20
"git grep" compiled with libpcre2 sometimes triggered a segfault, which is being fixed. * ab/pcre2-grep: grep: fix segfault under -P + PCRE2 <=10.30 + (*NO_JIT) test-lib: add LIBPCRE1 & LIBPCRE2 prerequisites
2017-12-13Merge branch 'ra/decorate-limit-refs'Junio C Hamano1-0/+101
The tagnames "git log --decorate" uses to annotate the commits can now be limited to subset of available refs with the two additional options, --decorate-refs[-exclude]=<pattern>. * ra/decorate-limit-refs: log: add option to choose which refs to decorate
2017-12-12t/helper: ignore everything but sourcesStefan Beller1-38/+4
Compiled test helpers in t/helper are out of sync with the .gitignore files quite frequently. This can happen when new test helpers are added, but the explicit .gitignore file is not updated in the same commit, or when you forget to 'make clean' before checking out a different version of git, as the different version may have a different explicit list of test helpers to ignore. Fix this by having an overly broad ignore pattern in that directory: Anything, except C and shell source, will be ignored. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-12t: add tests for pull --verify-signaturesHans Jerry Illikainen1-0/+78
Add tests for pull --verify-signatures with untrusted, bad and no signatures. Previously the only test for --verify-signatures was to make sure that pull --rebase --verify-signatures result in a warning (t5520-pull.sh). Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-12merge: add config option for verifySignaturesHans Jerry Illikainen1-0/+39
git merge --verify-signatures can be used to verify that the tip commit of the branch being merged in is properly signed, but it's cumbersome to have to specify that every time. Add a configuration option that enables this behaviour by default, which can be overridden by --no-verify-signatures. Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-11t4045: reindent to make helpers readableJunio C Hamano1-48/+56
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-11diff: add tests for --relative without optional prefix valueJacob Keller1-8/+14
We already have tests for --relative, but they currently only test when a prefix has been provided. This fails to test the case where --relative by itself should use the current directory as the prefix. Teach the check_$type functions to take a directory argument to indicate which subdirectory to run the git commands in. Add a new test which uses this to test --relative without a prefix value. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-11clone: support 'clone --shared' from a worktreeEric Sunshine1-0/+6
When worktree functionality was originally implemented, the possibility of 'clone --local' from within a worktree was overlooked, with the result that the location of the "objects" directory of the source repository was computed incorrectly, thus the objects could not be copied or hard-linked by the clone. This shortcoming was addressed by 744e469755 (clone: allow --local from a linked checkout, 2015-09-28). However, the related case of 'clone --shared' (despite being handled only a few lines away from the 'clone --local' case) was not fixed by 744e469755, with a similar result of the "objects" directory location being incorrectly computed for insertion into the 'alternates' file. Fix this. Reported-by: Marc-André Lureau <marcandre.lureau@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-11Makefile: replace perl/Makefile.PL with simple make rulesÆvar Arnfjörð Bjarmason2-2/+2
Replace the perl/Makefile.PL and the fallback perl/Makefile used under NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily inspired by how the i18n infrastructure's build process works[1]. The reason for having the Makefile.PL in the first place is that it was initially[2] building a perl C binding to interface with libgit, this functionality, that was removed[3] before Git.pm ever made it to the master branch. We've since since started maintaining a fallback perl/Makefile, as MakeMaker wouldn't work on some platforms[4]. That's just the tip of the iceberg. We have the PM.stamp hack in the top-level Makefile[5] to detect whether we need to regenerate the perl/perl.mak, which I fixed just recently to deal with issues like the perl version changing from under us[6]. There is absolutely no reason for why this needs to be so complex anymore. All we're getting out of this elaborate Rube Goldberg machine was copying perl/* to perl/blib/* as we do a string-replacement on the *.pm files to hardcode @@LOCALEDIR@@ in the source, as well as pod2man-ing Git.pm & friends. So replace the whole thing with something that's pretty much a copy of how we generate po/build/**.mo from po/*.po, just with a small sed(1) command instead of msgfmt. As that's being done rename the files from *.pm to *.pmc just to indicate that they're generated (see "perldoc -f require"). While I'm at it, change the fallback for Error.pm from being something where we'll ship our own Error.pm if one doesn't exist at build time to one where we just use a Git::Error wrapper that'll always prefer the system-wide Error.pm, only falling back to our own copy if it really doesn't exist at runtime. It's now shipped as Git::FromCPAN::Error, making it easy to add other modules to Git::FromCPAN::* in the future if that's needed. Functional changes: * This will not always install into perl's idea of its global "installsitelib". This only potentially matters for packagers that need to expose Git.pm for non-git use, and as explained in the INSTALL file there's a trivial workaround. * The scripts themselves will 'use lib' the target directory, but if INSTLIBDIR is set it overrides it. It doesn't have to be this way, it could be set in addition to INSTLIBDIR, but my reading of [7] is that this is the desired behavior. * We don't build man pages for all of the perl modules as we used to, only Git(3pm). As discussed on-list[8] that we were building installed manpages for purely internal APIs like Git::I18N or private-Error.pm was always a bug anyway, and all the Git::SVN::* ones say they're internal APIs. There are apparently external users of Git.pm, but I don't expect there to be any of the others. As a side-effect of these general changes the perl documentation now only installed by install-{doc,man}, not a mere "install" as before. 1. 5e9637c629 ("i18n: add infrastructure for translating Git with gettext", 2011-11-18) 2. b1edc53d06 ("Introduce Git.pm (v4)", 2006-06-24) 3. 18b0fc1ce1 ("Git.pm: Kill Git.xs for now", 2006-09-23) 4. f848718a69 ("Make perl/ build procedure ActiveState friendly.", 2006-12-04) 5. ee9be06770 ("perl: detect new files in MakeMaker builds", 2012-07-27) 6. c59c4939c2 ("perl: regenerate perl.mak if perl -V changes", 2017-03-29) 7. 0386dd37b1 ("Makefile: add PERLLIB_EXTRA variable that adds to default perl path", 2013-11-15) 8. 87bmjjv1pu.fsf@evledraar.booking.com ("Re: [PATCH] Makefile: replace perl/Makefile.PL with simple make rules" Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08t0027: Adapt the new MIX tests to WindowsTorsten Bögershausen1-8/+9
The new MIX tests don't pass under Windows, adapt them to use the correct native line ending. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08t5616: test bulk prefetch after partial fetchJeff Hostetler1-1/+31
Add test to t5616 to bulk fetch missing objects following a partial fetch. A technique like this could be used in a pre-command hook for example. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08fetch: inherit filter-spec from partial cloneJeff Hostetler1-1/+21
Teach (partial) fetch to inherit the filter-spec used by the partial clone. Extend --no-filter to override this inheritance. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08t5616: end-to-end tests for partial cloneJeff Hostetler1-0/+96
Additional end-to-end tests for partial clone. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08unpack-trees: batch fetching of missing blobsJonathan Tan1-0/+52
When running checkout, first prefetch all blobs that are to be updated but are missing. This means that only one pack is downloaded during such operations, instead of one per missing blob. This operates only on the blob level - if a repository has a missing tree, they are still fetched one at a time. This does not use the delayed checkout mechanism introduced in commit 2841e8f ("convert: add "status=delayed" to filter process protocol", 2017-06-30) due to significant conceptual differences - in particular, for partial clones, we already know what needs to be fetched based on the contents of the local repo alone, whereas for status=delayed, it is the filter process that tells us what needs to be checked in the end. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08clone: partial cloneJonathan Tan1-0/+49
Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08fetch: support filtersJeff Hostetler1-0/+36
Teach fetch to support filters. This is only allowed for the remote configured in extensions.partialcloneremote. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08fetch-pack: test support excluding large blobsJonathan Tan1-0/+27
Created tests to verify fetch-pack and upload-pack support for excluding large blobs using --filter=blobs:limit=<n> parameter. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08gc: do not repack promisor packfilesJonathan Tan1-2/+52
Teach gc to stop traversal at promisor objects, and to leave promisor packfiles alone. This has the effect of only repacking non-promisor packfiles, and preserves the distinction between promisor packfiles and non-promisor packfiles. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08rev-list: support termination at promisor objectsJonathan Tan1-0/+101
Teach rev-list to support termination of an object traversal at any object from a promisor remote (whether one that the local repo also has, or one that the local repo knows about because it has another promisor object that references it). This will be used subsequently in gc and in the connectivity check used by fetch. For efficiency, if an object is referenced by a promisor object, and is in the local repo only as a non-promisor object, object traversal will not stop there. This is to avoid building the list of promisor object references. (In list-objects.c, the case where obj is NULL in process_blob() and process_tree() do not need to be changed because those happen only when there is a conflict between the expected type and the existing object. If the object doesn't exist, an object will be synthesized, which is fine.) Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08sha1_file: support lazily fetching missing objectsJonathan Tan1-0/+51
Teach sha1_file to fetch objects from the remote configured in extensions.partialclone whenever an object is requested but missing. The fetching of objects can be suppressed through a global variable. This is used by fsck and index-pack. However, by default, such fetching is not suppressed. This is meant as a temporary measure to ensure that all Git commands work in such a situation. Future patches will update some commands to either tolerate missing objects (without fetching them) or be more efficient in fetching them. In order to determine the code changes in sha1_file.c necessary, I investigated the following: (1) functions in sha1_file.c that take in a hash, without the user regarding how the object is stored (loose or packed) (2) functions in packfile.c (because I need to check callers that know about the loose/packed distinction and operate on both differently, and ensure that they can handle the concept of objects that are neither loose nor packed) (1) is handled by the modification to sha1_object_info_extended(). For (2), I looked at for_each_packed_object and others. For for_each_packed_object, the callers either already work or are fixed in this patch: - reachable - only to find recent objects - builtin/fsck - already knows about missing objects - builtin/cat-file - warning message added in this commit Callers of the other functions do not need to be changed: - parse_pack_index - http - indirectly from http_get_info_packs - find_pack_entry_one - this searches a single pack that is provided as an argument; the caller already knows (through other means) that the sought object is in a specific pack - find_sha1_pack - fast-import - appears to be an optimization to not store a file if it is already in a pack - http-walker - to search through a struct alt_base - http-push - to search through remote packs - has_sha1_pack - builtin/fsck - already knows about promisor objects - builtin/count-objects - informational purposes only (check if loose object is also packed) - builtin/prune-packed - check if object to be pruned is packed (if not, don't prune it) - revision - used to exclude packed objects if requested by user - diff - just for optimization Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08decorate: clean up and document APIJonathan Tan3-0/+85
Improve the names of the identifiers in decorate.h, document them, and add an example of how to use these functions. The example is compiled and run as part of the test suite. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08t/Makefile: introduce TEST_SHELL_PATHJeff King2-3/+5
You may want to run the test suite with a different shell than you use to build Git. For instance, you may build with SHELL_PATH=/bin/sh (because it's faster, or it's what you expect to exist on systems where the build will be used) but want to run the test suite with bash (e.g., since that allows using "-x" reliably across the whole test suite). There's currently no good way to do this. You might think that doing two separate make invocations, like: make && make -C t SHELL_PATH=/bin/bash would work. And it _almost_ does. The second make will see our bash SHELL_PATH, and we'll use that to run the individual test scripts (or tell prove to use it to do so). So far so good. But this breaks down when "--tee" or "--verbose-log" is used. Those options cause the test script to actually re-exec itself using $SHELL_PATH. But wait, wouldn't our second make invocation have set SHELL_PATH correctly in the environment? Yes, but test-lib.sh sources GIT-BUILD-OPTIONS, which we built during the first "make". And that overrides the environment, giving us the original SHELL_PATH again. Let's introduce a new variable that lets you specify a specific shell to be run for the test scripts. Note that we have to touch both the main and t/ Makefiles, since we have to record it in GIT-BUILD-OPTIONS in one, and use it in the latter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08test-lib: make "-x" work with "--verbose-log"Jeff King1-2/+8
The "-x" tracing option implies "--verbose". This is a problem when running under a TAP harness like "prove", where we need to use "--verbose-log" instead. Instead, let's handle this the same way we do for --valgrind, including the recent fix from 88c6e9d31c (test-lib: --valgrind should not override --verbose-log, 2017-09-05). Namely, let's enable --verbose only when we know there isn't a more specific verbosity option indicated. Note that we also have to tweak `want_trace` to turn it on (previously we just lumped $verbose_log in with $verbose, but now we don't necessarily auto-set the latter). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08t5615: avoid re-using descriptor 4Jeff King1-3/+3
File descriptors 3 and 4 are special in our test suite, as they link back to the test script's original stdout and stderr. Normally this isn't something tests need to worry about: they are free to clobber these descriptors for sub-commands without affecting the overall script. But there's one very special thing about descriptor 4: since d88785e424 (test-lib: set BASH_XTRACEFD automatically, 2016-05-11), we ask bash to output "set -x" output to it by number. This goes to _any_ descriptor 4, even if it no longer points to the place it did when we set BASH_XTRACEFD. But in t5615, we run a shell loop with descriptor 4 redirected. As a result, t5615 works with non-bash shells even with "-x". And it works with bash without "-x". But the combination of "bash t5615-alternate-env.sh -x" gets a test failure (because our "set -x" output pollutes one of the files). We can fix this by using any descriptor _except_ the magical 4. So let's switch arbitrarily to using 5/6 in this loop, not 3/4. Another alternative is to use a different descriptor for BASH_XTRACEFD. But picking an unused one turns out to be hard. Most shells limit us to 9 numbered descriptors. Bash can handle more, but: - while the BASH_XTRACEFD is specific to bash, GIT_TRACE=4 has a similar problem, and would affect all shells - constructs like "999>/dev/null" are synticatically invalid to non-bash shells. So we have to actually bury it inside an eval, which creates more complications. Of the numbers 1-9, you might think that "9" would be less used than "4". But it's not; many of our scripts use descriptors 8 and 9 (probably under the assumption that they are high and therefore unused). The least-used descriptor is currently "7". We could switch to that, but we're just trading one magic number for another. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08test-lib: silence "-x" cleanup under bashJeff King1-10/+24
When the test suite's "-x" option is used with bash, we end up seeing cleanup cruft in the output: $ bash t0001-init.sh -x [...] ++ diff -u expected actual + test_eval_ret_=0 + want_trace + test t = t + test t = t + set +x ok 42 - re-init from a linked worktree This ranges from mildly annoying (for a successful test) to downright confusing (when we say "last command exited with error", but it's really 5 commands back). We normally are able to suppress this cleanup. As the in-code comment explains, we can't convince the shell not to print it, but we can redirect its stderr elsewhere. But since d88785e424 (test-lib: set BASH_XTRACEFD automatically, 2016-05-11), that doesn't hold for bash. It sends the "set -x" output directly to descriptor 4, not to stderr. We can fix this by also redirecting descriptor 4, and paying close attention to which commands redirected and which are not (see the updated comment). Two alternatives I considered and rejected: - unsetting and setting BASH_XTRACEFD; doing so closes the descriptor, which we must avoid - we could keep everything in a single block as before, redirect 4>/dev/null there, but retain 5>&4 as a copy. And then selectively restore 4>&5 for commands which should be allowed to trace. This would work, but the descriptor swapping seems unnecessarily confusing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-07worktree: invoke post-checkout hook (unless --no-checkout)Eric Sunshine1-0/+29
git-clone and git-checkout both invoke the post-checkout hook following a successful checkout, yet git-worktree neglects to do so even though it too "checks out" the worktree. Fix this oversight. Implementation note: The newly-created worktree may reference a branch or be detached. In the latter case, a commit lookup is performed, though the result is used only in a boolean sense to (a) determine if the commit actually exists, and (b) assign either the branch name or commit ID to HEAD. Since the post-commit hook needs to know the ID of the checked-out commit, the lookup now needs to be done in all cases, rather than only when detached. Consequently, a new boolean is needed to handle (b) since the lookup result itself can no longer perform that role. Reported-by: Matthew K Gumbel <matthew.k.gumbel@intel.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06diff-tree: read the index so attribute checks work in bare repositoriesBrandon Williams1-0/+17
A regression was introduced in 557a5998d (submodule: remove gitmodules_config, 2017-08-03) to how attribute processing was handled in bare repositories when running the diff-tree command. By default the attribute system will first try to read ".gitattribute" files from the working tree and then falls back to reading them from the index if there isn't a copy checked out in the worktree. Prior to 557a5998d the index was read as a side effect of the call to 'gitmodules_config()' which ensured that the index was already populated before entering the attribute subsystem. Since the call to 'gitmodules_config()' was removed the index is no longer being read so when the attribute system tries to read from the in-memory index it doesn't find any ".gitattribute" entries effectively ignoring any configured attributes. Fix this by explicitly reading the index during the setup of diff-tree. Reported-by: Ben Boeckel <ben.boeckel@kitware.com> Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06add worktree.guessRemote config optionThomas Gummerer1-0/+31
Some users might want to have the --guess-remote option introduced in the previous commit on by default, so they don't have to type it out every time they create a new worktree. Add a config option worktree.guessRemote that allows users to configure the default behaviour for themselves. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06worktree: add --guess-remote flag to add subcommandThomas Gummerer1-0/+29
Currently 'git worktree add <path>' creates a new branch named after the basename of the <path>, that matches the HEAD of whichever worktree we were on when calling "git worktree add <path>". It's sometimes useful to have 'git worktree add <path> behave more like the dwim machinery in 'git checkout <new-branch>', i.e. check if the new branch name, derived from the basename of the <path>, uniquely matches the branch name of a remote-tracking branch, and if so check out that branch and set the upstream to the remote-tracking branch. Add a new --guess-remote option that enables exactly that behaviour. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06Merge branch 'jn/ssh-wrappers'Junio C Hamano2-24/+48
The ssh-variant 'simple' introduced earlier broke existing installations by not passing --port/-4/-6 and not diagnosing an attempt to pass these as an error. Instead, default to automatically detect how compatible the GIT_SSH/GIT_SSH_COMMAND is to OpenSSH convention and then error out an invocation to make it easier to diagnose connection errors. * jn/ssh-wrappers: connect: correct style of C-style comment ssh: 'simple' variant does not support --port ssh: 'simple' variant does not support -4/-6 ssh: 'auto' variant to select between 'ssh' and 'simple' connect: split ssh option computation to its own function connect: split ssh command line options into separate function connect: split git:// setup into a separate function connect: move no_fork fallback to git_tcp_connect ssh test: make copy_ssh_wrapper_as clean up after itself
2017-12-06Merge branch 'bw/protocol-v1'Junio C Hamano4-6/+391
A new mechanism to upgrade the wire protocol in place is proposed and demonstrated that it works with the older versions of Git without harming them. * bw/protocol-v1: Documentation: document Extra Parameters ssh: introduce a 'simple' ssh variant i5700: add interop test for protocol transition http: tell server that the client understands v1 connect: tell server that the client understands v1 connect: teach client to recognize v1 server response upload-pack, receive-pack: introduce protocol version 1 daemon: recognize hidden request arguments protocol: introduce protocol extension mechanisms pkt-line: add packet_write function connect: in ref advertisement, shallows are last
2017-12-06Merge branch 'ph/stash-save-m-option-fix'Junio C Hamano1-0/+93
In addition to "git stash -m message", the command learned to accept "git stash -mmessage" form. * ph/stash-save-m-option-fix: stash: learn to parse -m/--message like commit does
2017-12-06Merge branch 'jk/fewer-pack-rescan'Junio C Hamano3-23/+82
Internaly we use 0{40} as a placeholder object name to signal the codepath that there is no such object (e.g. the fast-forward check while "git fetch" stores a new remote-tracking ref says "we know there is no 'old' thing pointed at by the ref, as we are creating it anew" by passing 0{40} for the 'old' side), and expect that a codepath to locate an in-core object to return NULL as a sign that the object does not exist. A look-up for an object that does not exist however is quite costly with a repository with large number of packfiles. This access pattern has been optimized. * jk/fewer-pack-rescan: sha1_file: fast-path null sha1 as a missing object everything_local: use "quick" object existence check p5551: add a script to test fetch pack-dir rescans t/perf/lib-pack: use fast-import checkpoint to create packs p5550: factor out nonsense-pack creation
2017-12-06Merge branch 'jt/submodule-tests-cleanup'Junio C Hamano1-218/+125
Further test clean-up. * jt/submodule-tests-cleanup: Tests: clean up submodule recursive helpers
2017-12-06Merge branch 'cc/git-packet-pm'Junio C Hamano1-2/+2
Code clean-up. * cc/git-packet-pm: Git/Packet.pm: use 'if' instead of 'unless' Git/Packet: clarify that packet_required_key_val_read allows EOF
2017-12-06Merge branch 'hm/config-parse-expiry-date'Junio C Hamano2-0/+42
"git config --expiry-date gc.reflogexpire" can read "2.weeks" from the configuration and report it as a timestamp, just like "--int" would read "1k" and report 1024, to help consumption by scripts. * hm/config-parse-expiry-date: config: add --expiry-date
2017-12-06Merge branch 'cc/perf-run-config'Junio C Hamano3-15/+89
* cc/perf-run-config: perf: store subsection results in "test-results/$GIT_PERF_SUBSECTION/" perf/run: show name of rev being built perf/run: add run_subsection() perf/run: update get_var_from_env_or_config() for subsections perf/run: add get_subsections() perf/run: add calls to get_var_from_env_or_config() perf/run: add GIT_PERF_DIRS_OR_REVS perf/run: add get_var_from_env_or_config() perf/run: add '--config' option to the 'run' script
2017-12-06Merge branch 'sb/submodule-recursive-checkout-detach-head'Junio C Hamano1-0/+17
"git checkout --recursive" may overwrite and rewind the history of the branch that happens to be checked out in submodule repositories, which might not be desirable. Detach the HEAD but still allow the recursive checkout to succeed in such a case. * sb/submodule-recursive-checkout-detach-head: Documentation/checkout: clarify submodule HEADs to be detached recursive submodules: detach HEAD from new state
2017-12-06Merge branch 'tz/redirect-fix' into maintJunio C Hamano1-1/+1
A few scripts (both in production and tests) incorrectly redirected their error output. These have been corrected. * tz/redirect-fix: rebase: fix stderr redirect in apply_autostash() t/lib-gpg: fix gpgconf stderr redirect to /dev/null
2017-12-06Merge branch 'tz/notes-error-to-stderr' into maintJunio C Hamano2-5/+5
"git notes" sent its error message to its standard output stream, which was corrected. * tz/notes-error-to-stderr: notes: send "Automatic notes merge failed" messages to stderr
2017-12-06Merge branch 'sb/test-cherry-pick-submodule-getting-in-a-way' into maintJunio C Hamano1-0/+36
The three-way merge performed by "git cherry-pick" was confused when a new submodule was added in the meantime, which has been fixed (or "papered over"). * sb/test-cherry-pick-submodule-getting-in-a-way: merge-recursive: handle addition of submodule on our side of history t/3512: demonstrate unrelated submodule/file conflict as cherry-pick failure
2017-12-06Merge branch 'rs/apply-inaccurate-eof-with-incomplete-line' into maintJunio C Hamano1-0/+14
"git apply --inaccurate-eof" when used with "--ignore-space-change" triggered an internal sanity check, which has been fixed. * rs/apply-inaccurate-eof-with-incomplete-line: apply: update line lengths for --inaccurate-eof
2017-12-06Merge branch 'ew/rebase-mboxrd' into maintJunio C Hamano1-0/+22
When "git rebase" prepared an mailbox of changes and fed it to "git am" to replay them, it was confused when a stray "From " happened to be in the log message of one of the replayed changes. This has been corrected. * ew/rebase-mboxrd: rebase: use mboxrd format to avoid split errors
2017-12-06Merge branch 'mh/avoid-rewriting-packed-refs' into maintJunio C Hamano1-0/+118
Recent update to the refs infrastructure implementation started rewriting packed-refs file more often than before; this has been optimized again for most trivial cases. * mh/avoid-rewriting-packed-refs: files-backend: don't rewrite the `packed-refs` file unnecessarily t1409: check that `packed-refs` is not rewritten unnecessarily
2017-12-06t2020: test variations that matterJunio C Hamano1-3/+3
Because our test suite is not about validating the working of the shell, it is pointless to test variations of how a literal string 'yes' is quoted when assigned to an environment variable. Instead, test various ways to spell 'yes' (we use strcasecmp() so uppercased and capitalized variant should work just like 'yes' spelled in all lowercase) and make sure we take them as 'yes'. That is more relevant in testing Git. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06t4013: test new output from diff --abbrev --rawAnn T Ropea15-1/+253
Use newly-introduced finely-grained control to teach the diff-family to honor the new environment GIT_PRINT_SHA1_ELLIPSIS and remove the ellipses when it is not set. Mentored-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ann T Ropea <bedhanger@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06t4013: prepare for upcoming "diff --raw --abbrev" output format changeAnn T Ropea1-6/+23
Most of the t4013 tests go through a list of sample command lines, and each of them is executed and its output compared with an expected one stored in t4013/ directory. Allow these lines to begin with a colon followed by magic word(s) so that test conditions can easily be tweaked. The expected use that will happen in later steps of this is to run tests expecting the traditional output and run the same test without the GIT_PRINT_SHA1_ELLIPSIS=yes environment exported for (perhaps some of) them, which will have to expect different output. Since all of the existing tests are meant to run with the environment, use the magic word "noellipses" to cause the variable not to be set and exported. As this step does not add any new test with the magic word, all tests still run with the environment variable, expecting the traditional output, but it will change soon. Based-on-patch-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ann T Ropea <bedhanger@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06checkout: describe_detached_head: remove ellipsis after committishAnn T Ropea1-0/+123
We do not want an ellipsis displayed following an (abbreviated) SHA-1 value. The days when this was necessary to indicate the truncation to lower-level Git commands and/or the user are bygone. However, to ease the transition, the ellipsis will still be printed if the user sets the environment variable GIT_PRINT_SHA1_ELLIPSIS to "yes". Correct documentation with respect to what describe_detached_head prints when GIT_PRINT_SHA1_ELLIPSIS is not set as indicated above. Add tests for the old and new behaviour. Signed-off-by: Ann T Ropea <bedhanger@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-05t3404: add test case for abbreviated commandsLiam Beguin1-0/+22
Make sure the todo list ends up using single-letter command abbreviations when the rebase.abbreviateCommands is enabled. This configuration option should not change anything else. Signed-off-by: Liam Beguin <liambeguin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-05fsck: support promisor objects as CLI argumentJonathan Tan1-0/+13
Teach fsck to not treat missing promisor objects provided on the CLI as an error when extensions.partialclone is set. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-05fsck: support referenced promisor objectsJonathan Tan1-0/+23
Teach fsck to not treat missing promisor objects indirectly pointed to by refs as an error when extensions.partialclone is set. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-05fsck: support refs pointing to promisor objectsJonathan Tan1-0/+24
Teach fsck to not treat refs referring to missing promisor objects as an error when extensions.partialclone is set. For the purposes of warning about no default refs, such refs are still treated as legitimate refs. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-05fsck: introduce partialclone extensionJonathan Tan1-0/+81
Currently, Git does not support repos with very large numbers of objects or repos that wish to minimize manipulation of certain blobs (for example, because they are very large) very well, even if the user operates mostly on part of the repo, because Git is designed on the assumption that every referenced object is available somewhere in the repo storage. In such an arrangement, the full set of objects is usually available in remote storage, ready to be lazily downloaded. Teach fsck about the new state of affairs. In this commit, teach fsck that missing promisor objects referenced from the reflog are not an error case; in future commits, fsck will be taught about other cases. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-05pathspec: only match across submodule boundaries when requestedBrandon Williams1-0/+19
Commit 74ed43711fd (grep: enable recurse-submodules to work on <tree> objects, 2016-12-16) taught 'tree_entry_interesting()' to be able to match across submodule boundaries in the presence of wildcards. This is done by performing literal matching up to the first wildcard and then punting to the submodule itself to perform more accurate pattern matching. Instead of introducing a new flag to request this behavior, commit 74ed43711fd overloaded the already existing 'recursive' flag in 'struct pathspec' to request this behavior. This leads to a bug where whenever any other caller has the 'recursive' flag set as well as a pathspec with wildcards that all submodules will be indicated as matches. One simple example of this is: git init repo cd repo git init submodule git -C submodule commit -m initial --allow-empty touch "[bracket]" git add "[bracket]" git commit -m bracket git add submodule git commit -m submodule git rev-list HEAD -- "[bracket]" Fix this by introducing the new flag 'recurse_submodules' in 'struct pathspec' and using this flag to determine if matches should be allowed to cross submodule boundaries. This fixes https://github.com/git-for-windows/git/issues/1371. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-04sha1_file: use strbuf_add() instead of strbuf_addf()Derrick Stolee1-0/+4
Replace use of strbuf_addf() with strbuf_add() when enumerating loose objects in for_each_file_in_obj_subdir(). Since we already check the length and hex-values of the string before consuming the path, we can prevent extra computation by using the lower- level method. One consumer of for_each_file_in_obj_subdir() is the abbreviation code. OID abbreviations use a cached list of loose objects (per object subdirectory) to make repeated queries fast, but there is significant cache load time when there are many loose objects. Most repositories do not have many loose objects before repacking, but in the GVFS case the repos can grow to have millions of loose objects. Profiling 'git log' performance in GitForWindows on a GVFS-enabled repo with ~2.5 million loose objects revealed 12% of the CPU time was spent in strbuf_addf(). Add a new performance test to p4211-line-log.sh that is more sensitive to this cache-loading. By limiting to 1000 commits, we more closely resemble user wait time when reading history into a pager. For a copy of the Linux repo with two ~512 MB packfiles and ~572K loose objects, running 'git log --oneline --parents --raw -1000' had the following performance: HEAD~1 HEAD ---------------------------------------- 7.70(7.15+0.54) 7.44(7.09+0.29) -3.4% Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-04print_sha1_ellipsis: introduce helperAnn T Ropea3-3/+3
Introduce a helper print_sha1_ellipsis() that pays attention to the GIT_PRINT_SHA1_ELLIPSIS environment variable, and prepare the tests to unconditionally set it for the test pieces that will be broken once the code stops showing the extra dots by default. The removal of these dots is merely a plan at this step and has not happened yet but soon will. Document GIT_PRINT_SHA1_ELLIPSIS. Signed-off-by: Ann T Ropea <bedhanger@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-02diffcore-rename: make diff-tree -l0 mean -l<large>Jonathan Tan1-0/+15
In the documentation of diff-tree, it is stated that the -l option "prevents rename/copy detection from running if the number of rename/copy targets exceeds the specified number". The documentation does not mention any special handling for the number 0, but the implementation before commit 9f7e4bfa3b ("diff: remove silent clamp of renameLimit", 2017-11-13) treated 0 as a special value indicating that the rename limit is to be a very large number instead. The commit 9f7e4bfa3b changed that behavior, treating 0 as 0. Revert this behavior to what it was previously. This allows existing scripts and tools that use "-l0" to continue working. The alternative (to have "-l0" suppress rename detection) is probably much less useful, since users can just refrain from specifying -M and/or -C to have the same effect. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-28Merge branch 'rs/include-comments-before-the-function-header'Junio C Hamano3-10/+38
"git grep -W", "git diff -W" and their friends learned a heuristic to extend a pre-context beyond the line that matches the "function pattern" (aka "diff.*.xfuncname") to include a comment block, if exists, that immediately precedes it. * rs/include-comments-before-the-function-header: grep: show non-empty lines before functions with -W grep: update boundary variable for pre-context t7810: improve check of -W with user-defined function lines xdiff: show non-empty lines before functions with -W xdiff: factor out is_func_rec() t4051: add test for comments preceding function lines
2017-11-28Merge branch 'ma/branch-list-paginate'Junio C Hamano1-0/+38
"git branch --list" learned to show its output through the pager by default when the output is going to a terminal, which is controlled by the pager.branch configuration variable. This is similar to a recent change to "git tag --list". * ma/branch-list-paginate: branch: change default of `pager.branch` to "on" branch: respect `pager.branch` in list-mode only t7006: add tests for how git branch paginates
2017-11-28Merge branch 'jc/branch-name-sanity'Junio C Hamano1-0/+43
"git branch" and "git checkout -b" are now forbidden from creating a branch whose name is "HEAD". * jc/branch-name-sanity: builtin/branch: remove redundant check for HEAD branch: correctly reject refs/heads/{-dash,HEAD} branch: split validate_new_branchname() into two branch: streamline "attr_only" handling in validate_new_branchname()
2017-11-28diff: support anchoring line(s)Jonathan Tan1-0/+94
Teach diff a new algorithm, one that attempts to prevent user-specified lines from appearing as a deletion or addition in the end result. The end user can use this by specifying "--anchored=<text>" one or more times when using Git commands like "diff" and "show". Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-27Merge branch 'ew/rebase-mboxrd'Junio C Hamano1-0/+22
When "git rebase" prepared an mailbox of changes and fed it to "git am" to replay them, it was confused when a stray "From " happened to be in the log message of one of the replayed changes. This has been corrected. * ew/rebase-mboxrd: rebase: use mboxrd format to avoid split errors
2017-11-27Merge branch 'tb/add-renormalize'Junio C Hamano1-0/+30
"git add --renormalize ." is a new and safer way to record the fact that you are correcting the end-of-line convention and other "convert_to_git()" glitches in the in-repository data. * tb/add-renormalize: add: introduce "--renormalize"
2017-11-27Merge branch 'rs/apply-inaccurate-eof-with-incomplete-line'Junio C Hamano1-0/+14
"git apply --inaccurate-eof" when used with "--ignore-space-change" triggered an internal sanity check, which has been fixed. * rs/apply-inaccurate-eof-with-incomplete-line: apply: update line lengths for --inaccurate-eof
2017-11-27Merge branch 'sb/test-cherry-pick-submodule-getting-in-a-way'Junio C Hamano1-0/+36
The three-way merge performed by "git cherry-pick" was confused when a new submodule was added in the meantime, which has been fixed (or "papered over"). * sb/test-cherry-pick-submodule-getting-in-a-way: merge-recursive: handle addition of submodule on our side of history t/3512: demonstrate unrelated submodule/file conflict as cherry-pick failure
2017-11-27Merge branch 'tz/notes-error-to-stderr'Junio C Hamano2-5/+5
"git notes" sent its error message to its standard output stream, which was corrected. * tz/notes-error-to-stderr: notes: send "Automatic notes merge failed" messages to stderr
2017-11-27Merge branch 'tz/redirect-fix'Junio C Hamano1-1/+1
A few scripts (both in production and tests) incorrectly redirected their error output. These have been corrected. * tz/redirect-fix: rebase: fix stderr redirect in apply_autostash() t/lib-gpg: fix gpgconf stderr redirect to /dev/null
2017-11-27Merge branch 'jc/ignore-cr-at-eol'Junio C Hamano1-0/+28
The "diff" family of commands learned to ignore differences in carriage return at the end of line. * jc/ignore-cr-at-eol: diff: --ignore-cr-at-eol xdiff: reassign xpparm_t.flags bits
2017-11-27t/README: document test_cmp_revThomas Gummerer1-0/+5
test_cmp_rev is a useful function that's used in quite a few test scripts. It is however not documented in t/README. Document it. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-27t/README: remove mention of adding copyright noticesThomas Gummerer1-4/+1
We generally no longer include copyright notices in new test scripts. However t/README still mentions it as something to include at the top of every new script. Remove that mention as it's outdated. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-27convert: tighten the safe autocrlf handlingTorsten Bögershausen1-5/+71
When a text file had been commited with CRLF and the file is commited again, the CRLF are kept if .gitattributs has "text=auto". This is done by analyzing the content of the blob stored in the index: If a '\r' is found, Git assumes that the blob was commited with CRLF. The simple search for a '\r' does not always work as expected: A file is encoded in UTF-16 with CRLF and commited. Git treats it as binary. Now the content is converted into UTF-8. At the next commit Git treats the file as text, the CRLF should be converted into LF, but isn't. Replace has_cr_in_index() with has_crlf_in_index(). When no '\r' is found, 0 is returned directly, this is the most common case. If a '\r' is found, the content is analyzed more deeply. Reported-By: Ashish Negi <ashishnegi33@gmail.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-27worktree: make add <path> <branch> dwimThomas Gummerer1-0/+19
Currently 'git worktree add <path> <branch>', errors out when 'branch' is not a local branch. It has no additional dwim'ing features that one might expect. Make it behave more like 'git checkout <branch>' when the branch doesn't exist locally, but a remote tracking branch uniquely matches the desired branch name, i.e. create a new branch from the remote tracking branch and set the upstream to the remote tracking branch. As 'git worktree add' currently just dies in this situation, there are no backwards compatibility worries when introducing this feature. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-27worktree: add --[no-]track option to the add subcommandThomas Gummerer1-0/+51
Currently 'git worktree add' sets up tracking branches if '<branch>' is a remote tracking branch, and doesn't set them up otherwise, as is the default for 'git branch'. This may or may not be what the user wants. Allow overriding this behaviour with a --[no-]track flag that gets passed through to 'git branch'. We already respect branch.autoSetupMerge, as 'git worktree' just calls 'git branch' internally. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-24t3512/t3513: remove KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1Phillip Wood2-2/+0
Now that the sequencer creates commits without forking 'git commit' it does not see an empty commit in these tests which fixes the known breakage. Note that logic for handling KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1 is not removed from lib-submodule-update.sh as it is still used by other tests. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-24grep: fix segfault under -P + PCRE2 <=10.30 + (*NO_JIT)Ævar Arnfjörð Bjarmason1-0/+6
Fix a bug in the compilation of PCRE2 patterns under JIT (the most common runtime configuration). Any pattern with a (*NO_JIT) verb would segfault in any currently released PCRE2 version: $ git grep -P '(*NO_JIT)hi.*there' Segmentation fault That this segfaulted was a bug in PCRE2 itself, after reporting it[1] on pcre-dev it's been fixed in a yet-to-be-released version of PCRE (presumably released first as 10.31). Now it'll die with: $ git grep -P '(*NO_JIT)hi.*there' fatal: pcre2_jit_match failed with error code -45: bad JIT option But the cause of the bug is in our own code dating back to my 94da9193a6 ("grep: add support for PCRE v2", 2017-06-01). As explained at more length in the comment being added here, it isn't sufficient to just check pcre2_config() to see whether the JIT should be used, pcre2_pattern_info() also has to be asked. This is something I discovered myself when fiddling around with PCRE2 verbs in patterns passed to git. I don't expect that any user of git has encountered this given the obscurity of passing PCRE2 verbs through to the library, along with the relative obscurity of (*NO_JIT) itself. 1. "How am I supposed to use PCRE2 JIT in the face of (*NO_JIT) ?" (<CACBZZX5mMqDuWuFmi7sRBp3wH6CFyd-ghACukd=v0NN=rBMnJg@mail.gmail.com> & https://lists.exim.org/lurker/thread/20171123.101502.7f0d38ca.en.html) on the pcre-dev mailing list Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-24test-lib: add LIBPCRE1 & LIBPCRE2 prerequisitesÆvar Arnfjörð Bjarmason2-0/+14
Add LIBPCRE1 and LIBPCRE2 prerequisites which are true when git is compiled with USE_LIBPCRE1=YesPlease or USE_LIBPCRE2=YesPlease, respectively. The syntax of PCRE1 and PCRE2 isn't the same in all cases (see pcresyntax(3) and pcre2syntax(3)). If test are added that test for those they'll need to be guarded by these new prerequisites. The subsequent patch will make use of LIBPCRE2, so LIBPCRE1 isn't strictly needed for now, but let's add it for consistency and so that checking for it doesn't have to be done with the less obvious "PCRE, !LIBPCRE2", which while semantically the same is more confusing, and would lead to bugs if PCRE v3 is ever released as the tests would mean v1, not any non-v2 version. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-24stash: learn to parse -m/--message like commit doesPhil Hord1-0/+93
`git stash push -m foo` uses "foo" as the message for the stash. But `git stash push -m"foo"` does not parse successfully. Similarly `git stash push --message="My stash message"` also fails. The stash documentation doesn't suggest this syntax should work, but gitcli does and my fingers have learned this pattern long ago for `commit`. Teach `git stash` to parse -mFoo and --message=Foo the same as `git commit` would do. Even though it's an internal function, add similar support to create_stash() for consistency. Signed-off-by: Phil Hord <phil.hord@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-22Git/Packet: clarify that packet_required_key_val_read allows EOFChristian Couder1-2/+2
The function calls itself "required", but it does not die when it sees an unexpected EOF. Let's rename it to "packet_key_val_read()". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-22pack-objects: add list-objects filteringJeff Hostetler1-0/+375
Teach pack-objects to use the filtering provided by the traverse_commit_list_filtered() interface to omit unwanted objects from the resulting packfile. Filtering requires the use of the "--stdout" option. Add t5317 test. In the future, we will introduce a "partial clone" mechanism wherein an object in a repo, obtained from a remote, may reference a missing object that can be dynamically fetched from that remote once needed. This "partial clone" mechanism will have a way, sometimes slow, of determining if a missing link is one of the links expected to be produced by this mechanism. This patch introduces handling of missing objects to help debugging and development of the "partial clone" mechanism, and once the mechanism is implemented, for a power user to perform operations that are missing-object aware without incurring the cost of checking if a missing link is expected. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-22rev-list: add list-objects filtering supportJeff Hostetler1-0/+225
Teach rev-list to use the filtering provided by the traverse_commit_list_filtered() interface to omit unwanted objects from the result. Object filtering is only allowed when one of the "--objects*" options are used. When the "--filter-print-omitted" option is used, the omitted objects are printed at the end. These are marked with a "~". This option can be combined with "--quiet" to get a list of just the omitted objects. Add t6112 test. In the future, we will introduce a "partial clone" mechanism wherein an object in a repo, obtained from a remote, may reference a missing object that can be dynamically fetched from that remote once needed. This "partial clone" mechanism will have a way, sometimes slow, of determining if a missing link is one of the links expected to be produced by this mechanism. This patch introduces handling of missing objects to help debugging and development of the "partial clone" mechanism, and once the mechanism is implemented, for a power user to perform operations that are missing-object aware without incurring the cost of checking if a missing link is expected. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-22Tests: clean up submodule recursive helpersJonathan Tan1-218/+125
This continues the work in commit d3b5a49 ("Tests: clean up and document submodule helpers", 2017-11-08). Factor out the commonalities from test_submodule_switch_recursing_with_args() and test_submodule_forced_switch_recursing_with_args() in lib-submodule-update.sh, and document their usage. Some tests differ slightly in their test assertions; I have used the superset of those assertions in that case. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-22log: add option to choose which refs to decorateRafael Ascensão1-0/+101
When `log --decorate` is used, git will decorate commits with all available refs. While in most cases this may give the desired effect, under some conditions it can lead to excessively verbose output. Introduce two command line options, `--decorate-refs=<pattern>` and `--decorate-refs-exclude=<pattern>` to allow the user to select which refs are used in decoration. When "--decorate-refs=<pattern>" is given, only the refs that match the pattern are used in decoration. The refs that match the pattern when "--decorate-refs-exclude=<pattern>" is given, are never used in decoration. These options follow the same convention for mixing negative and positive patterns across the system, assuming that the inclusive default is to match all refs available. (1) if there is no positive pattern given, pretend as if an inclusive default positive pattern was given; (2) for each candidate, reject it if it matches no positive pattern, or if it matches any one of the negative patterns. The rules for what is considered a match are slightly different from the rules used elsewhere. Commands like `log --glob` assume a trailing '/*' when glob chars are not present in the pattern. This makes it difficult to specify a single ref. On the other hand, commands like `describe --match --all` allow specifying exact refs, but do not have the convenience of allowing "shorthand refs" like 'refs/heads' or 'heads' to refer to 'refs/heads/*'. The commands introduced in this patch consider a match if: (a) the pattern contains globs chars, and regular pattern matching returns a match. (b) the pattern does not contain glob chars, and ref '<pattern>' exists, or if ref exists under '<pattern>/' This allows both behaviours (allowing single refs and shorthand refs) yet remaining compatible with existent commands. Helped-by: Kevin Daudt <me@ikke.info> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-21Merge branch 'av/fsmonitor'Junio C Hamano2-11/+18
Various fixes to bp/fsmonitor topic. * av/fsmonitor: fsmonitor: simplify determining the git worktree under Windows fsmonitor: store fsmonitor bitmap before splitting index fsmonitor: read from getcwd(), not the PWD environment variable fsmonitor: delay updating state until after split index is merged fsmonitor: document GIT_TRACE_FSMONITOR fsmonitor: don't bother pretty-printing JSON from watchman fsmonitor: set the PWD to the top of the working tree