summaryrefslogtreecommitdiff
path: root/t/t3512-cherry-pick-submodule.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-02-13Merge branch 'pw/sequencer-in-process-commit'Libravatar Junio C Hamano1-1/+0
The sequencer infrastructure is shared across "git cherry-pick", "git rebase -i", etc., and has always spawned "git commit" when it needs to create a commit. It has been taught to do so internally, when able, by reusing the codepath "git commit" itself uses, which gives performance boost for a few tens of percents in some sample scenarios. * pw/sequencer-in-process-commit: sequencer: run 'prepare-commit-msg' hook t7505: add tests for cherry-pick and rebase -i/-p t7505: style fixes sequencer: assign only free()able strings to gpg_sign sequencer: improve config handling t3512/t3513: remove KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1 sequencer: try to commit without forking 'git commit' sequencer: load commit related config sequencer: simplify adding Signed-off-by: trailer commit: move print_commit_summary() to libgit commit: move post-rewrite code to libgit Add a function to update HEAD after creating a commit commit: move empty message checks to libgit t3404: check intermediate squash messages
2017-11-24t3512/t3513: remove KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1Libravatar Phillip Wood1-1/+0
Now that the sequencer creates commits without forking 'git commit' it does not see an empty commit in these tests which fixes the known breakage. Note that logic for handling KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1 is not removed from lib-submodule-update.sh as it is still used by other tests. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-15merge-recursive: handle addition of submodule on our side of historyLibravatar Elijah Newren1-1/+1
The code for a newly added path assumed that the path was a normal file, and thus checked for there being a directory still being in the way of the file. Note that since unpack_trees() does path-in-the-way checks already, the only way for there to be a directory in the way at this point in the code, is if there is some kind of D/F conflict in the merge. For a submodule addition on HEAD's side of history, the submodule would have already been present. This means that we do expect there to be a directory present but should not consider it to be "in the way"; instead, it's the expected submodule. So, when there's a submodule addition from HEAD's side, don't bother checking the working copy for a directory in the way. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-12t/3512: demonstrate unrelated submodule/file conflict as cherry-pick failureLibravatar Stefan Beller1-0/+36
Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-14cherry-pick: add t3512 for submodule updatesLibravatar Jens Lehmann1-0/+13
Test that the cherry-pick command updates the work tree as expected (for submodule changes which don't result in conflicts). Set KNOWN_FAILURE_NOFF_MERGE_ATTEMPTS_TO_MERGE_REMOVED_SUBMODULE_FILES and KNOWN_FAILURE_NOFF_MERGE_DOESNT_CREATE_EMPTY_SUBMODULE_DIR to document that cherry-pick has the same --no-ff known failures merge has. Implement the KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT switch to expect the known failure that while cherry picking just a SHA-1 update for an ignored submodule the commit incorrectly fails with "The previous cherry-pick is now empty, possibly due to conflict resolution.". Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>