summaryrefslogtreecommitdiff
path: root/t/t3420-rebase-autostash.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-01-07rebase: implement --merge via the interactive machineryLibravatar Elijah Newren1-72/+6
As part of an ongoing effort to make rebase have more uniform behavior, modify the merge backend to behave like the interactive one, by re-implementing it on top of the latter. Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options. As such, there really is not any need for having both git-rebase--merge and git-rebase--interactive anymore. Delete git-rebase--merge.sh and instead implement it in builtin/rebase.c. This results in a few deliberate but small user-visible changes: * The progress output is modified (see t3406 and t3420 for examples) * A few known test failures are now fixed (see t3421) * bash-prompt during a rebase --merge is now REBASE-i instead of REBASE-m. Reason: The prompt is a reflection of the backend in use; this allows users to report an issue to the git mailing list with the appropriate backend information, and allows advanced users to know where to search for relevant control files. (see t9903) testcase modification notes: t3406: --interactive and --merge had slightly different progress output while running; adjust a test to match the new expectation t3420: these test precise output while running, but rebase--am, rebase--merge, and rebase--interactive all were built on very different commands (am, merge-recursive, cherry-pick), so the tests expected different output for each type. Now we expect --merge and --interactive to have the same output. t3421: --interactive fixes some bugs in --merge! Wahoo! t9903: --merge uses the interactive backend so the prompt expected is now REBASE-i. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-18Merge branch 'js/rebase-autostash-detach-fix'Libravatar Junio C Hamano1-0/+8
"git rebase --autostash" did not correctly re-attach the HEAD at times. * js/rebase-autostash-detach-fix: built-in rebase --autostash: leave the current branch alone if possible built-in rebase: demonstrate regression with --autostash
2018-11-08built-in rebase --autostash: leave the current branch alone if possibleLibravatar Johannes Schindelin1-1/+1
When we converted a `git reset --hard` call in the original Unix shell script to built-in code, we asked to reset the worktree and the index and explicitly *not* to detach the HEAD. By mistake, though, we still did. Let's fix this. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-08built-in rebase: demonstrate regression with --autostashLibravatar Johannes Schindelin1-0/+8
An unnamed colleague of Ævar Arnfjörð Bjarmason reported a breakage where a `pull --rebase` (which did not really need to do anything but stash, see that nothing was changed, and apply the stash again) also detached the HEAD. This patch adds a minimal reproducer for this regression. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02Merge branch 'js/rebase-autostash-fix'Libravatar Junio C Hamano1-0/+10
"git rebase" that has recently been rewritten in C had a few issues in its "--autstash" feature, which have been corrected. * js/rebase-autostash-fix: rebase --autostash: fix issue with dirty submodules rebase --autostash: demonstrate a problem with dirty submodules rebase (autostash): use an explicit OID to apply the stash rebase (autostash): store the full OID in <state-dir>/autostash rebase (autostash): avoid duplicate call to state_dir_path()
2018-10-24rebase --autostash: fix issue with dirty submodulesLibravatar Johannes Schindelin1-1/+1
Since we cannot stash dirty submodules, there is no use in requiring them to be clean (or stash them when they are not). This brings the built-in rebase in line with the previous, scripted version, which also did not care about dirty submodules (but it was admittedly not very easy to figure that out). This fixes https://github.com/git-for-windows/git/issues/1820 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-24rebase --autostash: demonstrate a problem with dirty submodulesLibravatar Johannes Schindelin1-0/+10
It has been reported that dirty submodules cause problems with the built-in rebase when it is asked to autostash. The symptom is: fatal: Unexpected stash response: '' This patch adds a regression test that demonstrates that bug. Original report: https://github.com/git-for-windows/git/issues/1820 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-22t3420-rebase-autostash: don't try to grep non-existing filesLibravatar SZEDER Gábor1-4/+4
Several tests in 't3420-rebase-autostash.sh' start various rebase processes that are expected to fail because of merge conflicts. These tests then run '! grep' to ensure that the autostash feature did its job, and the dirty contents of a file is gone. However, due to the test repo's history and the choice of upstream branch that file shouldn't exist in the conflicted state at all. Consequently, this 'grep' doesn't fail as expected, because it can't find the dirty content, but it fails because it can't open the file. Tighten this check by using 'test_path_is_missing' instead, thereby avoiding unexpected errors from 'grep' as well. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-23t3420: fix under GETTEXT_POISON buildLibravatar Junio C Hamano1-2/+2
Newly added tests to t3420 in this series prepare expected human-readable output from "git rebase -i" and then compare the actual output with it. As the output from the command is designed to go through i18n/l10n, we need to use test_i18ncmp to tell GETTEXT_POISON build that it is OK the output does not match. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-19rebase: add more regression tests for console outputLibravatar Phillip Wood1-2/+69
Check the console output when using --autostash and the stash does not apply is what we expect. The test is quite strict but should catch any changes to the console output from the various rebase flavors. Thanks-to: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-19rebase: add regression tests for console outputLibravatar Phillip Wood1-3/+64
Check the console output when using --autostash and the stash applies cleanly is what we expect. The test is quite strict but should catch any changes to the console output from the various rebase flavors. Thanks-to: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11Spelling fixesLibravatar Ville Skyttä1-2/+2
<BAD> <CORRECTED> accidently accidentally commited committed dependancy dependency emtpy empty existance existence explicitely explicitly git-upload-achive git-upload-archive hierachy hierarchy indegee indegree intial initial mulitple multiple non-existant non-existent precendence. precedence. priviledged privileged programatically programmatically psuedo-binary pseudo-binary soemwhere somewhere successfull successful transfering transferring uncommited uncommitted unkown unknown usefull useful writting writing Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-29rebase -i: restore autostash on abortLibravatar Patrick Steinhardt1-0/+31
When we abort an interactive rebase we do so by calling `die_abort`, which cleans up after us by removing the rebase state directory. If the user has requested to use the autostash feature, though, the state directory may also contain a reference to the autostash, which will now be deleted. Fix the issue by trying to re-apply the autostash in `die_abort`. This will also handle the case where the autostash does not apply cleanly anymore by recording it in a user-visible stash. Reported-by: Daniel Hahler <git@thequod.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-10rebase: support --no-autostashLibravatar John Keeping1-0/+10
This is documented as an option but we don't actually accept it. Support it so that it is possible to override the "rebase.autostash" config variable. Reported-by: Daniel Hahler <genml+git-2014@thequod.de> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-20rebase -i: test "Nothing to do" case with autostashLibravatar Matthieu Moy1-0/+15
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-13rebase: finish_rebase() in noop rebaseLibravatar Ramkumar Ramachandra1-0/+11
In the following case $ git rebase master Current branch autostash-fix is up to date. the autostash is not applied automatically, because this codepath forgets to call finish_rebase(). Fix this. Also add a test to guard against regressions. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-13rebase: finish_rebase() in fast-forward rebaseLibravatar Ramkumar Ramachandra1-0/+11
In the following case $ git rebase master Fast-forwarded autostash-fix to master. The autostash is not applied automatically, because this codepath forgets to call finish_rebase(). Fix this. Also add a test to guard against regressions. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-29rebase: implement --[no-]autostash and rebase.autostashLibravatar Ramkumar Ramachandra1-0/+148
This new feature allows a rebase to be executed on a dirty worktree or index. It works by creating a temporary "dangling merge commit" out of the worktree and index changes (via 'git stash create'), and automatically applying it after a successful rebase or abort. rebase stores the SHA-1 hex of the temporary merge commit, along with the rest of the rebase state, in either .git/{rebase-merge,rebase-apply}/autostash depending on the kind of rebase. Since $state_dir is automatically removed at the end of a successful rebase or abort, so is the autostash. The advantage of this approach is that we do not affect the normal stash's reflogs, making the autostash invisible to the end-user. This means that you can use 'git stash' during a rebase as usual. When the autostash application results in a conflict, we push $state_dir/autostash onto the normal stash and remove $state_dir ending the rebase. The user can inspect the stash, and pop or drop at any time. Most significantly, this feature means that a caller like pull (with pull.rebase set to true) can easily be patched to remove the require_clean_work_tree restriction. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>