summaryrefslogtreecommitdiff
path: root/git-rebase--interactive.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-08-24i18n: fix git rebase interactive commit messagesLibravatar Jean-Noel Avila1-42/+3
For proper i18n, the logic cannot embed english specific processing. Signed-off-by: Jean-Noel Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-08Merge branch 'js/rebase-i-progress-tidy'Libravatar Junio C Hamano1-1/+1
Regression fix for an i18n topic already in 'master'. * js/rebase-i-progress-tidy: rebase-interactive: trim leading whitespace from progress count
2016-07-28rebase-interactive: trim leading whitespace from progress countLibravatar Johannes Sixt1-1/+1
Interactive rebase uses 'wc -l' to write the current patch number in a progress report. Some implementations of 'wc -l' produce spaces before the number, leading to ugly output such as Rebasing ( 3/8) Remove the spaces using a trivial arithmetic evaluation. Before 9588c52 (i18n: rebase-interactive: mark strings for translation) this was not a problem because printf was used to generate the text. Since that commit, the count is interpolated directly from a shell variable into the text, where the spaces remain. The total number of patches does not have this problem even though it is interpolated from a shell variable in the same manner, because the variable is set by an arithmetic evaluation. Later in the script, there is a virtually identical case where leading spaces are trimmed, but it uses a pattern substitution: todocount=$(git stripspace --strip-comments <"$todo" | wc -l) todocount=${todocount##* } I did not choose this idiom because it adds a line of code, and there is already an arithmetic evaluation in the vicinity of the line that is changed here. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13Merge branch 'ps/rebase-i-auto-unstash-upon-abort'Libravatar Junio C Hamano1-0/+1
"git rebase -i --autostash" did not restore the auto-stashed change when the operation was aborted. * ps/rebase-i-auto-unstash-upon-abort: rebase -i: restore autostash on abort
2016-07-13Merge branch 'va/i18n-even-more'Libravatar Junio C Hamano1-118/+172
More markings of messages for i18n, with updates to various tests to pass GETTEXT_POISON tests. One patch from the original submission dropped due to conflicts with jk/upload-pack-hook, which is still in flux. * va/i18n-even-more: (38 commits) t5541: become resilient to GETTEXT_POISON i18n: branch: mark comment when editing branch description for translation i18n: unmark die messages for translation i18n: submodule: escape shell variables inside eval_gettext i18n: submodule: join strings marked for translation i18n: init-db: join message pieces i18n: remote: allow translations to reorder message i18n: remote: mark URL fallback text for translation i18n: standardise messages i18n: sequencer: add period to error message i18n: merge: change command option help to lowercase i18n: merge: mark messages for translation i18n: notes: mark options for translation i18n: notes: mark strings for translation i18n: transport-helper.c: change N_() call to _() i18n: bisect: mark strings for translation t5523: use test_i18ngrep for negation t4153: fix negated test_i18ngrep call t9003: become resilient to GETTEXT_POISON tests: unpack-trees: update to use test_i18n* functions ...
2016-06-29rebase -i: restore autostash on abortLibravatar Patrick Steinhardt1-0/+1
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>
2016-06-27Merge branch 'em/newer-freebsd-shells-are-fine-with-returns'Libravatar Junio C Hamano1-2/+2
Comments about misbehaving FreeBSD shells have been clarified with the version number (9.x and before are broken, newer ones are OK). * em/newer-freebsd-shells-are-fine-with-returns: rebase: update comment about FreeBSD /bin/sh
2016-06-17i18n: rebase-interactive: mark strings for translationLibravatar Vasco Almeida1-90/+101
Mark strings in git-rebase--interactive.sh for translation. There is no need to source git-sh-i18n since git-rebase.sh already does so. Add git-rebase--interactive.sh to LOCALIZED_SH in Makefile in order to enable extracting strings marked for translation by xgettext. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: rebase-interactive: mark comments of squash for translationLibravatar Vasco Almeida1-13/+56
Mark comment messages of squash/fixup file ($squash_msg) for translation. Helper functions this_nth_commit_message and skip_nth_commit_message replace the previous method of making the comment messages (such as "This is the 2nd commit message:") aided by nth_string helper function. This step was taken as a workaround to enabled translation of entire sentences. However, doesn't change any text seen in English by the user, except for string "The first commit's message is:" which was changed to match the style of other instances. The test t3404-rebase-interactive.sh resorts to set_fake_editor which didn't account for GETTEXT_POISON. Fix it by assuming success when we find dummy gettext poison output where was supposed to find the first comment line "This is a combination of $count commits.". For that same message, use plural aware eval_ngettext instead of eval_gettext, since other languages have more complex plural forms. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: rebase-interactive: mark here-doc strings for translationLibravatar Vasco Almeida1-15/+15
Use pipe to send gettext output to git stripspace instead of the original method of using shell here-document, because command substitution '$(...)' would not take place inside the here-documents. The exception is the case of the last here-document redirecting to cat, in which commands substitution works and, thus, is preserved in this commit. t3404: adapt test to the strings newly marked for translation Test t3404-rebase-interactive.sh would fail under GETTEXT_POISON unless using test_i18ngrep. Add eval_ngettext fallback functions to be called when running, for instance, under GETTEXT_POISON. Otherwise, tests would fail under GETTEXT_POISON, or other build that doesn't support the GNU gettext, because that function could not be found. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17rebase: update comment about FreeBSD /bin/shLibravatar Ed Maste1-2/+2
Commit 9f50d32 introduced a fix for FreeBSD /bin/sh misbehaviour when dot-sourcing a file containing "return" statements outside of any function, from a function in another shell script. That issue affects FreeBSD 9.x, and is not present in the /bin/sh in FreeBSD 10.3 and later. Update the comment to clarify this. The example from 9f50d32's commit message produces the expected output on FreeBSD 10.3 and -CURRENT (the upcoming 11.0): % sh script1.sh only this line should show % Signed-off-by: Ed Maste <emaste@freebsd.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-03Merge branch 'js/rebase-i-dedup-call-to-rerere'Libravatar Junio C Hamano1-1/+0
"git rebase -i", after it fails to auto-resolve the conflict, had an unnecessary call to "git rerere" from its very early days, which was spotted recently; the call has been removed. * js/rebase-i-dedup-call-to-rerere: rebase -i: remove an unnecessary 'rerere' invocation
2016-05-31rebase -i: remove an unnecessary 'rerere' invocationLibravatar Johannes Sixt1-1/+0
Interactive rebase uses 'git cherry-pick' and 'git merge' to replay commits. Both invoke the 'rerere' machinery when they fail due to merge conflicts. Note that all code paths with these two commands also invoke the shell function die_with_patch when the commands fail. Since commit 629716d2 ("rerere: do use multiple variants") the second operation of the rerere machinery can be observed by a duplicated message "Recorded preimage for 'file'". This second operation records the same preimage as the first one and, hence, only wastes cycles. Remove the 'git rerere' invocation from die_with_patch. Shell function die_with_patch can be called after the failure of "git commit", too, which also calls into the rerere machinery, but it does so only after a successful commit to record the resolution. Therefore, it is wrong to call 'git rerere' from die_with_patch after "git commit" fails. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-23Merge branch 'jk/test-z-n-unquoted'Libravatar Junio C Hamano1-2/+2
t9xxx series has been updated primarily for readability, while fixing small bugs in it. A few scripted Porcelains have also been updated to fix possible bugs around their use of "test -z" and "test -n". * jk/test-z-n-unquoted: always quote shell arguments to test -z/-n t9103: modernize test style t9107: switch inverted single/double quotes in test t9107: use "return 1" instead of "exit 1" t9100,t3419: enclose all test code in single-quotes t/lib-git-svn: drop $remote_git_svn and $git_svn_id
2016-05-17Merge branch 'jk/rebase-interative-eval-fix'Libravatar Junio C Hamano1-0/+1
Portability enhancement for "rebase -i" to help platforms whose shell does not like "for i in <empty>" (which is not POSIX-kosher). * jk/rebase-interative-eval-fix: rebase--interactive: avoid empty list in shell for-loop
2016-05-14always quote shell arguments to test -z/-nLibravatar Jeff King1-2/+2
In shell code like: test -z $foo test -n $foo that does not quote its arguments, it's easy to think that it is actually looking at the contents of $foo in each case. But if $foo is empty, then "test" does not see any argument at all! The results are quite subtle. POSIX specifies that test's behavior depends on the number of arguments it sees, and if $foo is empty, it sees only one. The behavior in this case is: 1 argument: Exit true (0) if $1 is not null; otherwise, exit false. So in the "-z $foo" case, if $foo is empty, then we check that "-z" is non-null, and it returns success. Which happens to match what we expected. But for "-n $foo", if $foo is empty, we'll see that "-n" is non-null and still return success. That's the opposite of what we intended! Furthermore, if $foo contains whitespace, we'll end up with more than 2 arguments. The results in this case are generally unspecified (unless the first part of $foo happens to be a valid binary operator, in which case the results are specified but certainly not what we intended). And on top of this, even though "test -z $foo" _should_ work for the empty case, some older shells (reportedly ksh88) complain about the missing argument. So let's make sure we consistently quote our variable arguments to "test". After this patch, the results of: git grep 'test -[zn] [^"]' are empty. Reported-by: Armin Kunaschik <megabreit@googlemail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-10rebase--interactive: avoid empty list in shell for-loopLibravatar Jeff King1-0/+1
The $strategy_opts variable contains a space-separated list of strategy options, each individually shell-quoted. To loop over each, we "unwrap" them by doing an eval like: eval ' for opt in '"$strategy_opts"' do ... done ' Note the quoting that means we expand $strategy_opts inline in the code to be evaluated (which is the right thing because we want the IFS-split and de-quoting). If the variable is empty, however, we ask the shell to eval the following code: for opt in do ... done without anything between "in" and "do". Most modern shells are happy to treat that like a noop, but reportedly ksh88 on AIX considers it a syntax error. So let's catch the case that the variable is empty and skip the eval altogether (since we know the loop would be a noop anyway). Reported-by: Armin Kunaschik <megabreit@googlemail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-13Merge branch 'rt/rebase-i-shorten-stop-report'Libravatar Junio C Hamano1-1/+2
The commit object name reported when "rebase -i" stops has been shortened. * rt/rebase-i-shorten-stop-report: rebase-i: print an abbreviated hash when stop for editing
2016-03-28rebase-i: print an abbreviated hash when stop for editingLibravatar Ralf Thielow1-1/+2
The message that is shown when rebase-i stops for editing prints the full hash of the commit where it stopped which makes the message overflow to the next line on smaller terminal windows. Print an abbreviated hash instead. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-16Merge branch 'jc/sane-grep'Libravatar Junio C Hamano1-1/+2
Recent versions of GNU grep is pickier than before to decide if a file is "binary" and refuse to give line-oriented hits when we expect it to, unless explicitly told with "-a" option. As our scripted Porcelains use sane_grep wrapper for line-oriented data, even when the line may contain non-ASCII payload we took from end-user data, use "grep -a" to implement sane_grep wrapper when using an implementation of "grep" that takes the "-a" option. * jc/sane-grep: rebase-i: clarify "is this commit relevant?" test sane_grep: pass "-a" if grep accepts it
2016-03-10rebase-i: clarify "is this commit relevant?" testLibravatar Junio C Hamano1-1/+2
While I was checking all the call sites of sane_grep and sane_egrep, I noticed this one is somewhat strangely written. The lines in the file sane_grep works on all begin with 40-hex object name, so there is no real risk of confusing "test $(...) = ''" by finding something that begins with a dash, but using the status from sane_grep makes it a lot clearer what is going on. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-11rebase -i: remember merge options beyond continue actionsLibravatar Fabian Ruch1-11/+7
If the user explicitly specified a merge strategy or strategy options, continue to use that strategy/option after "rebase --continue". Add a test of the corrected behavior. If --merge is specified or implied by -s or -X, then "strategy and "strategy_opts" are set to values from which "strategy_args" can be derived; otherwise they are set to empty strings. Either way, their values are propagated from one step of an interactive rebase to the next via state files. "do_merge", on the other hand, is *not* propagated to later steps of an interactive rebase. Therefore, making the initialization of "strategy_args" conditional on "do_merge" being set prevents later steps of an interactive rebase from setting it correctly. Luckily, we don't need the "do_merge" guard at all. If the rebase was started without --merge, then "strategy" and "strategy_opts" are both the empty string, which results in "strategy_args" also being set to the empty string, which is just what we want in that situation. So remove the "do_merge" guard and derive "strategy_args" from "strategy" and "strategy_opts" every time. Reported-by: Diogo de Campos <campos@esss.com.br> Signed-off-by: Fabian Ruch <bafain@gmail.com> Helped-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-13rebase-i-exec: Allow space in SHELL_PATHLibravatar Fredrik Medley1-1/+1
On Windows, when Git is installed under "C:\Program Files\Git", SHELL_PATH will include a space. Fix "git rebase --interactive --exec" so that it works with spaces in SHELL_PATH. Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
2015-11-03Merge branch 'gr/rebase-i-drop-warn' into maintLibravatar Junio C Hamano1-0/+12
Recent update to "rebase -i" that tries to sanity check the edited insn sheet before it uses it has become too picky on Windows where CRLF left by the editor is turned into a trailing CR on the line read via the "read" built-in command. * gr/rebase-i-drop-warn: rebase-i: work around Windows CRLF line endings t3404: "rebase -i" gets broken when insn sheet uses CR/LF line endings
2015-10-28rebase-i: work around Windows CRLF line endingsLibravatar Junio C Hamano1-0/+12
Editors on Windows can and do save text files with CRLF line endings, which is the convention on the platform. We are seeing reports that the "read" command in a port of bash to the environment however does not strip the CRLF at the end, not adjusting for the same convention on the platform. This breaks the recently added sanity checks for the insn sheet fed to "rebase -i"; instead of an empty line (hence nothing in $command), the script was getting a lone CR in there. Special case a lone CR and treat it the same way as an empty line to work this around. This patch (also) passes the test with Git for Windows, where the issue was seen first. Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16Merge branch 'gr/rebase-i-drop-warn' into maintLibravatar Junio C Hamano1-35/+31
"git rebase -i" had a minor regression recently, which stopped considering a line that begins with an indented '#' in its insn sheet not a comment, which is now fixed. * gr/rebase-i-drop-warn: rebase-i: loosen over-eager check_bad_cmd check rebase-i: explicitly accept tab as separator in commands
2015-10-05rebase-i: loosen over-eager check_bad_cmd checkLibravatar Matthieu Moy1-33/+29
804098bb (git rebase -i: add static check for commands and SHA-1, 2015-06-29) tried to check all insns before running any in the todo list, but it did so by implementing its own parser that is a lot stricter than necessary. We used to allow lines that are indented (including comment lines), and we used to allow a whitespace between the insn and the commit object name to be HT, among other things, that are flagged as an invalid line by mistake. Fix this by using the same tokenizer that is used to parse the todo list file in the new check. Whether it's a good thing to accept indented comments is debatable (other commands like "git commit" do not accept them), but we already accepted them in the past, and some people and scripts rely on this behavior. Also, a line starting with space followed by a '#' cannot have any meaning other than being a comment, hence it doesn't harm to accept them as comments. Largely based on patch by: Junio C Hamano <gitster@pobox.com> [jc: updated test with quickfix from Torsten Bögershausen] Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-02rebase-i: explicitly accept tab as separator in commandsLibravatar Matthieu Moy1-2/+2
The git-rebase-todo is parsed several times with different parsers. In principle, the user input is normalized by transform_todo_ids and further parsing can be stricter. In case the user wrote pick deadbeef<TAB>commit message the parser of transform_todo_ids was considering the sha1 to be "deadbeef<TAB>commit", and was leaving the tab in the transformed sheet. In practice, this went unnoticed since the actual command interpretation was done later in do_next which did accept the tab as a separator. Make it explicit in the code of transform_todo_ids that tabs are accepted. This way, code that mimicks it will also accept tabs as separator. A similar construct appears in skip_unnecessary_picks, but this one comes after transform_todo_ids, hence reads the normalized format, so it needs not be changed. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-03Merge branch 'gr/rebase-i-drop-warn'Libravatar Junio C Hamano1-4/+188
Add "drop commit-object-name subject" command as another way to skip replaying of a commit in "rebase -i", and then punish those who do not use it (and instead just remove the lines) by throwing a warning. * gr/rebase-i-drop-warn: git rebase -i: add static check for commands and SHA-1 git rebase -i: warn about removed commits git-rebase -i: add command "drop" to remove a commit
2015-08-03Merge branch 'mr/rebase-i-customize-insn-sheet'Libravatar Junio C Hamano1-3/+17
"git rebase -i"'s list of todo is made configurable. * mr/rebase-i-customize-insn-sheet: git-rebase--interactive.sh: add config option for custom instruction format
2015-08-03Merge branch 'js/rebase-i-clean-up-upon-continue-to-skip' into maintLibravatar Junio C Hamano1-1/+5
Abandoning an already applied change in "git rebase -i" with "--continue" left CHERRY_PICK_HEAD and confused later steps. * js/rebase-i-clean-up-upon-continue-to-skip: rebase -i: do not leave a CHERRY_PICK_HEAD file behind t3404: demonstrate CHERRY_PICK_HEAD bug
2015-07-13Merge branch 'js/rebase-i-clean-up-upon-continue-to-skip'Libravatar Junio C Hamano1-1/+5
Abandoning an already applied change in "git rebase -i" with "--continue" left CHERRY_PICK_HEAD and confused later steps. * js/rebase-i-clean-up-upon-continue-to-skip: rebase -i: do not leave a CHERRY_PICK_HEAD file behind t3404: demonstrate CHERRY_PICK_HEAD bug
2015-06-30git rebase -i: add static check for commands and SHA-1Libravatar Galan Rémi1-0/+72
Check before the start of the rebasing if the commands exists, and for the commands expecting a SHA-1, check if the SHA-1 is present and corresponds to a commit. In case of error, print the error, stop git rebase and prompt the user to fix with 'git rebase --edit-todo' or to abort. This allows to avoid doing half of a rebase before finding an error and giving back what's left of the todo list to the user and prompt him to fix when it might be too late for him to do so (he might have to abort and restart the rebase). Signed-off-by: Galan Rémi <remi.galan-alfonso@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-30git rebase -i: warn about removed commitsLibravatar Galan Rémi1-3/+114
Check if commits were removed (i.e. a line was deleted) and print warnings or stop git rebase depending on the value of the configuration variable rebase.missingCommitsCheck. This patch gives the user the possibility to avoid silent loss of information (losing a commit through deleting the line in this case) if he wants. Add the configuration variable rebase.missingCommitsCheck. - When unset or set to "ignore", no checking is done. - When set to "warn", the commits are checked, warnings are displayed but git rebase still proceeds. - When set to "error", the commits are checked, warnings are displayed and the rebase is stopped. (The user can then use 'git rebase --edit-todo' and 'git rebase --continue', or 'git rebase --abort') rebase.missingCommitsCheck defaults to "ignore". Signed-off-by: Galan Rémi <remi.galan-alfonso@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-30git-rebase -i: add command "drop" to remove a commitLibravatar Galan Rémi1-1/+2
Instead of removing a line to remove the commit, you can use the command "drop" (just like "pick" or "edit"). It has the same effect as deleting the line (removing the commit) except that you keep a visual trace of your actions, allowing a better control and reducing the possibility of removing a commit by mistake. Signed-off-by: Galan Rémi <remi.galan-alfonso@ensimag.grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-29rebase -i: do not leave a CHERRY_PICK_HEAD file behindLibravatar Johannes Schindelin1-1/+5
When skipping commits whose changes were already applied via `git rebase --continue`, we need to clean up said file explicitly. The same is not true for `git rebase --skip` because that will execute `git reset --hard` as part of the "skip" handling in git-rebase.sh, even before git-rebase--interactive.sh is called. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25Merge branch 'mm/rebase-i-post-rewrite-exec' into maintLibravatar Junio C Hamano1-5/+5
"git rebase -i" fired post-rewrite hook when it shouldn't (namely, when it was told to stop sequencing with 'exec' insn). * mm/rebase-i-post-rewrite-exec: t5407: use <<- to align the expected output rebase -i: fix post-rewrite hook with failed exec command rebase -i: demonstrate incorrect behavior of post-rewrite
2015-06-15git-rebase--interactive.sh: add config option for custom instruction formatLibravatar Michael Rappazzo1-3/+17
A config option 'rebase.instructionFormat' can override the default 'oneline' format of the rebase instruction list. Since the list is parsed using the left, right or boundary mark plus the sha1, they are prepended to the instruction format. Signed-off-by: Michael Rappazzo <rappazzo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01Merge branch 'mm/rebase-i-post-rewrite-exec'Libravatar Junio C Hamano1-5/+5
"git rebase -i" fired post-rewrite hook when it shouldn't (namely, when it was told to stop sequencing with 'exec' insn). * mm/rebase-i-post-rewrite-exec: t5407: use <<- to align the expected output rebase -i: fix post-rewrite hook with failed exec command rebase -i: demonstrate incorrect behavior of post-rewrite
2015-05-22rebase -i: fix post-rewrite hook with failed exec commandLibravatar Matthieu Moy1-5/+5
Usually, when 'git rebase' stops before completing the rebase, it is to give the user an opportunity to edit a commit (e.g. with the 'edit' command). In such cases, 'git rebase' leaves the sha1 of the commit being rewritten in "$state_dir"/stopped-sha, and subsequent 'git rebase --continue' will call the post-rewrite hook with this sha1 as <old-sha1> argument to the post-rewrite hook. The case of 'git rebase' stopping because of a failed 'exec' command is different: it gives the opportunity to the user to examine or fix the failure, but does not stop saying "here's a commit to edit, use --continue when you're done". So, there's no reason to call the post-rewrite hook for 'exec' commands. If the user did rewrite the commit, it would be with 'git commit --amend' which already called the post-rewrite hook. Fix the behavior to leave no stopped-sha file in case of failed exec command, and teach 'git rebase --continue' to skip record_in_rewritten if no stopped-sha file is found. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-19Merge branch 'ph/rebase-i-redo'Libravatar Junio C Hamano1-0/+16
"git rebase -i" moved the "current" command from "todo" to "done" a bit too prematurely, losing a step when a "pick" did not even start. * ph/rebase-i-redo: rebase -i: redo tasks that die during cherry-pick
2015-05-11Merge branch 'nd/multiple-work-trees'Libravatar Junio C Hamano1-3/+3
A replacement for contrib/workdir/git-new-workdir that does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other. * nd/multiple-work-trees: (41 commits) prune --worktrees: fix expire vs worktree existence condition t1501: fix test with split index t2026: fix broken &&-chain t2026 needs procondition SANITY git-checkout.txt: a note about multiple checkout support for submodules checkout: add --ignore-other-wortrees checkout: pass whole struct to parse_branchname_arg instead of individual flags git-common-dir: make "modules/" per-working-directory directory checkout: do not fail if target is an empty directory t2025: add a test to make sure grafts is working from a linked checkout checkout: don't require a work tree when checking out into a new one git_path(): keep "info/sparse-checkout" per work-tree count-objects: report unused files in $GIT_DIR/worktrees/... gc: support prune --worktrees gc: factor out gc.pruneexpire parsing code gc: style change -- no SP before closing parenthesis checkout: clean up half-prepared directories in --to mode checkout: reject if the branch is already checked out elsewhere prune: strategies for linked checkouts checkout: support checking out into a new working directory ...
2015-04-29rebase -i: redo tasks that die during cherry-pickLibravatar Phil Hord1-0/+16
When rebase--interactive processes a task, it removes the item from the todo list and appends it to another list of executed tasks. If a pick (this includes squash and fixup) fails before the index has recorded the changes, take the corresponding item and put it on the todo list again. Otherwise, the changes introduced by the scheduled commit would be lost. That kind of decision is possible since the cherry-pick command signals why it failed to apply the changes of the given commit. Either the changes are recorded in the index using a conflict (return value 1) and rebase does not continue until they are resolved or the changes are not recorded in the index (return value neither 0 nor 1) and rebase has to try again with the same task. Add a test cases for regression testing to the "rebase-interactive" test suite. Signed-off-by: Fabian Ruch <bafain@gmail.com> Signed-off-by: Phil Hord <hordp@cisco.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-23Merge branch 'es/rebase-i-count-todo' into maintLibravatar Junio C Hamano1-1/+2
"git rebase -i" recently started to include the number of commits in the insn sheet to be processed, but on a platform that prepends leading whitespaces to "wc -l" output, the numbers are shown with extra whitespaces that aren't necessary. * es/rebase-i-count-todo: rebase-interactive: re-word "item count" comment rebase-interactive: suppress whitespace preceding item count
2015-03-17Merge branch 'es/rebase-i-count-todo'Libravatar Junio C Hamano1-1/+2
"git rebase -i" recently started to include the number of commits in the insn sheet to be processed, but on a platform that prepends leading whitespaces to "wc -l" output, the numbers are shown with extra whitespaces that aren't necessary. * es/rebase-i-count-todo: rebase-interactive: re-word "item count" comment rebase-interactive: suppress whitespace preceding item count
2015-03-06rebase-interactive: re-word "item count" commentLibravatar Eric Sunshine1-1/+1
97f05f43 (Show number of TODO items for interactive rebase, 2014-12-10) taught rebase-interactive to display an item count in the instruction list comments: # Rebase 46640c6..5568fd5 onto 46640c6 (4 TODO item(s)) # # Commands: # p, pick = use commit # ... However, with the exception of the --edit-todo option, "TODO" is a one-off term, never presented to the user by rebase-interactive in any other context. The item count is in fact the number of commands ("pick", "edit", etc.) remaining on the instruction sheet, and the comment immediately following it talks about "Commands". Consequently, replace "(# TODO item(s))" with the more accurate and meaningful "(# command(s))". Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-06rebase-interactive: suppress whitespace preceding item countLibravatar Eric Sunshine1-0/+1
97f05f43 (Show number of TODO items for interactive rebase, 2014-12-10) taught rebase-interactive to compute an item count with 'wc -l' and display it in the instruction list comments: # Rebase 46640c6..5568fd5 onto 46640c6 (4 TODO item(s)) On Mac OS X, however, it renders as: # Rebase 46640c6..5568fd5 onto 46640c6 ( 4 TODO item(s)) since 'wc -l' indents its output with leading spaces. Fix this. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-05Merge branch 'ks/rebase-i-abbrev' into maintLibravatar Junio C Hamano1-9/+8
The insn sheet "git rebase -i" creates did not fully honor core.abbrev settings. * ks/rebase-i-abbrev: rebase -i: use full object name internally throughout the script
2015-02-17Merge branch 'ks/rebase-i-abbrev'Libravatar Junio C Hamano1-9/+8
The insn sheet "git rebase -i" creates did not fully honor core.abbrev settings. * ks/rebase-i-abbrev: rebase -i: use full object name internally throughout the script
2015-01-22rebase -i: use full object name internally throughout the scriptLibravatar Kirill A. Shutemov1-9/+8
In earlier days, the abbreviated commit object name shown to the end users were generated with hardcoded --abbrev=7; 56895038 (rebase -i: respect core.abbrev, 2013-09-28) tried to make it honor the user specified core.abbrev, but it missed the very initial invocation of the editor. These days, we try to use the full 40-hex object names internally to avoid ambiguity that can arise after rebase starts running. Newly created objects during the rebase may share the same prefix with existing commits listed in the insn sheet. These object names are shortened just before invoking the sequence editor to present the insn sheet to the end user, and then expanded back to full object names when the editor returns. But the code still used the shortened names when preparing the insn sheet for the very first time, resulting "7 hexdigits or more" output to the user. Change the code to use full 40-hex commit object names from the very beginning to make things more uniform. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>