summaryrefslogtreecommitdiff
path: root/t/t7607-merge-overwrite.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-05-08merge-recursive: fix overwriting dirty files involved in renamesLibravatar Elijah Newren1-1/+1
This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of dirty files that are involved in directory rename detection will be added in a subsequent commit. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-11Revert "Merge branch 'en/rename-directory-detection'"Libravatar Junio C Hamano1-1/+1
This reverts commit e4bb62fa1eeee689744b413e29a50b4d1dae6886, reversing changes made to 468165c1d8a442994a825f3684528361727cd8c0. The topic appears to inflict severe regression in renaming merges, even though the promise of it was that it would improve them. We do not yet know which exact change in the topic was wrong, but in the meantime, let's play it safe and revert it out of 'master' before real Git-using projects are harmed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-27merge-recursive: fix overwriting dirty files involved in renamesLibravatar Elijah Newren1-1/+1
This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of dirty files that are involved in directory rename detection will be added in a subsequent commit. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-19Tighten and correct a few testcases for merging and cherry-pickingLibravatar Elijah Newren1-1/+4
t3501 had a testcase originally added in 05f2dfb965 (cherry-pick: demonstrate a segmentation fault, 2016-11-26) to ensure cherry-pick wouldn't segfault when working with a dirty file involved in a rename. While the segfault was fixed, there was another problem this test demonstrated: namely, that git would overwrite a dirty file involved in a rename. Further, the test encoded a "successful merge" and overwriting of this file as correct behavior. Modify the test so that it would still catch the segfault, but to require the correct behavior. Mark it as test_expect_failure for now too, since this second bug is not yet fixed. t7607 had a test added in 30fd3a5425 (merge overwrites unstaged changes in renamed file, 2012-04-15) specific to looking for a merge overwriting a dirty file involved in a rename, but it too actually encoded what I would term incorrect behavior: it expected the merge to succeed. Fix that, and add a few more checks to make sure that the merge really does produce the expected results. Reviewed-By: Stefan Beller <sbeller@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13Merge branch 'ah/unpack-trees-advice-messages'Libravatar Junio C Hamano1-1/+1
Grammofix. * ah/unpack-trees-advice-messages: unpack-trees: fix English grammar in do-this-before-that messages
2016-06-27unpack-trees: fix English grammar in do-this-before-that messagesLibravatar Alex Henrie1-1/+1
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17tests: unpack-trees: update to use test_i18n* functionsLibravatar Vasco Almeida1-1/+1
Use functions test_i18ncmp and test_i18ngrep to successfully pass tests running under GETTEXT_POISON. The output strings compared to in these test were marked for translation in ed47fdf ("i18n: unpack-trees: mark strings for translation", 2016-04-09) and later improved in 2e3926b ("i18n: unpack-trees: avoid substituting only a verb in sentences", 2016-05-12). Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases)Libravatar Johannes Sixt1-3/+2
There are many instances where the treatment of symbolic links in the object model and the algorithms are tested, but where it is not necessary to actually have a symbolic link in the worktree. Make adjustments to the tests and remove the SYMLINKS prerequisite when appropriate in trivial cases, where "trivial" means: - merely a replacement of 'ln -s a b && git add b' by test_ln_s_add is needed; - a test for symbolic link on the file system can be split off (and remains protected by SYMLINKS); - existing code is equivalent to test_ln_s_add. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15merge overwrites unstaged changes in renamed fileLibravatar Clemens Buchacher1-0/+9
Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-21unpack-trees: print "Aborting" to stderrLibravatar Michael J Gruber1-0/+1
display_error_msgs() prints all the errors to stderr already (if any), followed by "Aborting" (if any) to stdout. Make the latter go to stderr instead. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-14i18n: use test_i18n{cmp,grep} in t7600, t7607, t7611 and t7811Libravatar Junio C Hamano1-5/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-01Merge branch 'ab/i18n-st'Libravatar Junio C Hamano1-2/+8
* ab/i18n-st: (69 commits) i18n: git-shortlog basic messages i18n: git-revert split up "could not revert/apply" message i18n: git-revert literal "me" messages i18n: git-revert "Your local changes" message i18n: git-revert basic messages i18n: git-notes GIT_NOTES_REWRITE_MODE error message i18n: git-notes basic commands i18n: git-gc "Auto packing the repository" message i18n: git-gc basic messages i18n: git-describe basic messages i18n: git-clean clean.requireForce messages i18n: git-clean basic messages i18n: git-bundle basic messages i18n: git-archive basic messages i18n: git-status "renamed: " message i18n: git-status "Initial commit" message i18n: git-status "Changes to be committed" message i18n: git-status shortstatus messages i18n: git-status "nothing to commit" messages i18n: git-status basic messages ... Conflicts: builtin/branch.c builtin/checkout.c builtin/clone.c builtin/commit.c builtin/grep.c builtin/merge.c builtin/push.c builtin/revert.c t/t3507-cherry-pick-conflict.sh t/t7607-merge-overwrite.sh
2011-03-25merge: merge unborn index before setting refLibravatar Jeff King1-0/+4
When we merge into an unborn branch, there are basically two steps: 1. Write the sha1 of the new commit into the ref pointed to by HEAD. 2. Update the index with the new content, and check it out to the working tree. We currently do them in this order. However, (2) is the step that is much more likely to fail, since it can be blocked by things like untracked working tree files. When it does, the merge fails and we are left with an empty index but an updated HEAD. This patch switches the order, so that a failure in updating the index leaves us unchanged. Of course, a failure in updating the ref now leaves us with an updated index and mis-matched HEAD. That is arguably not much better, but it is probably less likely to actually happen. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-25t7607: clean up stray untracked fileLibravatar Jeff King1-1/+2
This file ends up conflicting with the test just after it (causing the "git merge" to fail). Neither test is to blame for the bug, though. It looks like the merge in 1a9fe45 (Merge branch 'tr/merge-unborn-clobber', 2011-02-09) is what caused the conflict. We didn't notice because the follow-on test is already marked as expect_failure (even though it has since been fixed, and now succeeds once the untracked file is moved out of the way). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-25t7607: mark known breakage in test 11 as fixedLibravatar Jeff King1-1/+1
This was fixed by 1d718a51 (do not overwrite untracked symlinks, 2011-02-20). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-merge basic messagesLibravatar Ævar Arnfjörð Bjarmason1-2/+8
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-09Merge branch 'tr/merge-unborn-clobber'Libravatar Junio C Hamano1-0/+16
* tr/merge-unborn-clobber: Exhibit merge bug that clobbers index&WT Conflicts: t/t7607-merge-overwrite.sh
2010-11-29Merge branch 'cb/leading-path-removal'Libravatar Junio C Hamano1-23/+79
* cb/leading-path-removal: use persistent memory for rejected paths do not overwrite files in leading path lstat_cache: optionally return match_len add function check_ok_to_remove() t7607: add leading-path tests t7607: use test-lib functions and check MERGE_HEAD Conflicts: t/t7607-merge-overwrite.sh
2010-11-24Merge branch 'cb/maint-orphan-merge-noclobber'Libravatar Junio C Hamano1-0/+16
* cb/maint-orphan-merge-noclobber: do not overwrite untracked during merge from unborn branch
2010-11-15use persistent memory for rejected pathsLibravatar Clemens Buchacher1-3/+16
An aborted merge prints the list of rejected paths as part of the error message. Since commit f66caaf9 (do not overwrite files in leading path), some of those paths do not have static buffers, so we have to keep a copy. Use string_list's to accomplish this. This changes the order of the list to the order in which the paths are processed. Previously, it was reversed. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-15do not overwrite untracked during merge from unborn branchLibravatar Clemens Buchacher1-0/+16
In case HEAD does not point to a valid commit yet, merge is implemented as a hard reset. This will cause untracked files to be overwritten. Instead, assume the empty tree for HEAD and do a regular merge. An untracked file will cause the merge to abort and do nothing. If no conflicting files are present, the merge will have the same effect as a hard reset. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-13do not overwrite files in leading pathLibravatar Clemens Buchacher1-1/+1
If the work tree contains an untracked file x, and unpack-trees wants to checkout a path x/*, the file x is removed unconditionally. Instead, apply the same checks that are normally used for untracked files, and abort if the file cannot be removed. Signed-off-by: Clemens Buchacher <drizzd@aon.at>
2010-10-13t7607: add leading-path testsLibravatar Clemens Buchacher1-0/+51
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
2010-10-13t7607: use test-lib functions and check MERGE_HEADLibravatar Clemens Buchacher1-23/+15
Use the test_commit and test_path_is_missing functions from the test library. Also make sure that a merge which fails due to pre-merge checks aborts properly and does not leave MERGE_HEAD behind. The "will not overwrite removed file" test is an exception to this. It notices the untracked file at a stage where the merge is already well under way. Therefore we cannot abort the merge without major restructuring. See the following thread for more details. http://mid.gmane.org/7vskopwxej.fsf@gitster.siamese.dyndns.org Signed-off-by: Clemens Buchacher <drizzd@aon.at>
2010-08-25Exhibit merge bug that clobbers index&WTLibravatar Thomas Rast1-0/+16
Running git-merge on an unborn branch is supposed to do an index-level merge with the other side, and then update the branch name there. In the common case where the index was empty at the start, this makes 'git pull otherrepo branch' a convenient way to populate the history after 'git init'. However, if the index was *not* empty, git-merge silently discards *both index and worktree* copies of all files that were tracked, leading to data loss. Exhibit this bug. Reported-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-20Convert "! git" to "test_must_fail git"Libravatar Jared Hance1-6/+6
test_must_fail will account for segfaults in git, so it should be used instead of "! git" This patch does not change any of the commands that use pipes. Signed-off-by: Jared Hance <jaredhance@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-15merge-recursive: do not clobber untracked working tree garbageLibravatar Junio C Hamano1-1/+1
When merge-recursive wanted to create a new file in the work tree (either as the final result, or a hint for reference purposes while delete/modify conflicts), it unconditionally overwrote an untracked file in the working tree. Be careful not to lose whatever the user has that is not tracked. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-15modify/delete conflict resolution overwrites untracked fileLibravatar Clemens Buchacher1-0/+87
If a file was removed in HEAD, but modified in MERGE_HEAD, recursive merge will result in a "CONFLICT (delete/modify)". If the (now untracked) file already exists and was not added to the index, it is overwritten with the conflict resolution contents. In similar situations (cf. test 2), the merge would abort with "error: Untracked working tree 'file' would be overwritten by merge." The same should happen in this case. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>