summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2017-09-09files_ref_store: use a transaction to update packed refsLibravatar Michael Haggerty1-2/+2
When processing a `files_ref_store` transaction, it is sometimes necessary to delete some references from the "packed-refs" file. Do that using a reference transaction conducted against the `packed_ref_store`. This change further decouples `files_ref_store` from `packed_ref_store`. It also fixes multiple problems, including the two revealed by test cases added in the previous commit. First, the old code didn't obtain the `packed-refs` lock until `files_transaction_finish()`. This means that a failure to acquire the `packed-refs` lock (e.g., due to contention with another process) wasn't detected until it was too late (problems like this are supposed to be detected in the "prepare" phase). The new code acquires the `packed-refs` lock in `files_transaction_prepare()`, the same stage of the processing when the loose reference locks are being acquired, removing another reason why the "prepare" phase might succeed and the "finish" phase might nevertheless fail. Second, the old code deleted the loose version of a reference before deleting any packed version of the same reference. This left a moment when another process might think that the packed version of the reference is current, which is incorrect. (Even worse, the packed version of the reference can be arbitrarily old, and might even point at an object that has since been garbage-collected.) Third, if a reference deletion fails to acquire the `packed-refs` lock altogether, then the old code might leave the repository in the incorrect state (possibly corrupt) described in the previous paragraph. Now we activate the new "packed-refs" file (sans any references that are being deleted) *before* deleting the corresponding loose references. But we hold the "packed-refs" lock until after the loose references have been finalized, thus preventing a simultaneous "pack-refs" process from packing the loose version of the reference in the time gap, which would otherwise defeat our attempt to delete it. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-09t1404: demonstrate two problems with reference transactionsLibravatar Michael Haggerty1-0/+73
Currently, a loose reference is deleted even before locking the `packed-refs` file, let alone deleting any packed version of the reference. This leads to two problems, demonstrated by two new tests: * While a reference is being deleted, other processes might see the old, packed value of the reference for a moment before the packed version is deleted. Normally this would be hard to observe, but we can prolong the window by locking the `packed-refs` file externally before running `update-ref`, then unlocking it before `update-ref`'s attempt to acquire the lock times out. * If the `packed-refs` file is locked so long that `update-ref` fails to lock it, then the reference can be left permanently in the incorrect state described in the previous point. In a moment, both problems will be fixed. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-26Merge branch 'mg/killed-merge'Libravatar Junio C Hamano1-0/+15
Killing "git merge --edit" before the editor returns control left the repository in a state with MERGE_MSG but without MERGE_HEAD, which incorrectly tells the subsequent "git commit" that there was a squash merge in progress. This has been fixed. * mg/killed-merge: merge: save merge state earlier merge: split write_merge_state in two merge: clarify call chain Documentation/git-merge: explain --continue
2017-08-26Merge branch 'jc/cutoff-config'Libravatar Junio C Hamano1-18/+39
"[gc] rerereResolved = 5.days" used to be invalid, as the variable is defined to take an integer counting the number of days. It now is allowed. * jc/cutoff-config: rerere: allow approxidate in gc.rerereResolved/gc.rerereUnresolved rerere: represent time duration in timestamp_t internally t4200: parameterize "rerere gc" custom expiry test t4200: gather "rerere gc" together t4200: make "rerere gc" test more robust t4200: give us a clean slate after "rerere gc" tests
2017-08-26Merge branch 'kw/write-index-reduce-alloc'Libravatar Junio C Hamano2-0/+52
We used to spend more than necessary cycles allocating and freeing piece of memory while writing each index entry out. This has been optimized. * kw/write-index-reduce-alloc: read-cache: avoid allocating every ondisk entry when writing read-cache: fix memory leak in do_write_index perf: add test for writing the index
2017-08-26Merge branch 'bw/submodule-config-cleanup'Libravatar Junio C Hamano4-156/+15
Code clean-up to avoid mixing values read from the .gitmodules file and values read from the .git/config file. * bw/submodule-config-cleanup: submodule: remove gitmodules_config unpack-trees: improve loading of .gitmodules submodule-config: lazy-load a repository's .gitmodules file submodule-config: move submodule-config functions to submodule-config.c submodule-config: remove support for overlaying repository config diff: stop allowing diff to have submodules configured in .git/config submodule: remove submodule_config callback routine unpack-trees: don't respect submodule.update submodule: don't rely on overlayed config when setting diffopts fetch: don't overlay config with submodule-config submodule--helper: don't overlay config in update-clone submodule--helper: don't overlay config in remote_submodule_branch add, reset: ensure submodules can be added or reset submodule: don't use submodule_from_name t7411: check configuration parsing errors
2017-08-26Merge branch 'tb/apply-with-crlf'Libravatar Junio C Hamano1-6/+27
"git apply" that is used as a better "patch -p1" failed to apply a taken from a file with CRLF line endings to a file with CRLF line endings. The root cause was because it misused convert_to_git() that tried to do "safe-crlf" processing by looking at the index entry at the same path, which is a nonsense---in that mode, "apply" is not working on the data in (or derived from) the index at all. This has been fixed. * tb/apply-with-crlf: apply: file commited with CRLF should roundtrip diff and apply convert: add SAFE_CRLF_KEEP_CRLF
2017-08-26Merge branch 'jt/stash-tests'Libravatar Junio C Hamano1-0/+34
Test update to improve coverage for "git stash" operations. * jt/stash-tests: stash: add a test for stashing in a detached state stash: add a test for when apply fails during stash branch stash: add a test for stash create with no files
2017-08-26Merge branch 'jk/trailers-parse'Libravatar Junio C Hamano2-7/+120
"git interpret-trailers" has been taught a "--parse" and a few other options to make it easier for scripts to grab existing trailer lines from a commit log message. * jk/trailers-parse: doc/interpret-trailers: fix "the this" typo pretty: support normalization options for %(trailers) t4205: refactor %(trailers) tests pretty: move trailer formatting to trailer.c interpret-trailers: add --parse convenience option interpret-trailers: add an option to unfold values interpret-trailers: add an option to show only existing trailers interpret-trailers: add an option to show only the trailers trailer: put process_trailers() options into a struct
2017-08-26Merge branch 'pb/trailers-from-command-line'Libravatar Junio C Hamano1-0/+66
"git interpret-trailers" learned to take the trailer specifications from the command line that overrides the configured values. * pb/trailers-from-command-line: interpret-trailers: fix documentation typo interpret-trailers: add options for actions trailers: introduce struct new_trailer_item trailers: export action enums and corresponding lookup functions
2017-08-26Merge branch 'jt/diff-color-move-fix'Libravatar Junio C Hamano1-68/+193
A handful of bugfixes and an improvement to "diff --color-moved". * jt/diff-color-move-fix: diff: define block by number of alphanumeric chars diff: respect MIN_BLOCK_LENGTH for last block diff: avoid redundantly clearing a flag
2017-08-26Merge branch 'sb/diff-color-move'Libravatar Junio C Hamano1-0/+434
"git diff" has been taught to optionally paint new lines that are the same as deleted lines elsewhere differently from genuinely new lines. * sb/diff-color-move: (25 commits) diff: document the new --color-moved setting diff.c: add dimming to moved line detection diff.c: color moved lines differently, plain mode diff.c: color moved lines differently diff.c: buffer all output if asked to diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY diff.c: emit_diff_symbol learns about DIFF_SYMBOL_STAT_SEP diff.c: convert word diffing to use emit_diff_symbol diff.c: convert show_stats to use emit_diff_symbol diff.c: convert emit_binary_diff_body to use emit_diff_symbol submodule.c: migrate diff output to use emit_diff_symbol diff.c: emit_diff_symbol learns DIFF_SYMBOL_REWRITE_DIFF diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES diff.c: emit_diff_symbol learns DIFF_SYMBOL_HEADER diff.c: emit_diff_symbol learns DIFF_SYMBOL_FILEPAIR_{PLUS, MINUS} diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_INCOMPLETE diff.c: emit_diff_symbol learns DIFF_SYMBOL_WORDS[_PORCELAIN] diff.c: migrate emit_line_checked to use emit_diff_symbol diff.c: emit_diff_symbol learns DIFF_SYMBOL_NO_LF_EOF diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_FRAGINFO ...
2017-08-24Merge branch 'lg/merge-signoff'Libravatar Junio C Hamano1-0/+69
"git merge" learned a "--signoff" option to add the Signed-off-by: trailer with the committer's name. * lg/merge-signoff: merge: add a --signoff flag
2017-08-23Merge branch 'hv/t5526-andand-chain-fix'Libravatar Junio C Hamano1-4/+4
Test fix. * hv/t5526-andand-chain-fix: t5526: fix some broken && chains
2017-08-23Merge branch 'as/grep-quiet-no-match-exit-code-fix'Libravatar Junio C Hamano1-0/+5
"git grep -L" and "git grep --quiet -L" reported different exit codes; this has been corrected. * as/grep-quiet-no-match-exit-code-fix: git-grep: correct exit code with --quiet and -L
2017-08-23Merge branch 'rs/t1002-do-not-use-sum'Libravatar Junio C Hamano2-35/+35
Test simplification. * rs/t1002-do-not-use-sum: t1002: stop using sum(1)
2017-08-23Merge branch 'nm/stash-untracked'Libravatar Junio C Hamano1-0/+17
"git stash -u" used the contents of the committed version of the ".gitignore" file to decide which paths are ignored, even when the file has local changes. The command has been taught to instead use the locally modified contents. * nm/stash-untracked: stash: clean untracked files before reset
2017-08-23merge: save merge state earlierLibravatar Michael J Gruber1-0/+15
If the `git merge` process is killed while waiting for the editor to finish, the merge state is lost but the prepared merge msg and tree is kept. So, a subsequent `git commit` creates a squashed merge even when the user asked for proper merge commit originally. Demonstrate the problem with a test crafted after the in t7502. The test requires EXECKEEPSPID (thus does not run under MINGW). Save the merge state earlier (in the non-squash case) so that it does not get lost. This makes the test pass. Reported-by: hIpPy <hippy2981@gmail.com> Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-22rerere: allow approxidate in gc.rerereResolved/gc.rerereUnresolvedLibravatar Junio C Hamano1-0/+2
These two configuration variables are described in the documentation to take an expiry period expressed in the number of days: gc.rerereResolved:: Records of conflicted merge you resolved earlier are kept for this many days when 'git rerere gc' is run. The default is 60 days. gc.rerereUnresolved:: Records of conflicted merge you have not resolved are kept for this many days when 'git rerere gc' is run. The default is 15 days. There is no strong reason not to allow a more general "approxidate" expiry specification, e.g. "5.days.ago", or "never". Rename the config_get_expiry() helper introduced in the previous step to git_config_get_expiry_in_days() and move it to a more generic place, config.c, and use date.c::parse_expiry_date() to do so. Give it an ability to allow the caller to tell among three cases (i.e. there is no "gc.rerereResolved" config, there is and it is correctly parsed into the *expiry variable, and there was an error in parsing the given value). The current caller can work correctly without using the return value, though. In the future, we may find other variables that only allow an integer that specifies "this many days" or other unit of time, and when it happens we may need to drop "_days" suffix from the name of the function and instead pass the "scale" value as another parameter. But this will do for now. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-22t4200: parameterize "rerere gc" custom expiry testLibravatar Junio C Hamano1-25/+33
The test creates a rerere database entry that is two days old, and tries to expire with three different custom expiry configuration (keep ones less than 5 days old, keep ones used less than 5 days ago, and expire everything right now). We'll be introducing a different way to spell the same "5 days" and "right now" parameter in a later step; parameterize the test to make it easier to test the new spelling when it happens. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-22t4200: gather "rerere gc" togetherLibravatar Junio C Hamano1-27/+27
Move the "rerere gc with custom expiry" test up, so that it is close to the existing basic "rerere gc" tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-22t4200: make "rerere gc" test more robustLibravatar Junio C Hamano1-5/+14
The test blindly trusted that there may be _some_ entries left in the rerere database, and used them by updating their timestamps to see if the gc threshold variables are honoured correctly. This won't work if there is no entry in the database when the test begins. Instead, clear the rerere database, and populate it with a few known entries (which are bogus, but for the purpose of testing "garbage collection", it does not matter---we want to make sure we collect old cruft, even if the files are corrupt rerere database entries), and use them for the expiry test. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-22t4200: give us a clean slate after "rerere gc" testsLibravatar Junio C Hamano1-0/+2
The "multiple identical conflicts" test counts the number of entries in the rerere database after trying a handful of mergy operations and recording their resolutions, but without initializing the rerere database to a known state, allowing the state left by previous tests to trigger a false failure. Make it robust by cleaning the database before it starts. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-22Merge branch 'mh/packed-ref-store'Libravatar Junio C Hamano2-0/+84
The "ref-store" code reorganization continues. * mh/packed-ref-store: (32 commits) files-backend: cheapen refname_available check when locking refs packed_ref_store: handle a packed-refs file that is a symlink read_packed_refs(): die if `packed-refs` contains bogus data t3210: add some tests of bogus packed-refs file contents repack_without_refs(): don't lock or unlock the packed refs commit_packed_refs(): remove call to `packed_refs_unlock()` clear_packed_ref_cache(): don't protest if the lock is held packed_refs_unlock(), packed_refs_is_locked(): new functions packed_refs_lock(): report errors via a `struct strbuf *err` packed_refs_lock(): function renamed from lock_packed_refs() commit_packed_refs(): use a staging file separate from the lockfile commit_packed_refs(): report errors rather than dying packed_ref_store: make class into a subclass of `ref_store` packed-backend: new module for handling packed references packed_read_raw_ref(): new function, replacing `resolve_packed_ref()` packed_ref_store: support iteration packed_peel_ref(): new function, extracted from `files_peel_ref()` repack_without_refs(): take a `packed_ref_store *` parameter get_packed_ref(): take a `packed_ref_store *` parameter rollback_packed_refs(): take a `packed_ref_store *` parameter ...
2017-08-22Merge branch 'sb/retire-t1200'Libravatar Junio C Hamano1-268/+0
A test script that outlived its usefulness has been removed. * sb/retire-t1200: t1200: remove t1200-tutorial.sh
2017-08-22Merge branch 'rs/t4062-obsd'Libravatar Junio C Hamano1-1/+3
Test portability fix. * rs/t4062-obsd: t4062: use less than 256 repetitions in regex
2017-08-22Merge branch 'jk/drop-sha1-entry-pos'Libravatar Junio C Hamano2-11/+1
Code clean-up. * jk/drop-sha1-entry-pos: sha1_file: drop experimental GIT_USE_LOOKUP search
2017-08-22Merge branch 'pw/am-signoff'Libravatar Junio C Hamano1-20/+63
"git am -s" has been taught that some input may end with a trailer block that is not Signed-off-by: and it should refrain from adding an extra blank line before adding a new sign-off in such a case. * pw/am-signoff: am: fix signoff when other trailers are present
2017-08-22Merge branch 'rs/t3700-clean-leftover'Libravatar Junio C Hamano1-0/+1
A test fix. * rs/t3700-clean-leftover: t3700: fix broken test under !POSIXPERM
2017-08-22Merge branch 'rs/in-obsd-basename-dirname-take-const'Libravatar Junio C Hamano1-2/+16
Portability fix. * rs/in-obsd-basename-dirname-take-const: test-path-utils: handle const parameter of basename and dirname
2017-08-22Merge branch 'rs/obsd-getcwd-workaround'Libravatar Junio C Hamano1-2/+28
Test portability fix for BSDs. * rs/obsd-getcwd-workaround: t0001: skip test with restrictive permissions if getpwd(3) respects them
2017-08-22Merge branch 'ma/parse-maybe-bool'Libravatar Junio C Hamano1-0/+7
Code clean-up. * ma/parse-maybe-bool: parse_decoration_style: drop unused argument `var` treewide: deprecate git_config_maybe_bool, use git_parse_maybe_bool config: make git_{config,parse}_maybe_bool equivalent config: introduce git_parse_maybe_bool_text t5334: document that git push --signed=1 does not work Doc/git-{push,send-pack}: correct --sign= to --signed=
2017-08-22Merge branch 'ab/ref-filter-no-contains'Libravatar Junio C Hamano1-1/+1
A test fix. * ab/ref-filter-no-contains: tests: don't give unportable ">" to "test" built-in, use -gt
2017-08-22Merge branch 'bw/clone-recursive-quiet'Libravatar Junio C Hamano1-0/+6
"git clone --recurse-submodules --quiet" did not pass the quiet option down to submodules. * bw/clone-recursive-quiet: clone: teach recursive clones to respect -q
2017-08-22Merge branch 'pw/sequence-rerere-autoupdate'Libravatar Junio C Hamano2-45/+132
Commands like "git rebase" accepted the --rerere-autoupdate option from the command line, but did not always use it. This has been fixed. * pw/sequence-rerere-autoupdate: cherry-pick/revert: reject --rerere-autoupdate when continuing cherry-pick/revert: remember --rerere-autoupdate t3504: use test_commit rebase -i: honor --rerere-autoupdate rebase: honor --rerere-autoupdate am: remember --rerere-autoupdate setting
2017-08-22Merge branch 'bw/push-options-recursively-to-submodules'Libravatar Junio C Hamano1-1/+24
"git push --recurse-submodules $there HEAD:$target" was not propagated down to the submodules, but now it is. * bw/push-options-recursively-to-submodules: submodule--helper: teach push-check to handle HEAD
2017-08-21perf: add test for writing the indexLibravatar Kevin Willford2-0/+52
A performance test for writing the index to be able to determine if changes to allocating ondisk structure help. Signed-off-by: Kevin Willford <kewillf@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19stash: add a test for stashing in a detached stateLibravatar Joel Teichroeb1-0/+12
All that we are really testing here is that the message is correct when we are not on any branch. All other functionality is already tested elsewhere. Signed-off-by: Joel Teichroeb <joel@teichroeb.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19stash: add a test for when apply fails during stash branchLibravatar Joel Teichroeb1-0/+14
If the return value of merge recursive is not checked, the stash could end up being dropped even though it was not applied properly Signed-off-by: Joel Teichroeb <joel@teichroeb.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19stash: add a test for stash create with no filesLibravatar Joel Teichroeb1-0/+8
Ensure the command suceeds and outputs nothing Signed-off-by: Joel Teichroeb <joel@teichroeb.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-19apply: file commited with CRLF should roundtrip diff and applyLibravatar Torsten Bögershausen1-6/+27
When a file had been commited with CRLF but now .gitattributes say "* text=auto" (or core.autocrlf is true), the following does not roundtrip, `git apply` fails: printf "Added line\r\n" >>file && git diff >patch && git checkout -- . && git apply patch Before applying the patch, the file from working tree is converted into the index format (clean filter, CRLF conversion, ...). Here, when commited with CRLF, the line endings should not be converted. Note that `git apply --index` or `git apply --cache` doesn't call convert_to_git() because the source material is already in index format. Analyze the patch if there is a) any context line with CRLF, or b) if any line with CRLF is to be removed. In this case the patch file `patch` has mixed line endings, for a) it looks like this: diff --git a/one b/one index 533790e..c30dea8 100644 --- a/one +++ b/one @@ -1 +1,2 @@ a\r +b\r And for b) it looks like this: diff --git a/one b/one index 533790e..485540d 100644 --- a/one +++ b/one @@ -1 +1 @@ -a\r +b\r If `git apply` detects that the patch itself has CRLF, (look at the line " a\r" or "-a\r" above), the new flag crlf_in_old is set in "struct patch" and two things will happen: - read_old_data() will not convert CRLF into LF by calling convert_to_git(..., SAFE_CRLF_KEEP_CRLF); - The WS_CR_AT_EOL bit is set in the "white space rule", CRLF are no longer treated as white space. While at there, make it clear that read_old_data() in apply.c knows what it wants convert_to_git() to do with respect to CRLF. In fact, this codepath is about applying a patch to a file in the filesystem, which may not exist in the index, or may exist but may not match what is recorded in the index, or in the extreme case, we may not even be in a Git repository. If convert_to_git() peeked at the index while doing its work, it *would* be a bug. Pass NULL instead of &the_index to convert_to_git() to make sure we catch future bugs to clarify this. Update the test in t4124: split one test case into 3: - Detect the " a\r" line in the patch - Detect the "-a\r" line in the patch - Use LF in repo and CLRF in the worktree. Reported-by: Anthony Sottile <asottile@umich.edu> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-17git-grep: correct exit code with --quiet and -LLibravatar Anthony Sottile1-0/+5
The handling of `status_only` no longer interferes with the handling of `unmatch_name_only`. `--quiet` no longer affects the exit code when using `-L`/`--files-without-match`. Signed-off-by: Anthony Sottile <asottile@umich.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-17t5526: fix some broken && chainsLibravatar Heiko Voigt1-4/+4
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-16diff: define block by number of alphanumeric charsLibravatar Jonathan Tan1-69/+157
The existing behavior of diff --color-moved=zebra does not define the minimum size of a block at all, instead relying on a heuristic applied later to filter out sets of adjacent moved lines that are shorter than 3 lines long. This can be confusing, because a block could thus be colored as moved at the source but not at the destination (or vice versa), depending on its neighbors. Instead, teach diff that the minimum size of a block is 20 alphanumeric characters, the same heuristic used by "git blame". This allows diff to still exclude uninteresting lines appearing on their own (such as those solely consisting of one or a few closing braces), as was the intention of the adjacent-moved-line heuristic. This requires a change in some tests in that some of their lines are no longer considered to be part of a block, because they are too short. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-16diff: respect MIN_BLOCK_LENGTH for last blockLibravatar Jonathan Tan1-0/+37
Currently, MIN_BLOCK_LENGTH is only checked when diff encounters a line that does not belong to the current block. In particular, this means that MIN_BLOCK_LENGTH is not checked after all lines are encountered. Perform that check. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-15t1002: stop using sum(1)Libravatar René Scharfe2-35/+35
sum(1) is a command for calculating checksums of the contents of files. It was part of early editions of Unix ("Research Unix", 1972/1973, [1]). cksum(1) appeared in 4.4BSD (1993) as a replacement [2], and became part of POSIX.1-2008 [3]. OpenBSD 5.6 (2014) removed sum(1). We only use sum(1) in t1002 to check for changes in three files. On MinGW we use md5sum(1) instead. We could switch to the standard command cksum(1) for all platforms; MinGW comes with GNU coreutils now, which provides sum(1), cksum(1) and md5sum(1). Use our standard method for checking for file changes instead: test_cmp. It's more convenient because it shows differences nicely, it's faster on MinGW because we have a special implementation there based only on shell-internal commands, it's simpler as it allows us to avoid stripping out unnecessary entries from the checksum file using grep(1), and it's more consistent with the rest of the test suite. We already compare changed files with their expected new contents using diff(1), so we don't need to check with "test_must_fail test_cmp" if they differ from their original state. A later patch could convert the direct diff(1) calls to test_cmp as well. With all sum(1) calls gone, remove the MinGW-specific implementation from test-lib.sh as well. [1] http://minnie.tuhs.org/cgi-bin/utree.pl?file=V3/man/man1/sum.1 [2] http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/share/man/cat1/cksum.0 [3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cksum.html Signed-off-by: René Scharfe <l.s.r@web.de> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-15pretty: support normalization options for %(trailers)Libravatar Jeff King1-0/+33
The interpret-trailers command recently learned some options to make its output easier to parse (for a caller whose only interested in picking out the trailer values). But it's not very efficient for asking for the trailers of many commits in a single invocation. We already have "%(trailers)" to do that, but it doesn't know about unfolding or omitting non-trailers. Let's plumb those options through, so you can have the best of both. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-15t4205: refactor %(trailers) testsLibravatar Jeff King1-8/+12
We currently have one test for %(trailers). In preparation for more, let's refactor a few bits: - move the commit creation to its own setup step so it can be reused by multiple tests - add a trailer with whitespace continuation (to confirm that it is left untouched) - fix the sample text which claims the placeholder is %bT. This was switched long ago to %(trailers) - replace one "cat" with an "echo" when generating the expected output. This saves a process (and sets a better pattern for future tests to follow). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-15interpret-trailers: add an option to unfold valuesLibravatar Jeff King1-0/+21
The point of "--only-trailers" is to give a caller an output that's easy for them to parse. Getting rid of the non-trailer material helps, but we still may see more complicated syntax like whitespace continuation. Let's add an option to unfold any continuation, giving the output as a single "key: value" line per trailer. As a bonus, this could be used even without --only-trailers to clean up unusual formatting in the incoming data. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-15interpret-trailers: add an option to show only existing trailersLibravatar Jeff King1-0/+16
It can be useful to invoke interpret-trailers for the primary purpose of parsing existing trailers. But in that case, we don't want to apply existing ifMissing or ifExists rules from the config. Let's add a special mode where we avoid applying those rules. Coupled with --only-trailers, this gives us a reasonable parsing tool. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>