-
Notifications
You must be signed in to change notification settings - Fork 315
Conversation
We explicitly check for and handle the case that the incoming "path" variable is NULL, but before doing so we call strchrnul on it, leading to a potential segfault. We can fix this simply by moving the strchrnul call down; as a bonus, we can tighten the scope on the associated variable. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
When we see config like: [include] path the expand_user_path helper notices that the config value is empty, but we then dereference NULL while printing the error message (glibc will helpfully print "(null)" for us here, but we cannot rely on that). $ git -c include.path rev-parse error: Could not expand include path '(null)' fatal: unable to parse command-line config Instead of tweaking our message, let's actually use config_error_nonbool to match other config variables that expect a value: $ git -c include.path rev-parse error: Missing value for 'include.path' fatal: unable to parse command-line config Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The --prefix, --default, and --resolve-git-dir options to git-rev-parse require an argument, but when given no argument, the code uses the NULL read from argv[argc] without checking, leading to a segfault. Instead, check first and die() with an error message. Signed-off-by: David Sharp <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Moving to some other directory and letting the remainder of the test pieces to expect that they start there is a bad practice. The test that contains chdir itself may fail (or by mistake skipped via the GIT_SKIP_TESTS mechanism) in which case the remainder may operate on files in unexpected places. Signed-off-by: Junio C Hamano <[email protected]>
Lasse Makholm noticed that running "git check-attr" from a place totally unrelated to $GIT_DIR and $GIT_WORK_TREE does not give expected results. I think it is because the command does not say it wants to call setup_work_tree(). We still need to support use cases where only a bare repository is involved, so unconditionally requiring a working tree would not work well. Instead, make a call only in a non-bare repository. We may want to see if we want to do a similar fix in the opposite direction to check-ignore. The command unconditionally requires a working tree, but it should be usable in a bare repository just like check-attr attempts to be. Signed-off-by: Junio C Hamano <[email protected]>
We set the default apache port for each of the httpd tests to the 4-digit test number of the test script. We want these to remain unique so that the tests do not conflict with each other when run in parallel. Instead of doing it manually in each test script, let's just set it from the test name at run time. This is simpler, and is one less thing to be updated when test scripts are renamed (e.g., when being re-rolled or when conflicting after being merged with another topic). Incidentally, this fixes a case where t5537 and t5538 used the same port number (5537), and could conflict with each other when run in parallel. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Make clear which one is for dumb protocol, which one is for smart from their file name. Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
It's introduced in 1bd8c8f (git-upload-pack: Support the multi_ack protocol - 2005-10-28) but probably better documented in the commit message of 78affc4 (Add multi_ack_detailed capability to fetch-pack/upload-pack - 2009-10-30). Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
…ocol.txt pack-protocol.txt explains in detail how multi_ack_detailed works and what's the difference between no multi_ack, multi_ack and multi_ack_detailed. No need to repeat here. Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
See 3e63b21 (upload-pack: Implement no-done capability - 2011-03-14) and 761ecf0 (fetch-pack: Implement no-done capability - 2011-03-14) for more information. Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
In smart http, upload-pack adds new shallow lines at the beginning of each rpc response. Only shallow lines from the first rpc call are useful. After that they are thrown away. It's designed this way because upload-pack is stateless and has no idea when its shallow lines are helpful or not. So after refs are negotiated with multi_ack_detailed and the server thinks it learned enough, it sends "ACK obj-id ready", terminates the rpc call and waits for the final rpc round. The client sends "done". The server sends another response, which also has shallow lines at the beginning, and the last "ACK obj-id" line. When no-done is active, the last round is cut out, the server sends "ACK obj-id ready" and "ACK obj-id" in the same rpc response. fetch-pack is updated to recognize this and not send "done". However it still tries to consume shallow lines, which are never sent. Update the code, make sure to skip consuming shallow lines when no-done is enabled. Reported-by: Jeff King <[email protected]> Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
start_httpd is supposed to be at the beginning of the test file, not the middle of it. The "test_seq" line in "no shallow lines.." test is updated to compensate missing refs that are there in t5537, but not in the new t5539. Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The GIT_EXTERNAL_DIFF calling code attempts to reuse existing worktree files for the worktree side of diffs, for performance reasons. However, that code also tries to do the same with submodules. This results in calls to $GIT_EXTERNAL_DIFF where the old-file is a file of the form "Submodule commit $sha1", but the new-file is a directory in the worktree. Fix it by never reusing a worktree "file" in the submodule case. Reported-by: Grégory Pakosz <[email protected]> Signed-off-by: Thomas Rast <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Refreshing index requires work tree. So we have two options: always set up work tree (and refuse to reset if failing to do so), or make refreshing index optional. As refreshing index is not the main task, it makes more sense to make it optional. This allows us to still work in a bare repository to update what is in the index. Reported-by: Patrick Palka <[email protected]> Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Modern versions of "git submodule" use .git-files to setup the submodule directory. When run in a "git submodule"-created repository "git difftool --dir-diff" dies with the following error: $ git difftool -d HEAD~ fatal: This operation must be run in a work tree diff --raw --no-abbrev -z HEAD~: command returned error: 128 core.worktree is relative to the .git directory but the logic in find_worktree() does not account for it. Use `git rev-parse --show-toplevel` to find the worktree so that the dir-diff feature works inside a submodule. Reported-by: Gábor Lipták <[email protected]> Helped-by: Jens Lehmann <[email protected]> Helped-by: John Keeping <[email protected]> Signed-off-by: David Aguilar <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
When t4212 was originally added by 9dbe7c3 (pretty: handle broken commit headers gracefully, 2013-04-17), it tested our handling of commits with broken ident lines in which the timestamps could not be parsed. It does so using a bogus line like "Name <email>-<> 1234 -0000", because that simulates an error that was seen in the wild. Later, 03818a4 (split_ident: parse timestamp from end of line, 2013-10-14) made our parser smart enough to actually find the timestamp on such a line, and t4212 was adjusted to match. While it's nice that we handle this real-world case, this meant that we were not actually testing the bogus-timestamp case anymore. This patch adds a test with a totally incomprehensible timestamp to make sure we are testing the code path. Note that the behavior is slightly different between regular log output and "--format=%ad". In the former case, we produce a sentinel value and in the latter, we produce an empty string. While at first this seems unnecessarily inconsistent, it matches the original behavior given by 9dbe7c3. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
When we check commit objects, we complain if commit->date is ULONG_MAX, which is an indication that we saw integer overflow when parsing it. However, we do not do any check at all for author lines, which also contain a timestamp. Let's actually check the timestamps on each ident line with strtoul. This catches both author and committer lines, and we can get rid of the now-redundant commit->date check. Note that like the existing check, we compare only against ULONG_MAX. Now that we are calling strtoul at the site of the check, we could be slightly more careful and also check that errno is set to ERANGE. However, this will make further refactoring in future patches a little harder, and it doesn't really matter in practice. For 32-bit systems, one would have to create a commit at the exact wrong second in 2038. But by the time we get close to that, all systems will hopefully have moved to 64-bit (and if they haven't, they have a real problem one second later). For 64-bit systems, by the time we get close to ULONG_MAX, all systems will hopefully have been consumed in the fiery wrath of our expanding Sun. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
When we check whether a timestamp has overflowed, we check only against ULONG_MAX, meaning that strtoul has overflowed. However, we also feed these timestamps to system functions like gmtime, which expect a time_t. On many systems, time_t is actually smaller than "unsigned long" (e.g., because it is signed), and we would overflow when using these functions. We don't know the actual size or signedness of time_t, but we can easily check for truncation with a simple assignment. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
If an ident line has a ridiculous date value like (2^64)+1, we currently just pass ULONG_MAX along to the date code, which can produce nonsensical dates. On systems with a signed long time_t (e.g., 64-bit glibc systems), this actually doesn't end up too bad. The ULONG_MAX is converted to -1, we apply the timezone field to that, and the result ends up somewhere between Dec 31, 1969 and Jan 1, 1970. However, there is still a few good reasons to detect the overflow explicitly: 1. On systems where "unsigned long" is smaller than time_t, we get a nonsensical date in the future. 2. Even where it would produce "Dec 31, 1969", it's easier to recognize "midnight Jan 1" as a consistent sentinel value for "we could not parse this". 3. Values which do not overflow strtoul but do overflow a signed time_t produce nonsensical values in the past. For example, on a 64-bit system with a signed long time_t, a timestamp of 18446744073000000000 produces a date in 1947. We also recognize overflow in the timezone field, which could produce nonsensical results. In this case we show the parsed date, but in UTC. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Many code paths assume that show_date and show_ident_date cannot return NULL. For the most part, we handle missing or corrupt timestamps by showing the epoch time t=0. However, we might still return NULL if gmtime rejects the time_t we feed it, resulting in a segfault. Let's catch this case and just format t=0. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The remote we push can be defined either by remote.pushdefault or by branch.*.pushremote for the current branch. The order in which they appear in the config file should not matter to precedence (which should be to prefer the branch-specific config). The current code parses the config linearly and uses a single string to store both values, overwriting any previous value. Thus, config like: [branch "master"] pushremote = foo [remote] pushdefault = bar erroneously ends up pushing to "bar" from the master branch. We can fix this by storing both values and resolving the correct value after all config is read. Signed-off-by: Jeff King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Sometimes when working with a large repository it can be useful to try out a merge and only check out conflicting files to disk (for example as a speed optimization on a server). Until v1.7.7-rc1~28^2~20 (merge-recursive: When we detect we can skip an update, actually skip it, 2011-08-11), it was possible to do so with the following idiom: # Prepare a temporary index and empty work tree. GIT_INDEX_FILE="$PWD/tmp-$$-index" && export GIT_INDEX_FILE && GIT_WORK_TREE="$PWD/tmp-$$-work" && export GIT_WORK_TREE && mkdir "$GIT_WORK_TREE" && # Convince the index that our side is on disk. git read-tree -i -m $ours && git update-index --ignore-missing --refresh && # Merge their side into our side. bases=$(git merge-base --all $ours $theirs) && git merge-recursive $bases -- $ours $theirs && tree=$(git write-tree) Nowadays, that still works and the exit status is the same, but merge-recursive produces a diagnostic if "our" side renamed a file: error: addinfo_cache failed for path 'dst' Add a test to document this regression. Signed-off-by: Brad King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Move lstat ENOENT handling from refresh_index to refresh_cache_ent and activate it with a new CE_MATCH_IGNORE_MISSING option. This will allow other call paths into refresh_cache_ent to use the feature. Signed-off-by: Brad King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Convert the make_cache_entry boolean 'refresh' argument to a more general 'refresh_options' argument. Pass the value through to the underlying refresh_cache_ent call. Add option CE_MATCH_REFRESH to enable stat refresh. Update call sites to use the new signature. Signed-off-by: Brad King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Teach add_cacheinfo to tell make_cache_entry to skip refreshing stat information when a file is missing from the work tree. We do not want the index to be stat-dirty after the merge but also do not want to fail when a file happens to be missing. This fixes the 'merge-recursive w/ empty work tree - ours has rename' case in t3030-merge-recursive. Suggested-by: Elijah Newren <[email protected]> Signed-off-by: Brad King <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
This helps reduce the number of match_pathspec_depth() call sites and show how match_pathspec_depth() is used. Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
This helps reduce the number of match_pathspec_depth() call sites and show how m_p_d() is used. And it usage is: - match against an index entry (ce_path_match or match_pathspec_depth in ls-files) - match against a dir_entry from read_directory (dir_path_match and match_pathspec_depth in clean.c, which will be converted later) - resolve-undo (rerere.c and ls-files.c) Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
A long time ago, for some reason I was not happy with match_pathspec(). I created a better version, match_pathspec_depth() that was suppose to replace match_pathspec() eventually. match_pathspec() has finally been gone since 6 months ago. Use the shorter name for match_pathspec_depth(). Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Currently we do support matching pathspec "foo/" against directory "foo". That is because match_pathspec() has no way to tell "foo" is a directory and matching "foo/" against _file_ "foo" is wrong. The callers can now tell match_pathspec if "foo" is a directory, we could make an exception for this case. Code is not executed though because no callers pass the flag yet. Signed-off-by: Nguyễn Thái Ngọc Duy <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
* jk/shallow-update-fix: shallow: verify shallow file after taking lock shallow: automatically clean up shallow tempfiles shallow: use stat_validity to check for up-to-date file
* rr/doc-merge-strategies: Documentation/merge-strategies: avoid hyphenated commands
* us/printf-not-echo: test-lib.sh: do not "echo" caller-supplied strings rebase -i: do not "echo" random user-supplied strings
* nd/index-pack-error-message: index-pack: report error using the correct variable
* jk/lib-terminal-lazy: t/lib-terminal: make TTY a lazy prerequisite
* mh/remove-subtree-long-pathname-fix: entry.c: fix possible buffer overflow in remove_subtree() checkout_entry(): use the strbuf throughout the function
* jk/mv-submodules-fix: mv: prevent mismatched data when ignoring errors. builtin/mv: fix out of bounds write Conflicts: t/t7001-mv.sh
Signed-off-by: Junio C Hamano <[email protected]>
* bp/commit-p-editor: run-command: mark run_hook_with_custom_index as deprecated merge hook tests: fix and update tests merge: fix GIT_EDITOR override for commit hook commit: fix patch hunk editing with "commit -p -m" test patch hunk editing with "commit -p -m" merge hook tests: use 'test_must_fail' instead of '!' merge hook tests: fix missing '&&' in test
* mm/status-porcelain-format-i18n-fix: status: disable translation when --porcelain is used
Signed-off-by: Junio C Hamano <[email protected]>
Signed-off-by: Thomas Ackermann <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
* commit '5df05146d5cb94628a3dfc53063c802ee1152cec': doc/http-backend: missing accent grave in literal mark-up
* jc/fix-diff-no-index-diff-opt-parse: diff-no-index: correctly diagnose error return from diff_opt_parse()
* jk/commit-dates-parsing-fix: t4212: loosen far-in-future test for AIX date: recognize bogus FreeBSD gmtime output
* mh/update-ref-batch-create-fix: update-ref: fail create operation over stdin if ref already exists
* cn/fetch-prune-overlapping-destination: fetch: handle overlaping refspecs on --prune fetch: add a failing test for prunning with overlapping refspecs
* jl/nor-or-nand-and: code and test: fix misuses of "nor" comments: fix misuses of "nor" contrib: fix misuses of "nor" Documentation: fix misuses of "nor"
The second maintenance release for Git 1.9; contains all the fixes that are scheduled to appear in Git 2.0. Signed-off-by: Junio C Hamano <[email protected]>
The process is unfortunately slightly more involved because we want to keep our topic branches in shape for (eventual, hopefully) contribution upstream. For that purpose, we use the script I am in the process of doing that and I already got three merge conflicts: one with the hidden .git directory support, one with stricter transport checking and one with support for dynamic linking to the CRT via MSVC... |
Interesting, thank you for the answer. |
MSysGit - the development behind Git for Windows » git #185 SUCCESS |
Aargh. I made a mistake: I called |
@kasal In https://github.com/msysgit/msysgit/wiki/How-and-when-does-Git-for-Windows-get-released I documented the steps needed to switch to a newer upstream tag. |
Wow! @t-b thanks. The test suite now runs really quickly, with all processor cores working on 100%. |
@t-b 20 minutes instead of hours, Wow! |
Hello,
I tried to build msysgit 1.9.2 and it seemed to be very easy. I did "git merge v1.9.2" and there was one trivial merge conflict. The test suite is ok until 7407. There was a fail in 7407, but it did not reproduce on subsequent runs. But while I was at it, I noticed that part of @dscho's workaround there is not (no longer?) necessary.
(The only CR problem seems to come from running echo from within git; I guess it runs cmd.exe echo, not sh echo.)
Back to original subject: what is the right way to create v1.9.2.msysgit?
I also tried
git rebase -i --autosquash --onto v1.9.2 v1.9.0
I took ages and created script that contained ~5800 commits; does that make sense?
Or should the rebase be called with --preserve-merges?
I'll be grateful for any explanations, though I suspect this may not be the best place for this discussion.
Stepan