summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2014-05-08Merge branch 'km/avoid-bs-in-shell-glob' into maintLibravatar Junio C Hamano1-2/+2
Some tests used shell constructs that did not work well on FreeBSD * km/avoid-bs-in-shell-glob: test: fix t5560 on FreeBSD
2014-05-08Merge branch 'km/avoid-cp-a' into maintLibravatar Junio C Hamano1-2/+2
Some tests used shell constructs that did not work well on FreeBSD * km/avoid-cp-a: test: fix t7001 cp to use POSIX options
2014-04-11test: fix t5560 on FreeBSDLibravatar Kyle J. McKay1-2/+2
Since fd0a8c2e (first appearing in v1.7.0), the t/t5560-http-backend-noserver.sh test has used a backslash escape inside a ${} expansion in order to specify a literal '?' character. Unfortunately the FreeBSD /bin/sh does not interpret this correctly. In a POSIX compliant shell, the following: x='one?two?three' echo "${x#*\?}" Would be expected to produce this: two?three When using the FreeBSD /bin/sh instead you get this: one?two?three In fact the FreeBSD /bin/sh treats the backslash as a literal character to match so that this: y='one\two\three' echo "${y#*\?}" Produces this unexpected value: wo\three In this case the backslash is not only treated literally, it also fails to defeat the special meaning of the '?' character. Instead, we can use the [...] construct to defeat the special meaning of the '?' character and match it exactly in a way that works for the FreeBSD /bin/sh as well as other POSIX /bin/sh implementations. Changing the example like so: x='one?two?three' echo "${x#*[?]}" Produces the expected output using the FreeBSD /bin/sh. Therefore, change the use of \? to [?] in order to be compatible with the FreeBSD /bin/sh which allows t/t5560-http-backend-noserver.sh to pass on FreeBSD again. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-11test: fix t7001 cp to use POSIX optionsLibravatar Kyle J. McKay1-2/+2
Since 11502468 and 04c1ee57 (both first appearing in v1.8.5), the t7001-mv test has used "cp -a" to perform a copy in several of the tests. However, the "-a" option is not required for a POSIX cp utility and some platforms' cp utilities do not support it. The POSIX equivalent of -a is -R -P -p. Change "cp -a" to "cp -R -P -p" so that the t7001-mv test works on systems with a cp utility that only implements the POSIX required set of options and not the "-a" option. Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-09Merge branch 'jl/nor-or-nand-and' into maintLibravatar Junio C Hamano7-7/+7
* 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"
2014-04-09Merge branch 'cn/fetch-prune-overlapping-destination' into maintLibravatar Junio C Hamano1-0/+20
* cn/fetch-prune-overlapping-destination: fetch: handle overlaping refspecs on --prune fetch: add a failing test for prunning with overlapping refspecs
2014-04-09Merge branch 'mh/update-ref-batch-create-fix' into maintLibravatar Junio C Hamano1-0/+11
* mh/update-ref-batch-create-fix: update-ref: fail create operation over stdin if ref already exists
2014-04-09Merge branch 'jk/commit-dates-parsing-fix' into maintLibravatar Junio C Hamano1-4/+2
* jk/commit-dates-parsing-fix: t4212: loosen far-in-future test for AIX date: recognize bogus FreeBSD gmtime output
2014-04-08Merge branch 'bp/commit-p-editor' into maintLibravatar Junio C Hamano2-9/+58
* 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
2014-04-03Merge branch 'jk/mv-submodules-fix' into maintLibravatar Junio C Hamano1-1/+12
* jk/mv-submodules-fix: mv: prevent mismatched data when ignoring errors. builtin/mv: fix out of bounds write Conflicts: t/t7001-mv.sh
2014-04-03Merge branch 'jk/lib-terminal-lazy' into maintLibravatar Junio C Hamano1-18/+19
* jk/lib-terminal-lazy: t/lib-terminal: make TTY a lazy prerequisite
2014-04-03Merge branch 'us/printf-not-echo' into maintLibravatar Junio C Hamano1-2/+2
* us/printf-not-echo: test-lib.sh: do not "echo" caller-supplied strings rebase -i: do not "echo" random user-supplied strings
2014-04-03Merge branch 'jn/wt-status' into maintLibravatar Junio C Hamano2-13/+13
* jn/wt-status: wt-status: lift the artificual "at least 20 columns" floor wt-status: i18n of section labels wt-status: extract the code to compute width for labels wt-status: make full label string to be subject to l10n
2014-04-02update-ref: fail create operation over stdin if ref already existsLibravatar Aman Gupta1-0/+11
Signed-off-by: Aman Gupta <aman@tmm1.net> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Acked-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-01t4212: loosen far-in-future test for AIXLibravatar Jeff King1-4/+2
One of the tests in t4212 checks our behavior when we feed gmtime a date so far in the future that it gives up and returns NULL. Some implementations, like AIX, may actually just provide us a bogus result instead. It's not worth it for us to come up with heuristics that guess whether the return value is sensible or not. On good platforms where gmtime reports the problem to us with NULL, we will print the epoch value. On bad platforms, we will print garbage. But our test should be written for the lowest common denominator so that it passes everywhere. Reported-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-31code and test: fix misuses of "nor"Libravatar Justin Lebar7-7/+7
Signed-off-by: Justin Lebar <jlebar@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-26fetch: handle overlaping refspecs on --pruneLibravatar Carlos Martín Nieto1-1/+1
We need to consider that a remote-tracking branch may match more than one rhs of a fetch refspec. In such a case, it is not enough to stop at the first match but look at all of the matches in order to determine whether a head is stale. To this goal, introduce a variant of query_refspecs which returns all of the matching refspecs and loop over those answers to check for staleness. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-18Merge branch 'jk/clean-d-pathspec' into maintLibravatar Junio C Hamano1-0/+16
"git clean -d pathspec" did not use the given pathspec correctly and ended up cleaning too much. * jk/clean-d-pathspec: clean: simplify dir/not-dir logic clean: respect pathspecs with "-d"
2014-03-18Merge branch 'da/difftool-git-files' into maintLibravatar Junio C Hamano1-0/+14
"git difftool" misbehaved when the repository is bound to the working tree with the ".git file" mechanism, where a textual file ".git" tells us where it is. * da/difftool-git-files: t7800: add a difftool test for .git-files difftool: support repositories with .git-files
2014-03-18Merge branch 'jk/remote-pushremote-config-reading' into maintLibravatar Junio C Hamano1-0/+13
"git push" did not pay attention to branch.*.pushremote if it is defined earlier than remote.pushdefault; the order of these two variables in the configuration file should not matter, but it did by mistake. * jk/remote-pushremote-config-reading: remote: handle pushremote config in any order
2014-03-18Merge branch 'jk/commit-dates-parsing-fix' into maintLibravatar Junio C Hamano2-0/+59
Codepaths that parse timestamps in commit objects have been tightened. * jk/commit-dates-parsing-fix: show_ident_date: fix tz range check log: do not segfault on gmtime errors log: handle integer overflow in timestamps date: check date overflow against time_t fsck: report integer overflow in author timestamps t4212: test bogus timestamps with git-log
2014-03-18Merge branch 'tr/diff-submodule-no-reuse-worktree' into maintLibravatar Junio C Hamano1-1/+29
"git diff --external-diff" incorrectly fed the submodule directory in the working tree to the external diff driver when it knew it is the same as one of the versions being compared. * tr/diff-submodule-no-reuse-worktree: diff: do not reuse_worktree_file for submodules
2014-03-18Merge branch 'nd/reset-setup-worktree' into maintLibravatar Junio C Hamano1-0/+11
"git reset" needs to refresh the index when working in a working tree (it can also be used to match the index to the HEAD in an otherwise bare repository), but it failed to set up the working tree properly, causing GIT_WORK_TREE to be ignored. * nd/reset-setup-worktree: reset: optionally setup worktree and refresh index on --mixed
2014-03-18Merge branch 'jc/check-attr-honor-working-tree' into maintLibravatar Junio C Hamano1-22/+40
"git check-attr" when working on a repository with a working tree did not work well when the working tree was specified via the --work-tree (and obviously with --git-dir) option. * jc/check-attr-honor-working-tree: check-attr: move to the top of working tree when in non-bare repository t0003: do not chdir the whole test process
2014-03-18Merge branch 'bk/refresh-missing-ok-in-merge-recursive' into maintLibravatar Junio C Hamano1-0/+47
"merge-recursive" was broken in 1.7.7 era and stopped working in an empty (temporary) working tree, when there are renames involved. This has been corrected. * bk/refresh-missing-ok-in-merge-recursive: merge-recursive.c: tolerate missing files while refreshing index read-cache.c: extend make_cache_entry refresh flag with options read-cache.c: refactor --ignore-missing implementation t3030-merge-recursive: test known breakage with empty work tree
2014-03-18Merge branch 'nd/diff-quiet-stat-dirty' into maintLibravatar Junio C Hamano1-0/+6
"git diff --quiet -- pathspec1 pathspec2" sometimes did not return correct status value. * nd/diff-quiet-stat-dirty: diff: do not quit early on stat-dirty files diff.c: move diffcore_skip_stat_unmatch core logic out for reuse later
2014-03-18Merge branch 'nd/http-fetch-shallow-fix' into maintLibravatar Junio C Hamano9-35/+83
Attempting to deepen a shallow repository by fetching over smart HTTP transport failed in the protocol exchange, when no-done extension was used. The fetching side waited for the list of shallow boundary commits after the sending end stopped talking to it. * nd/http-fetch-shallow-fix: t5537: move http tests out to t5539 fetch-pack: fix deepen shallow over smart http with no-done cap protocol-capabilities.txt: document no-done protocol-capabilities.txt: refer multi_ack_detailed back to pack-protocol.txt pack-protocol.txt: clarify 'obj-id' in the last ACK after 'done' test: rename http fetch and push test files tests: auto-set LIB_HTTPD_PORT from test name
2014-03-18Merge branch 'nd/submodule-pathspec-ending-with-slash' into maintLibravatar Junio C Hamano2-3/+9
Allow "git cmd path/", when the 'path' is where a submodule is bound to the top-level working tree, to match 'path', despite the extra and unnecessary trailing slash (such a slash is often given by command line completion). * nd/submodule-pathspec-ending-with-slash: clean: use cache_name_is_other() clean: replace match_pathspec() with dir_path_match() pathspec: pass directory indicator to match_pathspec_item() match_pathspec: match pathspec "foo/" against directory "foo" dir.c: prepare match_pathspec_item for taking more flags pathspec: rename match_pathspec_depth() to match_pathspec() pathspec: convert some match_pathspec_depth() to dir_path_match() pathspec: convert some match_pathspec_depth() to ce_path_match()
2014-03-18test-lib.sh: do not "echo" caller-supplied stringsLibravatar Uwe Storbeck1-2/+2
In some places we "echo" a string that is supplied by the calling test script and may contain backslash sequences. The echo command of some shells, most notably "dash", interprets these backslash sequences (POSIX.1 allows this) which may scramble the test output. Signed-off-by: Uwe Storbeck <uwe@ibr.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-18merge hook tests: fix and update testsLibravatar Benoit Pierre1-6/+21
- update 'no editor' hook test and add 'editor' hook test - make sure the tree is reset to a clean state after running a test (using test_when_finished) so later tests are not impacted Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-18commit: fix patch hunk editing with "commit -p -m"Libravatar Benoit Pierre1-2/+2
Don't change git environment: move the GIT_EDITOR=":" override to the hook command subprocess, like it's already done for GIT_INDEX_FILE. Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-18test patch hunk editing with "commit -p -m"Libravatar Benoit Pierre1-0/+34
Add (failing) tests: with commit changing the environment to let hooks know that no editor will be used (by setting GIT_EDITOR to ":"), the "edit hunk" functionality does not work (no editor is launched and the whole hunk is committed). Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-17mv: prevent mismatched data when ignoring errors.Libravatar brian m. carlson1-1/+12
We shrink the source and destination arrays, but not the modes or submodule_gitfile arrays, resulting in potentially mismatched data. Shrink all the arrays at the same time to prevent this. Add tests to ensure the problem does not recur. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-14t/lib-terminal: make TTY a lazy prerequisiteLibravatar Jeff King1-18/+19
When lib-terminal.sh is sourced by a test script, we immediately set up the TTY prerequisite. We do so inside a test_expect_success, because that nicely isolates any generated output. However, this early test can interfere with a script that later wants to skip all tests (e.g., t5541 then goes on to set up the httpd server, and wants to skip_all if that fails). TAP output doesn't let us skip everything after we have already run at least one test. We could fix this by reordering the inclusion of lib-terminal.sh in t5541 to go after the httpd setup. That solves this case, but we might eventually hit a case with circular dependencies, where either lib-*.sh include might want to skip_all after the other has run a test. So instead, let's just remove the ordering constraint entirely by doing the setup inside a test_lazy_prereq construct, rather than in a regular test. We never cared about the test outcome anyway (it was written to always succeed). Note that in addition to setting up the prerequisite, the current test also defines test_terminal. Since we can't affect the environment from a lazy_prereq, we have to hoist that out. We previously depended on it _not_ being defined when the TTY prereq isn't set as a way to ensure that tests properly declare their dependency on TTY. However, we still cover the case (see the in-code comment for details). Reported-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-12wt-status: lift the artificual "at least 20 columns" floorLibravatar Junio C Hamano2-13/+13
When we show unmerged paths, we had an artificial 20 columns floor for the width of labels (e.g. "both deleted:") shown next to the pathnames. Depending on the locale, this may result in a label that is too wide when all the label strings are way shorter than 20 columns, or no-op when a label string is longer than 20 columns. Just drop the artificial floor. The screen real estate is better utilized this way when all the strings are shorter. Adjust the tests to this change. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-11merge hook tests: use 'test_must_fail' instead of '!'Libravatar Benoit Pierre1-2/+2
Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-11merge hook tests: fix missing '&&' in testLibravatar Benoit Pierre1-1/+1
Signed-off-by: Benoit Pierre <benoit.pierre@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-11clean: respect pathspecs with "-d"Libravatar Jeff King1-0/+16
git-clean uses read_directory to fill in a `struct dir` with potential hits. However, read_directory does not actually check against our pathspec. It uses a simplified version that may turn up false positives. As a result, we need to check that any hits match our pathspec. We do so reliably for non-directories. For directories, if "-d" is not given we check that the pathspec matched exactly (i.e., we are even stricter, and require an explicit "git clean foo" to clean "foo/"). But if "-d" is given, rather than relaxing the exact match to allow a recursive match, we do not check the pathspec at all. This regression was introduced in 113f10f (Make git-clean a builtin, 2007-11-11). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-05t7800: add a difftool test for .git-filesLibravatar Junio C Hamano1-0/+14
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-28fetch: add a failing test for prunning with overlapping refspecsLibravatar Carlos Martín Nieto1-0/+20
When a remote has multiple fetch refspecs and these overlap in the target namespace, fetch may prune a remote-tracking branch which still exists in the remote. The test uses a popular form of this, by putting pull requests as stored in a popular hosting platform alongside "real" remote-tracking branches. The fetch command makes a decision of whether to prune based on the first matching refspec, which in this case is insufficient, as it covers the pull request names. This pair of refspecs does work as expected if the more "specific" refspec is the first in the list. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24diff: do not quit early on stat-dirty filesLibravatar Nguyễn Thái Ngọc Duy1-0/+6
When QUICK is set (i.e. with --quiet) we try to do as little work as possible, stopping after seeing the first change. stat-dirty is considered a "change" but it may turn out not, if no actual content is changed. The actual content test is performed too late in the process and the shortcut may be taken prematurely, leading to incorrect return code. Assume we do "git diff --quiet". If we have a stat-dirty file "a" and a really dirty file "b". We break the loop in run_diff_files() and stop after "a" because we have got a "change". Later in diffcore_skip_stat_unmatch() we find out "a" is actually not changed. But there's nothing else in the diff queue, we incorrectly declare "no change", ignoring the fact that "b" is changed. This also happens to "git diff --quiet HEAD" when it hits diff_can_quit_early() in oneway_diff(). This patch does the content test earlier in order to keep going if "a" is unchanged. The test result is cached so that when diffcore_skip_stat_unmatch() is done in the end, we spend no cycles on re-testing "a". Reported-by: IWAMOTO Toshihiro <iwamoto@valinux.co.jp> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24pathspec: pass directory indicator to match_pathspec_item()Libravatar Nguyễn Thái Ngọc Duy1-0/+6
This patch activates the DO_MATCH_DIRECTORY code in m_p_i(), which makes "git diff HEAD submodule/" and "git diff HEAD submodule" produce the same output. Previously only the version without trailing slash returns the difference (if any). That's the effect of new ce_path_match(). dir_path_match() is not executed by the new tests. And it should not introduce regressions. Previously if path "dir/" is passed in with pathspec "dir/", they obviously match. With new dir_path_match(), the path becomes _directory_ "dir" vs pathspec "dir/", which is not executed by the old code path in m_p_i(). The new code path is executed and produces the same result. The other case is pathspec "dir" and path "dir/" is now turned to "dir" (with DO_MATCH_DIRECTORY). Still the same result before or after the patch. So why change? Because of the next patch about clean.c. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24pathspec: rename match_pathspec_depth() to match_pathspec()Libravatar Nguyễn Thái Ngọc Duy1-3/+3
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 <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24merge-recursive.c: tolerate missing files while refreshing indexLibravatar Brad King1-1/+1
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 <newren@gmail.com> Signed-off-by: Brad King <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24t3030-merge-recursive: test known breakage with empty work treeLibravatar Brad King1-0/+47
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 <brad.king@kitware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24remote: handle pushremote config in any orderLibravatar Jeff King1-0/+13
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24log: do not segfault on gmtime errorsLibravatar Jeff King1-0/+8
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24log: handle integer overflow in timestampsLibravatar Jeff King1-0/+16
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24fsck: report integer overflow in author timestampsLibravatar Jeff King1-0/+14
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24t4212: test bogus timestamps with git-logLibravatar Jeff King1-0/+21
When t4212 was originally added by 9dbe7c3d (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 9dbe7c3d. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>