summaryrefslogtreecommitdiff
path: root/t/t4150-am.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-11-19t4*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-14/+14
Carefully excluding t4013 and t4015, which see independent development elsewhere at the time of writing, we use `main` as the default branch name in t4*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t4*.sh t4211/*.export && git checkout HEAD -- t4013\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Libravatar Johannes Schindelin1-0/+3
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-26tests: avoid variations of the `master` branch nameLibravatar Johannes Schindelin1-4/+4
The term `master` has a loaded history that serves as a constant reminder of racial injustice. The Git project has no desire to perpetuate this and already started avoiding it. The test suite uses variations of this name for branches other than the default one. Apart from t3200, where we just addressed this in the previous commit, those instances can be renamed in an automated manner because they do not require any changes outside of the test script, so let's do that. Seeing as the touched branches have very little (if anything) to do with the default branch, we choose to use a completely separate naming scheme: `topic_<number>` (it cannot be `topic-<number>` because t5515 uses the `test_oid` machinery with the term, and that machinery uses shell variables internally, whose names cannot contain dashes). This trick was performed by this (GNU) sed invocation: $ sed -i 's/master\([a-z0-9]\)/topic_\1/g' t/t*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13Merge branch 'ma/test-quote-cleanup'Libravatar Junio C Hamano1-4/+4
Test cleanup. * ma/test-quote-cleanup: t4104: modernize and simplify quoting t: don't spuriously close and reopen quotes
2020-08-06t: don't spuriously close and reopen quotesLibravatar Martin Ågren1-4/+4
In the test scripts, the recommended style is, e.g.: test_expect_success 'name' ' do-something somehow && do-some-more testing ' When using this style, any single quote in the multi-line test section is actually closing the lone single quotes that surround it. It can be a non-issue in practice: test_expect_success 'sed a little' ' sed -e 's/hi/lo/' in >out # "ok": no whitespace in s/hi/lo/ ' Or it can be a bug in the test, e.g., because variable interpolation happens before the test even begins executing: v=abc test_expect_success 'variable interpolation' ' v=def && echo '"$v"' # abc ' Change several such in-test single quotes to use double quotes instead or, in a few cases, drop them altogether. These were identified using some crude grepping. We're not fixing any test bugs here, but we're hopefully making these tests slightly easier to grok and to maintain. There are legitimate use cases for closing a quote and opening a new one, e.g., both '\'' and '"'"' can be used to produce a literal single quote. I'm not touching any of those here. In t9401, tuck the redirecting ">" to the filename while we're touching those lines. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-06apply: do not lazy fetch when applying binaryLibravatar Jonathan Tan1-0/+16
When applying a binary patch, as an optimization, "apply" checks if the postimage is already present. During this fetch, it is perfectly expected for the postimage not to be present, so there is no need to lazy-fetch missing objects. Teach "apply" not to lazy-fetch in this case. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-22t: fix whitespace around &&Libravatar Andrei Rybak1-1/+1
Add missing spaces before '&&' and switch tabs around '&&' to spaces. Also fix the space after redirection operator in t3701 while we're here. These issues were found using `git grep '[^ ]&&$'` and `git grep -P '&&\t' t/`. Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-20am: support --show-current-patch=diff to retrieve .git/rebase-apply/patchLibravatar Paolo Bonzini1-0/+10
When "git am --show-current-patch" was added in commit 984913a210 ("am: add --show-current-patch", 2018-02-12), "git am" started recommending it as a replacement for .git/rebase-merge/patch. Unfortunately the suggestion is somewhat misguided; for example, the output of "git am --show-current-patch" cannot be passed to "git apply" if it is encoded as quoted-printable or base64. Add a new mode to "git am --show-current-patch" in order to straighten the suggestion. Reported-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-20am: support --show-current-patch=raw as a synonym for--show-current-patchLibravatar Paolo Bonzini1-0/+10
When "git am --show-current-patch" was added in commit 984913a210 ("am: add --show-current-patch", 2018-02-12), "git am" started recommending it as a replacement for .git/rebase-merge/patch. Unfortunately the suggestion is somewhat misguided; for example, the output "git am --show-current-patch" cannot be passed to "git apply" if it is encoded as quoted-printable or base64. To simplify worktree operations and to avoid that users poke into .git, it would be better if "git am" also provided a mode that copies .git/rebase-merge/patch to stdout. One possibility could be to have completely separate options, introducing for example --show-current-message (for .git/rebase-apply/NNNN) and --show-current-diff (for .git/rebase-apply/patch), while possibly deprecating --show-current-patch. That would even remove the need for the first two patches in the series. However, the long common prefix would have prevented using an abbreviated option such as "--show". Therefore, I chose instead to add a string argument to --show-current-patch. The new argument is optional, so that "git am --show-current-patch"'s behavior remains backwards-compatible. The next choice to make is how to handle multiple --show-current-patch options. Right now, something like "git am --abort --show-current-patch" is rejected, and the previous suggestion would likewise have naturally rejected a command line like git am --show-current-message --show-current-diff Therefore, I decided to also reject for example git am --show-current-patch=diff --show-current-patch=raw In other words the whole of --show-current-patch=xxx (including the optional argument) is treated as the command mode. I found this to be more consistent and intuitive, even though it differs from the usual "last one wins" semantics of the git command line. Add the code to parse submodes based on the above design, where for now "raw" is the only valid submode. "raw" prints the full e-mail message just like "git am --show-current-patch". Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-03am: reload .gitattributes after patching itLibravatar brian m. carlson1-0/+52
When applying multiple patches with git am, or when rebasing using the am backend, it's possible that one of our patches has updated a gitattributes file. Currently, we cache this information, so if a file in a subsequent patch has attributes applied, the file will be written out with the attributes in place as of the time we started the rebase or am operation, not with the attributes applied by the previous patch. This problem does not occur when using the -m or -i flags to rebase. To ensure we write the correct data into the working tree, expire the cache after each patch that touches a path ending in ".gitattributes". Since we load these attributes in multiple separate files, we must expire them accordingly. Verify that both the am and rebase code paths work correctly, including the conflict marker size with am -3. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-13t4150: remove unused variableLibravatar Andrei Rybak1-3/+1
In commit 735285b403 ("am: fix signoff when other trailers are present", 2017-08-08) tests using variable $signoff were rewritten and it is no longer used, so just remove it from the test setup. Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27Merge branch 'sg/test-must-be-empty'Libravatar Junio C Hamano1-2/+2
Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s'
2018-08-21tests: use 'test_must_be_empty' instead of '! test -s'Libravatar SZEDER Gábor1-2/+2
Using 'test_must_be_empty' is preferable to '! test -s', because it gives a helpful error message if the given file is unexpectedly not empty, while the latter remains completely silent. Furthermore, it also catches cases when the given file unexpectedly does not exist at all. This patch was basically created by: sed -i -e 's/! test -s/test_must_be_empty/' t[0-9]*.sh with the following notable exceptions: - The '! test -s' check in '.gitmodules ignore=dirty suppresses submodules with untracked content' in 't7508-status.sh' is left as-is, because it's bogus and, therefore, it's subject of a dedicated patch. - The '! test -s' checks in 't9131-git-svn-empty-symlink.sh' and 't9135-git-svn-moved-branch-empty-file.sh' are immediately preceeded by a 'test -f' to ensure that the files exist in the first place. 'test_must_be_empty' ensures that as well, so those 'test -f' commands are removed as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-17Merge branch 'ar/t4150-am-scissors-test-fix'Libravatar Junio C Hamano1-19/+20
Test fix. * ar/t4150-am-scissors-test-fix: t4150: fix broken test for am --scissors
2018-08-06t4150: fix broken test for am --scissorsLibravatar Andrei Rybak1-19/+20
Tests for "git am --[no-]scissors" [1] work in the following way: 1. Create files with commit messages 2. Use these files to create expected commits 3. Generate eml file with patch from expected commits 4. Create commits using git am with these eml files 5. Compare these commits with expected The test for "git am --scissors" is supposed to take an e-mail with a scissors line and in-body "Subject:" header and demonstrate that the subject line from the e-mail itself is overridden by the in-body header and that only text below the scissors line is included in the commit message of the commit created by the invocation of "git am --scissors". However, the setup of the test incorrectly uses a commit without the scissors line and without the in-body header in the commit message, producing eml file not suitable for testing of "git am --scissors". This can be checked by intentionally breaking is_scissors_line function in mailinfo.c, for example, by changing string ">8", which is used by the test. With such change the test should fail, but does not. Fix broken test by generating eml file with scissors line and in-body header "Subject:". Since the two tests for --scissors and --no-scissors options are there to test cutting or keeping the commit message, update both tests to change the test file in the same way, which allows us to generate only one eml file to be passed to git am. To clarify the intention of the test, give files and tags more explicit names. [1]: introduced in bf72ac17d (t4150: tests for am --[no-]scissors, 2015-07-19) Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com> Reviewed-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-14t: switch $_z40 to $ZERO_OIDLibravatar brian m. carlson1-2/+2
Switch all uses of $_z40 to $ZERO_OID so that they work correctly with larger hashes. This commit was created by using the following sed command to modify all files in the t directory except t/test-lib.sh: sed -i 's/\$_z40/$ZERO_OID/g' Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-06Merge branch 'nd/rebase-show-current-patch'Libravatar Junio C Hamano1-0/+5
The new "--show-current-patch" option gives an end-user facing way to get the diff being applied when "git rebase" (and "git am") stops with a conflict. * nd/rebase-show-current-patch: rebase: introduce and use pseudo-ref REBASE_HEAD rebase: add --show-current-patch am: add --show-current-patch
2018-02-14am: support --quitLibravatar Nguyễn Thái Ngọc Duy1-0/+12
Among the "in progress" commands, only git-am and git-merge do not support --quit. Support --quit in git-am too. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-12am: add --show-current-patchLibravatar Nguyễn Thái Ngọc Duy1-0/+5
Pointing the user to $GIT_DIR/rebase-apply may encourage them to mess around in there, which is not a good thing. With this, the user does not have to keep the path around somewhere (because after a couple of commands, the path may be out of scrollback buffer) when they need to look at the patch. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-08am: fix signoff when other trailers are presentLibravatar Phillip Wood1-20/+63
If there was no 'Signed-off-by:' trailer but another trailer such as 'Reported-by:' then 'git am --signoff' would add a blank line between the existing trailers and the added 'Signed-off-by:' line. e.g. Rebase accepts '--rerere-autoupdate' as an option but only honors it if '-m' is also given. Fix it for a non-interactive rebase by passing on the option to 'git am' and 'git cherry-pick'. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Fix by using the code provided for this purpose in sequencer.c. Change the tests so that they check the formatting of the 'Signed-off-by:' lines rather than just grepping for them. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-11mailinfo: fix in-body header continuationsLibravatar Linus Torvalds1-2/+4
An empty line should stop any pending in-body headers, and start the actual body parsing. This also modifies the original test for the in-body headers to actually have a real commit body that starts with spaces, and changes the test to check that the long line matches _exactly_, and doesn't get extra data from the body. Fixes:6b4b013f1884 ("mailinfo: handle in-body header continuations") Cc: Jonathan Tan <jonathantanmy@google.com> Cc: Jeff King <peff@peff.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-21mailinfo: handle in-body header continuationsLibravatar Jonathan Tan1-0/+23
Mailinfo currently handles multi-line headers, but it does not handle multi-line in-body headers. Teach it to handle such headers, for example, for this input: From: author <author@example.com> Date: Fri, 9 Jun 2006 00:44:16 -0700 Subject: a very long broken line Subject: another very long broken line interpret the in-body subject to be "another very long broken line" instead of "another very long". An existing test (t/t5100/msg0015) has an indented line immediately after an in-body header - it has been modified to reflect the new functionality. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06am: support --patch-format=mboxrdLibravatar Eric Wong1-0/+20
Combined with "git format-patch --pretty=mboxrd", this should allow us to round-trip commit messages with embedded mbox "From " lines without corruption. Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-08Merge branch 'jc/builtin-am-signoff-regression-fix'Libravatar Junio C Hamano1-0/+48
Recent "git am" had regression when adding a Signed-off-by line with its "-s" option by an unintended tightening of how an existing trailer block is detected. * jc/builtin-am-signoff-regression-fix: am: match --signoff to the original scripted version
2015-09-06am: match --signoff to the original scripted versionLibravatar Junio C Hamano1-0/+48
Linus noticed that the recently reimplemented "git am -s" defines the trailer block too rigidly, resulting in an unnecessary blank line between the existing sign-offs and his new sign-off. An e-mail submission sent to Linus in real life ends with mixture of sign-offs and commentaries, e.g. title here message here Signed-off-by: Original Author <original@auth.or> [rv: tweaked frotz and nitfol] Signed-off-by: Re Viewer <rv@ew.er> Signed-off-by: Other Reviewer <other@rev.ewer> --- patch here Because the reimplementation reused append_signoff() helper that is used by other codepaths, which is unaware that people intermix such comments with their sign-offs in the trailer block, such a message was judged to end with a non-trailer, resulting in an extra blank line before adding a new sign-off. The original scripted version of "git am" used a lot looser definition, i.e. "if and only if there is no line that begins with Signed-off-by:, add a blank line before adding a new sign-off". For the upcoming release, stop using the append_signoff() in "git am" and reimplement the looser definition used by the scripted version to use only in "git am" to fix this regression in "am" while avoiding new regressions to other users of append_signoff(). In the longer term, we should look into loosening append_signoff() so that other codepaths that add a new sign-off behave the same way as "git am -s", but that is a task for post-release. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-01rerere: release lockfile in non-writing functionsLibravatar Jeff King1-0/+36
There's a bug in builtin/am.c in which we take a lock on MERGE_RR recursively. But rather than fix am.c, this patch fixes the confusing interface from rerere.c that caused the bug. Read on for the gory details. The setup_rerere() function both reads the existing MERGE_RR file, and takes MERGE_RR.lock. In the rerere() and rerere_forget() functions, we end up in write_rr(), which will then commit the lock file. But for functions like rerere_clear() that do not write to MERGE_RR, we expect the caller to have handled setup_rerere(). That caller would then need to release the lockfile, but it can't; the lock struct is local to rerere.c. For builtin/rerere.c, this is OK. We run a single rerere operation and then exit immediately, which has the side effect of rolling back the lockfile. But in builtin/am.c, this is actively wrong. If we run "git am -3 --skip", we call setup-rerere twice without releasing the lock: 1. The "--skip" causes us to call am_rerere_clear(), which calls setup_rerere(), but never drops the lock. 2. We then proceed to the next patch. 3. The "--3way" may cause us to call rerere() to handle conflicts in that patch, but we are already holding the lock. The lockfile code dies with: BUG: prepare_tempfile_object called for active object We could fix this by having rerere_clear() call rollback_lock_file(). But it feels a bit odd for it to roll back a lockfile that it did not itself take. So let's simplify the interface further, and handle setup_rerere in the function itself, taking away the question from the caller over whether they need to do so. We can give rerere_gc() the same treatment, as well (even though it doesn't have any callers besides builtin/rerere.c at this point). Note that these functions don't take flags from their callers to pass along to setup_rerere; that's OK, because the flags would not be meaningful for what they are doing. Both of those functions need to hold the lock because even though they do not write to MERGE_RR, they are still writing and should be protected from a simultaneous "rerere" run. But rerere_remaining(), "rerere diff", and "rerere status" are all read-only operations. They want to setup_rerere(), but do not care about taking the lock in the first place. Since our update of MERGE_RR is the usual atomic rename done by commit_lock_file, they can just do a lockless read. For that, we teach setup_rerere a READONLY flag to avoid the lock. As a bonus, this pushes builtin/rerere.c's setup_rerere call closer to the functions that use it. Which means that "git rerere totally-bogus-command" will no longer silently exit(0) in a repository without rerere enabled. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-04git-am: add am.threeWay config variableLibravatar Remi Lespinet1-0/+19
Add the am.threeWay configuration variable to use the -3 or --3way option of git am by default. When am.threeway is set and not desired for a specific git am command, the --no-3way option can be used to override it. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'pt/am-tests'Libravatar Junio C Hamano1-0/+217
* pt/am-tests: t3901: test git-am encoding conversion t3418: non-interactive rebase --continue with rerere enabled t4150: tests for am --[no-]scissors t4150: am with post-applypatch hook t4150: am with pre-applypatch hook t4150: am with applypatch-msg hook t4150: am --resolved fails if index has unmerged entries t4150: am --resolved fails if index has no changes t4150: am refuses patches when paused t4151: am --abort will keep dirty index intact t4150: am fails if index is dirty t4150: am.messageid really adds the message id
2015-08-03Merge branch 'pt/am-foreign'Libravatar Junio C Hamano1-0/+82
Various enhancements around "git am" reading patches generated by foreign SCM. * pt/am-foreign: am: teach mercurial patch parser how to read from stdin am: use gmtime() to parse mercurial patch date t4150: test applying StGit series am: teach StGit patch parser how to read from stdin t4150: test applying StGit patch
2015-07-24Revert "git-am: add am.threeWay config variable"Libravatar Junio C Hamano1-19/+0
This reverts commit d96a275b91bae1800cd43be0651e886e7e042a17. It used to be possible to apply a patch series with "git am mbox" and then only after seeing a failure, switch to three-way mode via "git am -3" (no other options or arguments). The commit being reverted broke this workflow. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20t4150: tests for am --[no-]scissorsLibravatar Paul Tan1-0/+48
Since 017678b (am/mailinfo: Disable scissors processing by default, 2009-08-26), git-am supported the --[no-]scissors option, passing it to git-mailinfo. Add tests to ensure that git-am will pass the --scissors option to git-mailinfo, and that --no-scissors will override the configuration setting of mailinfo.scissors. Reviewed-by: Stefan Beller <sbeller@google.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20t4150: am with post-applypatch hookLibravatar Paul Tan1-0/+38
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am.sh will invoke the post-applypatch hook after the patch is applied and a commit is made. The exit code of the hook is ignored. Add tests for this hook. Helped-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Stefan Beller <sbeller@google.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20t4150: am with pre-applypatch hookLibravatar Paul Tan1-0/+33
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am.sg will invoke the pre-applypatch hook after applying the patch to the index, but before a commit is made. Should the hook exit with a non-zero status, git am will exit. Add tests for this hook. Helped-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Stefan Beller <sbeller@google.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20t4150: am with applypatch-msg hookLibravatar Paul Tan1-0/+35
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am will invoke the applypatch-msg hooks just after extracting the patch message. If the applypatch-msg hook exits with a non-zero status, git-am abort before even applying the patch to the index. Add tests for this hook. Helped-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Stefan Beller <sbeller@google.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20t4150: am --resolved fails if index has unmerged entriesLibravatar Paul Tan1-0/+13
Since c1d1128 (git-am --resolved: more usable error message., 2006-04-28), git-am --resolved will check to see if there are any unmerged entries, and will error out with a user-friendly error message if there are. Add a test for this. Reviewed-by: Stefan Beller <sbeller@google.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20t4150: am --resolved fails if index has no changesLibravatar Paul Tan1-0/+12
Since 6d28644 (git-am: do not allow empty commits by mistake., 2006-02-23), git-am --resolved will check to see if the index has any changes to prevent the user from creating an empty commit by mistake. Add a test for this. Reviewed-by: Stefan Beller <sbeller@google.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20t4150: am refuses patches when pausedLibravatar Paul Tan1-0/+14
Since c95b138 (Fix git-am safety checks, 2006-09-15), when there is a session in progress, git-am will check the command-line arguments and standard input to ensure that the user does not pass it any patches. Add a test for this. Reviewed-by: Stefan Beller <sbeller@google.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-20t4150: am fails if index is dirtyLibravatar Paul Tan1-0/+12
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), git-am will ensure that the index is clean before applying the patch. This is to prevent changes unrelated to the patch from being committed. Add a test for this check. Reviewed-by: Stefan Beller <sbeller@google.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-07t4150: am.messageid really adds the message idLibravatar Paul Tan1-0/+12
Since a078f73 (git-am: add --message-id/--no-message-id, 2014-11-25), the am.messageid setting determines whether the --message-id option is set by default. Add a test for this. Signed-off-by: Paul Tan <pyokagan@gmail.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-15am: teach mercurial patch parser how to read from stdinLibravatar Paul Tan1-0/+10
git-mailsplit, which splits mbox patches, will read the patch from stdin when the filename is "-" or there are no files listed on the command-line. To be consistent with this behavior, teach the mercurial patch parser to read from stdin if the filename is "-" or no files are listed on the command-line. Based-on-patch-by: Chris Packham <judge.packham@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-15am: use gmtime() to parse mercurial patch dateLibravatar Paul Tan1-0/+23
An example of the line in a mercurial patch that specifies the date of the commit would be: # Date 1433753301 25200 where the first number is the number of seconds since the unix epoch (in UTC), and the second number is the offset of the timezone, in second s west of UTC (negative if the timezone is east of UTC). git-am uses localtime() to break down the first number into its components (year, month, day, hours, minutes, seconds etc.). However, the returned components are relative to the user's time zone. As a result, if the user's time zone does not match the time zone specified in the patch, the resulting commit will have the wrong author date. Fix this by using gmtime() instead, which uses UTC instead of the user's time zone. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-15t4150: test applying StGit seriesLibravatar Paul Tan1-0/+17
A StGit series is a directory containing a "series" file which begins with the line: # This series applies on GIT commit XXXXX where XXXXX is the commit ID that the patch series applies on. Every following line names a patch in the directory to be applied. Test that git-am, when given this "series" file, is able to detect it as an StGit series and apply all the patches in the series. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-15am: teach StGit patch parser how to read from stdinLibravatar Paul Tan1-0/+10
git-mailsplit, which splits mbox patches, will read the patch from stdin when the filename is "-" or there are no files listed on the command-line. To be consistent with this behavior, teach the StGit patch parser to read from stdin if the filename is "-" or no files are listed on the command-line. Based-on-patch-by: Chris Packham <judge.packham@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-08t4150: test applying StGit patchLibravatar Paul Tan1-0/+22
By default, an StGit patch separates the subject from the commit message and headers as follows: $subject From: $author_name <$author_email> $message --- $diffstats We test git-am's ability to detect such a patch as an StGit patch, and its ability to be able to extract the commit author, date and message from such a patch. Based-on-patch-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-04git-am: add am.threeWay config variableLibravatar Remi Lespinet1-0/+19
Add the am.threeWay configuration variable to use the -3 or --3way option of git am by default. When am.threeway is set and not desired for a specific git am command, the --no-3way option can be used to override it. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-04t4150-am: refactor am -3 testsLibravatar Remi Lespinet1-15/+11
Create a setup for git am -3 in a separate test instead of creating this setup each time. This prepares for the next commit which will use this setup as well. Signed-off-by: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25git-am: add --message-id/--no-message-idLibravatar Paolo Bonzini1-0/+23
Parse the option and pass it directly to git-mailinfo. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17t/am: use test_path_is_missing() where appropriateLibravatar Ramkumar Ramachandra1-17/+17
Replace instances of ! test -d with test_path_is_missing. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17am: handle stray $dotest directoryLibravatar Ramkumar Ramachandra1-0/+6
The following bug has been observed: $ git am # no input file ^C $ git am --abort Resolve operation not in progress, we are not resuming. This happens because the following test fails: test -d "$dotest" && test -f "$dotest/last" && test -f "$dotest/next" and the codepath for an "am in-progress" is not executed. It falls back to the codepath that treats this as a "fresh execution". Before rr/rebase-autostash, this condition was test -d "$dotest" It would incorrectly execute the "normal" am --abort codepath: git read-tree --reset -u HEAD ORIG_HEAD git reset ORIG_HEAD by incorrectly assuming that an am is "in progress" (i.e. ORIG_HEAD etc. was written during the previous execution). Notice that $ git am ^C executes nothing of significance, is equivalent to $ mkdir .git/rebase-apply Therefore, the correct solution is to treat .git/rebase-apply as a "stray directory" and remove it on --abort in the fresh-execution codepath. Also ensure that we're not called with --rebasing from git-rebase--am.sh; in that case, it is the responsibility of the caller to handle and stray directories. While at it, tell the user to run "git am --abort" to get rid of the stray $dotest directory, if she attempts anything else. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-22apply --whitespace=fix: avoid running over the postimage bufferLibravatar Junio C Hamano1-1/+1
Originally update-pre-post-images could assume that any whitespace fixing will make the result only shorter by unexpanding runs of leading SPs into HTs and removing trailing whitespaces at the end of lines. Updating the post-image we read from the patch to match the actual result can be performed in-place under this assumption. These days, however, we have tab-in-indent (aka Python) rule whose result can be longer than the original, and we do need to allocate a larger buffer than the input and replace the result. Fortunately the support for lengthening rewrite was already added when we began supporting "match while ignoring whitespace differences" mode in 86c91f91794c (git apply: option to ignore whitespace differences, 2009-08-04). We only need to correctly count the number of bytes necessary to hold the updated result and tell the function to allocate a new buffer. Signed-off-by: Junio C Hamano <gitster@pobox.com>