kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
brian m. carlson	69e104d70e	doc: provide guidance on user.name format It's a frequent misconception that the user.name variable controls authentication in some way, and as a result, beginning users frequently attempt to change it when they're having authentication troubles. Document that the convention is that this variable represents some form of a human's personal name, although that is not required. In addition, address concerns about whether Unicode is supported. Use the term "personal name" as this is likely to draw the intended contrast, be applicable across cultures which may have different naming conventions, and be easily understandable to people who do not speak English as their first language. Indicate that "some form" is conventionally used, as people may use a nickname or preferred name instead of a full legal name. Point users who may be confused about authentication to an appropriate configuration option instead. Provide a shortened form of this information in the configuration option description. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
brian m. carlson	813f6025a5	docs: expand on possible and recommended user config options In the section on setting author and committer information, we omit the author.* and committer.* variables, so mention them for completeness. In addition, guide users to the typical case: simply setting user.name and user.email, which are recommended if one does not need complex configuration. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
brian m. carlson	bc94e5862a	doc: move author and committer information to git-commit(1) While at one time it made perfect sense to store information about configuring author and committer information in the documentation for git commit-tree, in modern Git that operation is seldom used. Most users will use git commit and expect to find comprehensive documentation about its use in the manual page for that command. Considering that there is significant confusion about how one is to use the user.name and user.email variables, let's put as much documentation as possible into an obvious place where users will be more likely to find it. In addition, expand the environment variables section to describe their use more fully. Even though we now describe all of the options there and in the configuration settings documentation, preserve the existing text in git-commit.txt so that people can easily reason about the ordering of the various options they can use. Explain the use of the author.* and committer.* options as well. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
brian m. carlson	856249c62a	docs: use "currently" for the present time In many languages, the adverb with the root "actual" means "at the present time." However, this usage is considered dated or even archaic in English, and for referring to events occurring at the present time, we usually prefer "currently" or "presently". "Actually" is commonly used in modern English only for the meaning of "in fact" or to express a contrast with what is expected. Since the documentation refers to the available options at the present time (that is, at the time of writing) instead of drawing a contrast, let's switch to "currently," which both is commonly used and sounds less formal than "presently." Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Derrick Stolee	b40a50264a	fetch: document and test --refmap="" To prevent long blocking time during a 'git fetch' call, a user may want to set up a schedule for background 'git fetch' processes. However, these runs will update the refs/remotes branches due to the default refspec set in the config when Git adds a remote. Hence the user will not notice when remote refs are updated during their foreground fetches. In fact, they may _want_ those refs to stay put so they can work with the refs from their last foreground fetch call. This can be accomplished by overriding the configured refspec using '--refmap=' along with a custom refspec: git fetch --refmap='' <remote> +refs/heads/:refs/hidden/<remote>/ to populate a custom ref space and download a pack of the new reachable objects. This kind of call allows a few things to happen: 1. We download a new pack if refs have updated. 2. Since the refs/hidden branches exist, GC will not remove the newly-downloaded data. 3. With fetch.writeCommitGraph enabled, the refs/hidden refs are used to update the commit-graph file. To avoid the refs/hidden directory from filling without bound, the --prune option can be included. When providing a refspec like this, the --prune option does not delete remote refs and instead only deletes refs in the target refspace. Update the documentation to clarify how '--refmap=""' works and create tests to guarantee this behavior remains in the future. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Junio C Hamano	232378479e	Sync with maint * maint: msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.x	5 years ago
Jeff King	e4837b4406	t7800: don't rely on reuse_worktree_file() A test in t7800 tries to make sure that when git-difftool runs an external tool that fails, it stops looking at files. Our fake failing tool prints the file name it was asked to diff before exiting non-zero, and then we confirm the output contains only that file. However, this subtly relies on our internal reuse_worktree_file(). Because we're diffing between branches, the command run by difftool might see: - the git-stored filename (e.g., "file"), if we decided that the working tree contents were up-to-date with the object in the index and HEAD, and we could reuse them - a temporary filename (e.g. "/tmp/abc123_file") if we had to dump the contents from the object database If the latter case happens, then the test fails, because it's expecting the string "file". I discovered this when debugging something unrelated with reuse_worktree_file(). I _thought_ it should be able to be triggered by a racy-git situation, but running: ./t7800-difftool.sh --stress --run=2,13 never seems to fail. However, by my reading of reuse_worktree_file(), this would probably always fail under Cygwin, because it sets NO_FAST_WORKING_DIRECTORY. At any rate, since reuse_worktree_file() is meant to be an optimization that may or may not trigger, our test should be robust either way. Instead of checking the filename, let's just make sure we got a single line of output (which would not be true if we continued after the first failure). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jeff King	fbce03d329	t4018: drop "debugging" cat from hunk-header tests We run a series of hunk-header tests in a loop, and each one does this: test_when_finished 'cat actual' && # for debugging only This is pretty pointless. When the test succeeds, we waste time running a useless cat process. If you're debugging a failure with "-i", then we won't run the when-finished part at all. So it helps only if you're running with something like "--verbose-log". Since we expect the tests to succeed most of the time, a better way to do this would be a helper that checks the output and dumps "actual" only when it fails. But it's probably not even worth the effort, as anyone debugging a failure could just run with "-i" and investigate the "actual" file themselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jeff King	f65d07fffa	Makefile: use compat regex with SANITIZE=address Recent versions of the gcc and clang Address Sanitizer produce test failures related to regexec(). This triggers with gcc-10 and clang-8 (but not gcc-9 nor clang-7). Running: make CC=gcc-10 SANITIZE=address test results in failures in t4018, t3206, and t4062. The cause seems to be that when built with ASan, we use a different version of regexec() than normal. And this version doesn't understand the REG_STARTEND flag. Here's my evidence supporting that. The failure in t4062 is an ASan warning: expecting success of 4062.2 '-G matches': git diff --name-only -G "^(0{64}){64}$" HEAD^ >out && test 4096-zeroes.txt = "$(cat out)" ================================================================= ==672994==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fa76f672000 at pc 0x7fa7726f75b6 bp 0x7ffe41bdda70 sp 0x7ffe41bdd220 READ of size 4097 at 0x7fa76f672000 thread T0 #0 0x7fa7726f75b5 (/lib/x86_64-linux-gnu/libasan.so.6+0x4f5b5) #1 0x562ae0c9c40e in regexec_buf /home/peff/compile/git/git-compat-util.h:1117 #2 0x562ae0c9c40e in diff_grep /home/peff/compile/git/diffcore-pickaxe.c:52 #3 0x562ae0c9cc28 in pickaxe_match /home/peff/compile/git/diffcore-pickaxe.c:166 [...] In this case we're looking in a buffer which was mmap'd via reuse_worktree_file(), and whose size is 4096 bytes. But libasan's regex tries to look at byte 4097 anyway! If we tweak Git like this: diff --git a/diff.c b/diff.c index 8e2914c031..cfae60c120 100644 --- a/diff.c +++ b/diff.c @@ -3880,7 +3880,7 @@ static int reuse_worktree_file(struct index_state istate, / if (ce_uptodate(ce) \|\| (!lstat(name, &st) && !ie_match_stat(istate, ce, &st, 0))) - return 1; + return 0; return 0; } to use a regular buffer (with a trailing NUL) instead of an mmap, then the complaint goes away. The other failures are actually diff output with an incorrect funcname header. If I instrument xdiff to show the funcname matching like so: diff --git a/xdiff-interface.c b/xdiff-interface.c index 8509f9ea22..f6c3dc1986 100644 --- a/xdiff-interface.c +++ b/xdiff-interface.c @@ -197,6 +197,7 @@ struct ff_regs { struct ff_reg { regex_t re; int negate; + char printable; } array; }; @@ -218,7 +219,12 @@ static long ff_regexp(const char line, long len, for (i = 0; i < regs->nr; i++) { struct ff_reg reg = regs->array + i; - if (!regexec_buf(&reg->re, line, len, 2, pmatch, 0)) { + int ret = regexec_buf(&reg->re, line, len, 2, pmatch, 0); + warning("regexec %s:\n regex: %s\n buf: %.s", + ret == 0 ? "matched" : "did not match", + reg->printable, + (int)len, line); + if (!ret) { if (reg->negate) return -1; break; @@ -264,6 +270,7 @@ void xdiff_set_find_func(xdemitconf_t xecfg, const char value, int cflags) expression = value; if (regcomp(&reg->re, expression, cflags)) die("Invalid regexp to look for hunk header: %s", expression); + reg->printable = xstrdup(expression); free(buffer); value = ep + 1; } then when compiling with ASan and gcc-10, running the diff from t4018.66 produces this: $ git diff -U1 cpp-skip-access-specifiers warning: regexec did not match: regex: ^[ ][A-Za-z_][A-Za-z_0-9]:[[:space:]]($\|/[/]) buf: private: warning: regexec matched: regex: ^((::[[:space:]])?[A-Za-z_].)$ buf: private: diff --git a/cpp-skip-access-specifiers b/cpp-skip-access-specifiers index 4d4a9db..ebd6f42 100644 --- a/cpp-skip-access-specifiers +++ b/cpp-skip-access-specifiers @@ -6,3 +6,3 @@ private: void DoSomething(); int ChangeMe; }; void DoSomething(); - int ChangeMe; + int IWasChanged; }; That first regex should match (and is negated, so it should be telling us _not_ to match "private:"). But it wouldn't if regexec() is looking at the whole buffer, and not just the length-limited line we've fed to regexec_buf(). So this is consistent again with REG_STARTEND being ignored. The correct output (compiling without ASan, or gcc-9 with Asan) looks like this: warning: regexec matched: regex: ^[ ][A-Za-z_][A-Za-z_0-9]:[[:space:]]($\|/[/]) buf: private: [...more lines that we end up not using...] warning: regexec matched: regex: ^((::[[:space:]])?[A-Za-z_].*)$ buf: class RIGHT : public Baseclass diff --git a/cpp-skip-access-specifiers b/cpp-skip-access-specifiers index 4d4a9db..ebd6f42 100644 --- a/cpp-skip-access-specifiers +++ b/cpp-skip-access-specifiers @@ -6,3 +6,3 @@ class RIGHT : public Baseclass void DoSomething(); - int ChangeMe; + int IWasChanged; }; So it really does seem like libasan's regex engine is ignoring REG_STARTEND. We should be able to work around it by compiling with NO_REGEX, which would use our local regexec(). But to make matters even more interesting, this isn't enough by itself. Because ASan has support from the compiler, it doesn't seem to intercept our call to regexec() at the dynamic library level. It actually recognizes when we are compiling a call to regexec() and replaces it with ASan-specific code at that point. And unlike most of our other compat code, where we might have git_mmap() or similar, the actual symbol name in the compiled compat/regex code is regexec(). So just compiling with NO_REGEX isn't enough; we still end up in libasan! We can work around that by having the preprocessor replace regexec with git_regexec (both in the callers and in the actual implementation), and we truly end up with a call to our custom regex code, even when compiling with ASan. That's probably a good thing to do anyway, as it means anybody looking at the symbols later (e.g., in a debugger) would have a better indication of which function is which. So we'll do the same for the other common regex functions (even though just regexec() is enough to fix this ASan problem). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Johannes Schindelin	849e43cc18	built-in add -i: accept open-ended ranges again The interactive `add` command allows selecting multiple files for some of its sub-commands, via unique prefixes, indices or index ranges. When re-implementing `git add -i` in C, we even added a code comment talking about ranges with a missing end index, such as `2-`, but the code did not actually accept those, as pointed out in https://github.com/git-for-windows/git/issues/2466#issuecomment-574142760. Let's fix this, and add a test case to verify that this stays fixed forever. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Johannes Schindelin	d660a30ceb	built-in add -i: do not try to `patch`/`diff` an empty list of files When the user does not select any files to `patch` or `diff`, there is no need to call `run_add_p()` on them. Even worse: we _have_ to avoid calling `parse_pathspec()` with an empty list because that would trigger this error: BUG: pathspec.c:557: PATHSPEC_PREFER_CWD requires arguments So let's avoid doing any work on a list of files that is empty anyway. This fixes https://github.com/git-for-windows/git/issues/2466. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Ralf Thielow	a4ffbbbb99	submodule.c: mark more strings for translation Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jeff King	0cbb60574e	dir: point treat_leading_path() warning to the right place Commit `777b420347` (dir: synchronize treat_leading_path() and read_directory_recursive(), 2019-12-19) tried to add two warning comments in those functions, pointing at each other. But the one in treat_leading_path() just points at itself. Let's fix that. Since the comment also redirects the reader for more details to "the commit that added this warning", and since we're now modifying the warning (creating a new commit without those details), let's mention the actual commit id. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jeff King	ad6f2157f9	dir: restructure in a way to avoid passing around a struct dirent Restructure the code slightly to avoid passing around a struct dirent anywhere, which also enables us to avoid trying to manufacture one. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Elijah Newren	22705334b9	dir: treat_leading_path() and read_directory_recursive(), round 2 I was going to title this "dir: more synchronizing of treat_leading_path() and read_directory_recursive()", a nod to commit `777b420347` ("dir: synchronize treat_leading_path() and read_directory_recursive()", 2019-12-19), but the title was too long. Anyway, first the backstory... fill_directory() has always had a slightly error-prone interface: it returns a subset of paths which might match the specified pathspec; it was intended to prune away some paths which didn't match the specified pathspec and keep at least all the ones that did match it. Given this interface, callers were responsible to post-process the results and check whether each actually matched the pathspec. builtin/clean.c did this. It would first prune out duplicates (e.g. if "dir" was returned as well as all files under "dir/", then it would simplify this to just "dir"), and after pruning duplicates it would compare the remaining paths to the specified pathspec(s). This post-processing itself could run into problems, though, as noted in commit `404ebceda0` ("dir: also check directories for matching pathspecs", 2019-09-17): For the case of git-clean and a set of pathspecs of "dir/file" and "more", this caused a problem because we'd end up with dir entries for both of "dir" "dir/file" Then correct_untracked_entries() would try to helpfully prune duplicates for us by removing "dir/file" since it's under "dir", leaving us with "dir" Since the original pathspec only had "dir/file", the only entry left doesn't match and leaves nothing to be removed. (Note that if only one pathspec was specified, e.g. only "dir/file", then the common_prefix_len optimizations in fill_directory would cause us to bypass this problem, making it appear in simple tests that we could correctly remove manually specified pathspecs.) That commit fixed the issue -- when multiple pathspecs were specified -- by making sure fill_directory() wouldn't return both "dir" and "dir/file" outside the common_prefix_len optimization path. This is where it starts to get fun. In commit `b9670c1f5e` ("dir: fix checks on common prefix directory", 2019-12-19), we noticed that the common_prefix_len wasn't doing appropriate checks and letting all kinds of stuff through, resulting in recursing into .git/ directories and other craziness. So it started locking down and doing checks on pathnames within that code path. That continued with commit `777b420347` ("dir: synchronize treat_leading_path() and read_directory_recursive()", 2019-12-19), which noted the following: Our optimization to avoid calling into read_directory_recursive() when all pathspecs have a common leading directory mean that we need to match the logic that read_directory_recursive() would use if we had just called it from the root. Since it does more than call treat_path() we need to copy that same logic. ...and then it more forcefully addressed the issue with this wonderfully ironic statement: Needing to duplicate logic like this means it is guaranteed someone will eventually need to make further changes and forget to update both locations. It is tempting to just nuke the leading_directory special casing to avoid such bugs and simplify the code, but unpack_trees' verify_clean_subdirectory() also calls read_directory() and does so with a non-empty leading path, so I'm hesitant to try to restructure further. Add obnoxious warnings to treat_leading_path() and read_directory_recursive() to try to warn people of such problems. You would think that with such a strongly worded description, that its author would have actually ensured that the logic in treat_leading_path() and read_directory_recursive() did actually match and that everything that was needed had at least been copied over at the time that this paragraph was written. But you'd be wrong, I messed it up by missing part of the logic. Copy the missing bits to fix the new final test in t7300. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Derrick Stolee	f365bf40a0	clean: demonstrate a bug with pathspecs `b9670c1f5e` (dir: fix checks on common prefix directory, 2019-12-19) modified the way pathspecs are handled when handling a directory during "git clean -f <path>". While this improved the behavior for known test breakages, it also regressed in how the clean command handles cleaning a specified file. Add a test case that demonstrates this behavior. This test passes before `b9670c1f5e` then fails after. Helped-by: Kevin Willford <Kevin.Willford@microsoft.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Johannes Schindelin	b6d4d82bd5	msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.x With the upgrade, the library names changed from libeay32/ssleay32 to libcrypto/libssl. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Junio C Hamano	d0654dc308	Git 2.25 Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Junio C Hamano	b4615e40a8	l10n-2.25.0-rnd1 -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEET/4dIHc7EQTOoGRdx6TpG3VEeigFAl4bB9IACgkQx6TpG3VE eihn9A/+I6kS5cYJjD5TjMJ8cauEF6zPtBeAFJ+VD9eLI2NnByn1O+HXmAgUICaZ eNbu/xJS8XPKv7ks/zzW+bwkngQZrcg7IEePyLSj2zOG74BI+Wa6uRTd6wM09Z1/ y86yi/cxQrKaZK/hiuRw5hk+1WU7ddVfKofenrqMjb3NlXtaEzz7TtawSW/LxXcm futdHvcQlNnqzrNVtC4qqNxfc0GJBrOMPOXtPXYGn/KVjuSyXrFzOMUjM4frlPXA YGYTpQN2kCp6Lri8ytATOpM9WijaaUqh/MBZEiLIAF1hWL1xDZyhbHut+C6YOi39 plZqfHmSOavwiD+fpdteUcIhnMA0NTcKno6v2TZmS+pgxU5VKnrrNvgsva2v3OAj 9hFU4syi5DIR2oDrYb7FiWgz+gz5x+8vemF1JhcvmBdB3pWTqxF/crOmmljzj+Hc AYFQPA0dgoNbBN5T5yURSnHb2unfPAqWtS0YOjw325QfYB2WFLdqaKhGrlVwMuzr QkxuIr4jswu8ojkl5obf2T2gbr4Zp1OGdH+RivKtk54GuSbUR/kbijftBofLL+Kh b+9lYOwATMxhfRrY92dCDtBADI7BknNSVjBdN3OWEPbv+5OCPjbZmoGJoe+G6lWt 4IBnDqNtucalrPR19D6s+p8mcrGqzvE6OrOkzswZjZDnd3p57LQ= =t/g1 -----END PGP SIGNATURE----- Merge tag 'l10n-2.25.0-rnd1' of git://github.com/git-l10n/git-po l10n-2.25.0-rnd1 * tag 'l10n-2.25.0-rnd1' of git://github.com/git-l10n/git-po: l10n: zh_CN: for git v2.25.0 l10n round 1 l10n: Update Catalan translation l10n: de.po: Update German translation v2.25.0 round 1 l10n: de.po: Reword generation numbers l10n: bg.po: Updated Bulgarian translation (4800t) l10n: es: 2.25.0 round #1 l10n: sv.po: Update Swedish translation (4800t0f0u) l10n: fr.po v2.25.0 rnd 1 l10n: vi(4800t): Updated Vietnamese translation v2.25.0 l10n: zh_TW.po: update translation for v2.25.0 round 1 l10n: it.po: update the Italian translation for Git 2.25.0 l10n: git.pot: v2.25.0 round 1 (119 new, 13 removed) l10n: Update Catalan translation l10n: zh_TW: add translation for v2.24.0	5 years ago
Junio C Hamano	4d924528d8	Revert "Merge branch 'ra/rebase-i-more-options'" This reverts commit `5d9324e0f4`, reversing changes made to `c58ae96fc4`. The topic turns out to be too buggy for real use. cf. <f2fe7437-8a48-3315-4d3f-8d51fe4bb8f1@gmail.com>	5 years ago
Jiang Xin	ddc12c429b	l10n: zh_CN: for git v2.25.0 l10n round 1 Translate 119 new messages (4800t0f0u) for git 2.25.0. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>	5 years ago
Jiang Xin	e23b95e75b	Merge branch 'master' of github.com:Softcatala/git-po into git-po-master * 'master' of github.com:Softcatala/git-po: l10n: Update Catalan translation	5 years ago
Junio C Hamano	1cf4836865	Merge branch 'js/mingw-loosen-overstrict-tree-entry-checks' Further tweak to a "no backslash in indexed paths" for Windows port we applied earlier. * js/mingw-loosen-overstrict-tree-entry-checks: mingw: safeguard better against backslashes in file names	5 years ago
Junio C Hamano	d78a1968c5	Merge branch 'ma/config-advice-markup-fix' Documentation markup fix. * ma/config-advice-markup-fix: config/advice.txt: fix description list separator	5 years ago
Jordi Mas	a20ae3ee29	l10n: Update Catalan translation Signed-off-by: Jordi Mas <jmas@softcatala.org>	5 years ago
Johannes Schindelin via GitGitGadget	49e268e23e	mingw: safeguard better against backslashes in file names In `224c7d70fa` (mingw: only test index entries for backslashes, not tree entries, 2019-12-31), we relaxed the check for backslashes in tree entries to check only index entries. However, the code change was incorrect: it was added to `add_index_entry_with_check()`, not to `add_index_entry()`, so under certain circumstances it was possible to side-step the protection. Besides, the description of that commit purported that all index entries would be checked when in fact they were only checked when being added to the index (there are code paths that do not do that, constructing "transient" index entries). In any case, it was pointed out in one insightful review at https://github.com/git-for-windows/git/pull/2437#issuecomment-566771835 that it would be a much better idea to teach `verify_path()` to perform the check for a backslash. This is safer, even if it comes with two notable drawbacks: - `verify_path()` cannot say _what_ is wrong with the path, therefore the user will no longer be told that there was a backslash in the path, only that the path was invalid. - The `git apply` command also calls the `verify_path()` function, and might have been able to handle Windows-style paths (i.e. with backslashes instead of forward slashes). This will no longer be possible unless the user (temporarily) sets `core.protectNTFS=false`. Note that `git add <windows-path>` will _still_ work because `normalize_path_copy_len()` will convert the backslashes to forward slashes before hitting the code path that creates an index entry. The clear advantage is that `verify_path()`'s purpose is to check the validity of the file name, therefore we naturally tap into all the code paths that need safeguarding, also implicitly into future code paths. The benefits of that approach outweigh the downsides, so let's move the check from `add_index_entry_with_check()` to `verify_path()`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Derrick Stolee via GitGitGadget	4c6c7971e0	unpack-trees: correctly compute result count The clear_ce_flags_dir() method processes the cache entries within a common directory. The returned int is the number of cache entries processed by that directory. When using the sparse-checkout feature in cone mode, we can skip the pattern matching for entries in the directories that are entirely included or entirely excluded. `eb42feca` (unpack-trees: hash less in cone mode, 2019-11-21) introduced this performance feature. The old mechanism relied on the counts returned by calling clear_ce_flags_1(), but the new mechanism calculated the number of rows by subtracting "cache_end" from "cache" to find the size of the range. However, the equation is wrong because it divides by sizeof(struct cache_entry ). This is not how pointer arithmetic works! A coverity build of Git for Windows in preparation for the 2.25.0 release found this issue with the warning, "Pointer differences, such as cache_end - cache, are automatically scaled down by the size (8 bytes) of the pointed-to type (struct cache_entry ). Most likely, the division by sizeof(struct cache_entry *) is extraneous and should be eliminated." This warning is correct. This leaves us with the question "how did this even work?" The problem that occurs with this incorrect pointer arithmetic is a performance-only bug, and a very slight one at that. Since the entry count returned by clear_ce_flags_dir() is reduced by a factor of 8, the loop in clear_ce_flags_1() will re-process entries from those directories. By inserting global counters into unpack-tree.c and tracing them with trace2_data_intmax() (in a private change, for testing), I was able to see count how many times the loop inside clear_ce_flags_1() processed an entry and how many times clear_ce_flags_dir() was called. Each of these are reduced by at least a factor of 8 with the current change. A factor larger than 8 happens when multiple levels of directories are repeated. Specifically, in the Linux kernel repo, the command git sparse-checkout set LICENSES restricts the working directory to only the files at root and in the LICENSES directory. Here are the measured counts: clear_ce_flags_1 loop blocks: Before: 11,520 After: 1,621 clear_ce_flags_dir calls: Before: 7,048 After: 606 While these are dramatic counts, the time spent in clear_ce_flags_1() is under one millisecond in each case, so the improvement is not measurable as an end-to-end time. Reported-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Matthias Rüster	63a5650a49	l10n: de.po: Update German translation v2.25.0 round 1 Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com> Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> Reviewed-by: Phillip Szelat <phillip.szelat@gmail.com>	5 years ago
Thomas Braun	75449c1b39	l10n: de.po: Reword generation numbers The english term generation is here not used in the sense of "to generate" but in the sense of "generations of beings". This corrects the initial translation from `cf4c0c25` (l10n: update German translation, 2018-12-06). Fixed-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>	5 years ago
Alexander Shopov	6b6a9803fb	l10n: bg.po: Updated Bulgarian translation (4800t) Signed-off-by: Alexander Shopov <ash@kambanaria.org>	5 years ago
Martin Ågren	3901d2c6bd	config/advice.txt: fix description list separator The whole submoduleAlternateErrorStrategyDie item is interpreted as being part of the supporting content of the preceding item. This is because we don't give a double-colon "::" for the separator, but just a single colon, ":". Let's fix that. There are a few other matches for [^:]:\s*$ in Documentation/config, but I didn't spot any similar bugs among them. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Junio C Hamano	7a6a90c6ec	Git 2.25-rc2 Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Junio C Hamano	1f5f3ffe5c	Merge branch 'ds/graph-assert-fix' Since recent updates to the log graph rendering code, drawing certain merges started triggering an assert on a condition that would no longer hold true, which has been corrected. * ds/graph-assert-fix: graph: fix lack of color in horizontal lines graph: drop assert() for merge with two collapsing parents	5 years ago
Junio C Hamano	a4e4140ac9	Merge branch 'tm/doc-submodule-absorb-fix' Typofix. * tm/doc-submodule-absorb-fix: doc: submodule: fix typo for command absorbgitdirs	5 years ago
Junio C Hamano	202f68b252	Merge branch 'pm/am-in-body-header-doc-update' Doc update. * pm/am-in-body-header-doc-update: am: document that Date: can appear as an in-body header	5 years ago
Junio C Hamano	7e65f8638e	Merge branch 'jb/doc-multi-pack-idx-fix' Typofix. * jb/doc-multi-pack-idx-fix: multi-pack-index: correct configuration in documentation	5 years ago
Junio C Hamano	c5dc20638b	Merge branch 'do/gitweb-typofix-in-comments' Typofix. * do/gitweb-typofix-in-comments: gitweb: fix a couple spelling errors in comments	5 years ago
Junio C Hamano	fe47c9cb5f	Merge https://github.com/prati0100/git-gui * https://github.com/prati0100/git-gui: git-gui: allow opening currently selected file in default app git-gui: allow closing console window with Escape git gui: fix branch name encoding error git-gui: revert untracked files by deleting them git-gui: update status bar to track operations git-gui: consolidate naming conventions	5 years ago
Derrick Stolee	a1087c9367	graph: fix lack of color in horizontal lines In some cases, horizontal lines in rendered graphs can lose their coloring. This is due to a use of graph_line_addch() instead of graph_line_write_column(). Using a ternary operator to pick the character is nice for compact code, but we actually need a column to provide the color. Add a test to t4215-log-skewed-merges.sh to prevent regression. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Derrick Stolee	0d251c3291	graph: drop assert() for merge with two collapsing parents When "git log --graph" shows a merge commit that has two collapsing lines, like: \| \| \| \| * \| \|_\|_\|/\| \|/\| \| \|/ \| \| \|/\| \| \|/\| \| \| * \| \| * \| \| \| we trigger an assert(): graph.c:1228: graph_output_collapsing_line: Assertion `graph->mapping[i - 3] == target' failed. The assert was introduced by `eaf158f8` ("graph API: Use horizontal lines for more compact graphs", 2009-04-21), which is quite old. This assert is trying to say that when we complete a horizontal line with a single slash, it is because we have reached our target. It is actually the _second_ collapsing line that hits this assert. The reason we are in this code path is because we are collapsing the first line, and in that case we are hitting our target now that the horizontal line is complete. However, the second line cannot be a horizontal line, so it will collapse without horizontal lines. In this case, it is inappropriate to assert that we have reached our target, as we need to continue for another column before reaching the target. Dropping the assert is safe here. The new behavior in `0f0f389f12` (graph: tidy up display of left-skewed merges, 2019-10-15) caused the behavior change that made this assertion failure possible. In addition to making the assert possible, it also changed how multiple edges collapse. In a larger example, the current code will output a collapse as follows: \| \| \| \| \| \| * \| \|_\|_\|_\|_\|/\|\ \|/\| \| \| \| \|/ / \| \| \| \| \|/\| / \| \| \| \|/\| \|/ \| \| \|/\| \|/\| \| \|/\| \|/\| \| \| \| \|/\| \| \| \| \| * \| \| \| However, the intended collapse should allow multiple horizontal lines as follows: \| \| \| \| \| \| * \| \|_\|_\|_\|_\|/\|\ \|/\| \| \| \| \|/ / \| \| \|_\|_\|/\| / \| \|/\| \| \| \|/ \| \| \| \|_\|/\| \| \| \|/\| \| \| \| \| * \| \| \| This behavior is not corrected by this change, but is noted for a later update. Helped-by: Jeff King <peff@peff.net> Reported-by: Bradley Smith <brad@brad-smith.co.uk> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jeff King	4d8cab95cc	transport: don't flush when disconnecting stateless-rpc helper Since `ba227857d2` (Reduce the number of connects when fetching, 2008-02-04), when we disconnect a git transport, we send a final flush packet. This cleanly tells the other side that we're done, and avoids the other side complaining "the remote end hung up unexpectedly" (though we'd only see that for transports that pass along the server stderr, like ssh or local-host). But when we've initiated a v2 stateless-connect session over a transport helper, there's no point in sending this flush packet. Each operation we've performed is self-contained, and the other side is fine with us hanging up between operations. But much worse, by sending the flush packet we may cause the helper to issue an entirely new request _just_ to send the flush packet. So we can incur an extra network request just to say "by the way, we have nothing more to send". Let's drop this extra flush packet. As the test shows, this reduces the number of POSTs required for a v2 ls-remote over http from 2 to 1. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Emily Shaffer	573117dfa5	unpack-trees: watch for out-of-range index position It's possible in a case where the index file contains a tree extension but no blobs within that tree exist for index_pos_by_traverse_info() to segfault. If the name_entry passed into index_pos_by_traverse_info() has no blobs inside, AND is alphabetically later than all blobs currently in the index file, index_pos_by_traverse_info() will segfault. For example, an index file which looks something like this: aaa#0 bbb/aaa#0 [Extensions] TREE: zzz In this example, 'index_name_pos(..., "zzz/", ...)' will return '-4', indicating that "zzz/" could be inserted at position 3. However, when the checks which ensure that the insertion position of "zzz/" look for a blob at that position beginning with "zzz/", the index cache is accessed out of range, causing a segfault. This kind of index state is not typically generated during user operations, and is in fact an edge case of the state being checked for in the conditional where it was added. However, since the entry for the BUG() line is ambiguous, tell some additional context to help Git developers debug the failure later. When we know the name of the dir we were trying to look up, it becomes possible to examine the index file in a hex util to determine what went wrong; the position gives a hint about where to start looking. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Jeff King	e701bab3e9	restore: invalidate cache-tree when removing entries with --staged When "git restore --staged <path>" removes a path that's in the index, it marks the entry with CE_REMOVE, but we don't do anything to invalidate the cache-tree. In the non-staged case, we end up in checkout_worktree(), which calls remove_marked_cache_entries(). That actually drops the entries from the index, as well as invalidating the cache-tree and untracked-cache. But with --staged, we never call checkout_worktree(), and the CE_REMOVE entries remain. Interestingly, they are dropped when we write out the index, but that means the resulting index is inconsistent: its cache-tree will not match the actual entries, and running "git commit" immediately after will create the wrong tree. We can solve this by calling remove_marked_cache_entries() ourselves before writing out the index. Note that we can't just hoist it out of checkout_worktree(); that function needs to iterate over the CE_REMOVE entries (to drop their matching worktree files) before removing them. One curiosity about the test: without this patch, it actually triggers a BUG() when running git-restore: BUG: cache-tree.c:810: new1 with flags 0x4420000 should not be in cache-tree But in the original problem report, which used a similar recipe, git-restore actually creates the bogus index (and the commit is created with the wrong tree). I'm not sure why the test here behaves differently than my out-of-suite reproduction, but what's here should catch either symptom (and the fix corrects both cases). Reported-by: Torsten Krah <krah.tm@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Heba Waly	1a7e454dd6	doc/gitcore-tutorial: fix prose to match example command In `328c6cb853` (doc: promote "git switch", 2019-03-29), an example was changed to use "git switch" rather than "git checkout" but an instance of "git checkout" in the explanatory text preceding the example was overlooked. Fix this oversight. Signed-off-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
brian m. carlson	63ab08fb99	run-command: avoid undefined behavior in exists_in_PATH In this function, we free the pointer we get from locate_in_PATH and then check whether it's NULL. However, this is undefined behavior if the pointer is non-NULL, since the C standard no longer permits us to use a valid pointer after freeing it. The only case in which the C standard would permit this to be defined behavior is if r were NULL, since it states that in such a case "no action occurs" as a result of calling free. It's easy to suggest that this is not likely to be a problem, but we know that GCC does aggressively exploit the fact that undefined behavior can never occur to optimize and rewrite code, even when that's contrary to the expectations of the programmer. It is, in fact, very common for it to omit NULL pointer checks, just as we have here. Since it's easy to fix, let's do so, and avoid a potential headache in the future. Noticed-by: Miriam R. <mirucam@gmail.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Elijah Newren	065027ee1a	string-list: note in docs that callers can specify sorting function In commit `1959bf6430` (string_list API: document what "sorted" means, 2012-09-17), Documentation/technical/api-string-list.txt was updated to specify that strcmp() was used for sorting. In commit `8dd5afc926` (string-list: allow case-insensitive string list, 2013-01-07), a cmp member was added to struct string_list to allow callers to specify an alternative comparison function, but api-string-list.txt was not updated. In commit `4f665f2cf3` (string-list.h: move documentation from Documentation/api/ into header, 2017-09-26), the now out-dated api-string-list.txt documentation was moved into string-list.h. Update the docs to reflect the configurability of sorting. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Elijah Newren	26f924d50e	unpack-trees: exit check_updates() early if updates are not wanted check_updates() has a lot of code that repeatedly checks whether o->update or o->dry_run are set. (Note that o->dry_run is a near-synonym for !o->update, but not quite as per commit `2c9078d05b` ("unpack-trees: add the dry_run flag to unpack_trees_options", 2011-05-25).) In fact, this function almost turns into a no-op whenever the condition !o->update \|\| o->dry_run is met. Simplify the code by checking this condition at the beginning of the function, and when it is true, do the few things that are relevant and return early. There are a few things that make the conversion not quite obvious: * The fact that check_updates() does not actually turn into a no-op when updates are not wanted may be slightly surprising. However, commit `33ecf7eb61` (Discard "deleted" cache entries after using them to update the working tree, 2008-02-07) put the discarding of unused cache entries in check_updates() so we still need to keep the call to remove_marked_cache_entries(). It's possible this call belongs in another function, but it is certainly needed as tests will fail if it is removed. * The original called remove_scheduled_dirs() unconditionally. Technically, commit `7847892716` (unlink_entry(): introduce schedule_dir_for_removal(), 2009-02-09) should have made that call conditional, but it didn't matter in practice because remove_scheduled_dirs() becomes a no-op when all the calls to unlink_entry() are skipped. As such, we do not need to call it. * When (o->dry_run && o->update), the original would have two calls to git_attr_set_direction() surrounding a bunch of skipped updates. These two calls to git_attr_set_direction() cancel each other out and thus can be omitted when o->dry_run is true just as they already are when !o->update. * The code would previously call setup_collided_checkout_detection() and report_collided_checkout() even when o->dry_run. However, this was just an expensive no-op because setup_collided_checkout_detection() merely cleared the CE_MATCHED flag for each cache entry, and report_collided_checkout() reported which ones had it set. Since a dry-run would skip all the checkout_entry() calls, CE_MATCHED would never get set and thus no collisions would be reported. Since we can't detect the collisions anyway without doing updates, skipping the collisions detection setup and reporting is an optimization. * The code previously would call get_progress() and display_progress() even when (!o->update \|\| o->dry_run). This served to show how long it took to skip all the updates, which is somewhat useless. Since we are skipping the updates, we can skip showing how long it takes to skip them. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Junio C Hamano	042ed3e048	The final batch before -rc2 Signed-off-by: Junio C Hamano <gitster@pobox.com>	5 years ago
Junio C Hamano	0f1930cd1b	Merge branch 'ds/sparse-cone' Code cleanup. * ds/sparse-cone: Documentation/git-sparse-checkout.txt: fix a typo sparse-checkout: use extern for global variables	5 years ago
Junio C Hamano	037f067587	Merge branch 'ds/commit-graph-set-size-mult' The code to write split commit-graph file(s) upon fetching computed bogus value for the parameter used in splitting the resulting files, which has been corrected. * ds/commit-graph-set-size-mult: commit-graph: prefer default size_mult when given zero	5 years ago

1 2 3 4 5 ...

58178 Commits (221887a492585b094f6148de70c4daab13256f25) All Branches Search

58178 Commits (221887a492585b094f6148de70c4daab13256f25)

All Branches