summaryrefslogtreecommitdiff
path: root/git-rebase--interactive.sh
AgeCommit message (Collapse)AuthorFilesLines
2013-09-30rebase -i: respect core.abbrevLibravatar Kirill A. Shutemov1-1/+1
collapse_todo_ids() uses `git rev-parse --short=7' to abbreviate commit ids before showing them to the user in a text editor. Let's drop argument from --short to the configured value instead (still defaulting to 7). Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-11Merge branch 'es/rebase-i-no-abbrev'Libravatar Junio C Hamano1-0/+30
The commit object names in the insn sheet that was prepared at the beginning of "rebase -i" session can become ambiguous as the rebasing progresses and the repository gains more commits. Make sure the internal record is kept with full 40-hex object names. * es/rebase-i-no-abbrev: rebase -i: fix short SHA-1 collision t3404: rebase -i: demonstrate short SHA-1 collision t3404: make tests more self-contained
2013-09-11Merge branch 'rt/rebase-p-no-merge-summary'Libravatar Junio C Hamano1-1/+2
"git rebase -p" internally used the merge machinery, but when rebasing, there should not be a need for merge summary. * rt/rebase-p-no-merge-summary: rebase --preserve-merges: ignore "merge.log" config
2013-09-11Merge branch 'es/rebase-i-respect-core-commentchar'Libravatar Junio C Hamano1-1/+1
"rebase -i" forgot that the comment character can be configurable while reading its insn sheet. * es/rebase-i-respect-core-commentchar: rebase -i: fix cases ignoring core.commentchar
2013-08-25rebase -i: fix short SHA-1 collisionLibravatar Junio C Hamano1-0/+30
The 'todo' sheet for interactive rebase shows abbreviated SHA-1's and then performs its operations upon those shortened values. This can lead to an abort if the SHA-1 of a reworded or edited commit is no longer unique within the abbreviated SHA-1 space and a subsequent SHA-1 in the todo list has the same abbreviated value. For example: edit f00dfad first pick badbeef second If, after editing, the new SHA-1 of "first" also has prefix badbeef, then the subsequent 'pick badbeef second' will fail since badbeef is no longer a unique SHA-1 abbreviation: error: short SHA1 badbeef is ambiguous. fatal: Needed a single revision Invalid commit name: badbeef Fix this problem by expanding the SHA-1's in the todo list before performing the operations. [es: also collapse & expand SHA-1's for --edit-todo; respect core.commentchar in transform_todo_ids(); compose commit message] Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-21rebase --preserve-merges: ignore "merge.log" configLibravatar Ralf Thielow1-1/+2
When "merge.log" config is set, "rebase --preserve-merges" will add the log lines to the message of the rebased merge commit. A rebase should not modify a commit message automatically. Teach "git-rebase" to ignore that configuration by passing "--no-log" to the git-merge call. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-18rebase -i: fix cases ignoring core.commentcharLibravatar Eric Sunshine1-1/+1
180bad3d (rebase -i: respect core.commentchar, 2013-02-11) updated "rebase -i" to honor core.commentchar but missed one instance of hard-coded '#' comment character in skip_unnecessary_picks(). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-18Merge branch 'rr/rebase-reflog-message-reword'Libravatar Junio C Hamano1-1/+5
"git rebase [-i]" used to leave just "rebase" as its reflog message for some operations. This rewords them to be more informative. * rr/rebase-reflog-message-reword: rebase -i: use a better reflog message rebase: use a better reflog message
2013-07-11Merge branch 'af/rebase-i-merge-options'Libravatar Junio C Hamano1-5/+16
"git rebase -i" now honors --strategy and -X options. * af/rebase-i-merge-options: Do not ignore merge options in interactive rebase
2013-07-02Do not ignore merge options in interactive rebaseLibravatar Arnaud Fontaine1-5/+16
Merge strategy and its options can be specified in `git rebase`, but with `--interactive`, they were completely ignored. Signed-off-by: Arnaud Fontaine <arnau@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-27rebase -i: handle fixup! fixup! in --autosquashLibravatar Andrew Pimlott1-5/+20
In rebase -i --autosquash, ignore all "fixup! " or "squash! " after the first. This supports the case when a git commit --fixup/--squash referred to an earlier fixup/squash instead of the original commit (whether intentionally, as when the user expressly meant to note that the commit fixes an earlier fixup; or inadvertently, as when the user meant to refer to the original commit with :/msg; or out of laziness, as when the user could remember how to refer to the fixup but not the original). In the todo list, the full commit message is preserved, in case it provides useful cues to the user. A test helper set_cat_todo_editor is introduced to check this. Helped-by: Thomas Rast <trast@inf.ethz.ch> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Andrew Pimlott <andrew@pimlott.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-23rebase -i: use a better reflog messageLibravatar Ramkumar Ramachandra1-1/+5
Now that the "checkout" invoked internally from "rebase -i" knows to honor GIT_REFLOG_ACTION, we can start to use it to write a better reflog message when "rebase anotherbranch", "rebase --onto branch", etc. internally checks out the new fork point. We will write: rebase -i: checkout master instead of the old rebase -i As all the calls git-rebase--interactive make to underlying git commands that leave reflog messages are preceded by the internal comment_for_reflog helper function, which uses the original value of the GIT_REFLOG_ACTION variable it saw when it first started, the new assignments to GIT_REFLOG_ACTION actively contaminate the value of the variable, knowing that it will be reset to a sane value before it is used again. This does not generally hold true but it should suffice for now. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-12rebase -i: return control to caller, for housekeepingLibravatar Ramkumar Ramachandra1-4/+5
Return control to the caller git-rebase.sh to get these two tasks rm -fr "$dotest" git gc --auto done by it. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-12rebase -i: don't error out if $state_dir already existsLibravatar Ramkumar Ramachandra1-1/+1
In preparation for a later patch that will create $state_dir/autostash in git-rebase.sh before anything else can happen, change a `mkdir $state_dir` call to `mkdir -p $state_dir`. The change is safe, because this is not a test to detect an in-progress rebase (that is already done much earlier in git-rebase.sh). Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-25bash-prompt.sh: show where rebase is at when stoppedLibravatar Zoltan Klinger1-0/+5
When a rebase stops (e.g. interrupted by a merge conflict), it could be useful to know how far a rebase has progressed and how many commits in total this rebase will apply. Teach the __git_ps1() command to display the number of commits so far applied and the total number of commits to be applied, like this: ((3ec0a6a...)|REBASE 2/5) In the example above the rebase has stopped at the second commit due to a merge conflict and there are a total number of five commits to be applied by this rebase. This information can be already obtained from the following files which are being generated during the rebase: GIT_DIR/.git/rebase-merge/msgnum (git-rebase--merge.sh) GIT_DIR/.git/rebase-merge/end (git-rebase--merge.sh) GIT_DIR/.git/rebase-apply/next (git-am.sh) GIT_DIR/.git/rebase-apply/last (git-am.sh) but "rebase -i" does not leave necessary clues. Implement this feature by doing these three things: 1) Modify git-rebase--interactive.sh to also create GIT_DIR/.git/rebase-merge/msgnum GIT_DIR/.git/rebase-merge/end files for the number of commits so far applied and the total number of commits to be applied. 2) Modify git-prompt.sh to read and display info from the above files. 3) Update test t9903-bash-prompt.sh to reflect changes introduced by this patch. Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-17Merge branch 'jk/rebase-i-comment-char'Libravatar Junio C Hamano1-40/+44
Finishing touches to the earlier core.commentchar topic to cover "rebase -i" as well. * jk/rebase-i-comment-char: rebase -i: respect core.commentchar
2013-02-12rebase -i: respect core.commentcharLibravatar John Keeping1-40/+44
Commit eff80a9 (Allow custom "comment char") introduced a custom comment character for commit messages but did not teach git-rebase--interactive to use it. Change git-rebase--interactive to read core.commentchar and use its value when generating commit messages and for the command list. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-21Merge branch 'ph/rebase-preserve-all-merges'Libravatar Junio C Hamano1-1/+6
An earlier change to add --keep-empty option broke "git rebase --preserve-merges" and lost merge commits that end up being the same as its parent. * ph/rebase-preserve-all-merges: rebase --preserve-merges: keep all merge commits including empty ones
2013-01-14rebase --preserve-merges: keep all merge commits including empty onesLibravatar Phil Hord1-1/+6
Since 90e1818f9a (git-rebase: add keep_empty flag, 2012-04-20) 'git rebase --preserve-merges' fails to preserve empty merge commits unless --keep-empty is also specified. Merge commits should be preserved in order to preserve the structure of the rebased graph, even if the merge commit does not introduce changes to the parent. Teach rebase not to drop merge commits only because they are empty. A special case which is not handled by this change is for a merge commit whose parents are now the same commit because all the previous different parents have been dropped as a result of this rebase or some previous operation. Signed-off-by: Phil Hord <hordp@cisco.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29Merge branch 'aw/rebase-i-edit-todo'Libravatar Junio C Hamano1-13/+40
Teach an option to edit the insn sheet to "git rebase -i". * aw/rebase-i-edit-todo: rebase -i: suggest using --edit-todo to fix an unknown instruction rebase -i: Add tests for "--edit-todo" rebase -i: Teach "--edit-todo" action rebase -i: Refactor help messages for todo file rebase usage: subcommands can not be combined with -i
2012-09-19rebase -i: suggest using --edit-todo to fix an unknown instructionLibravatar Johannes Sixt1-2/+3
We have now an explicit UI to edit the todo sheet and need not disclose the name of the file. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-18rebase -i: fix misleading error message after 'exec no-such' instructionLibravatar Johannes Sixt1-0/+4
When the todo sheet of interactive rebase instructs to run a non-existing command, the operation stops with the following error: Execution failed: no-such You can fix the problem, and then run git rebase --continue fatal: 'rebase' appears to be a git command, but we were not able to execute it. Maybe git-rebase is broken? The reason is that the shell that attempted to run the command exits with code 127. rebase--interactive just forwards this code to the caller (the git wrapper). But our smart run-command infrastructure detects this special exit code and turns it into ENOENT, which in turn is interpreted by the git wrapper as if the external command that it just executed did not exist. This is finally translated to the misleading last two lines in error message cited above. Fix it by translating the error code before it is forwarded. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17rebase -i: Teach "--edit-todo" actionLibravatar Andrew Wong1-0/+17
This allows users to edit the todo file while they're stopped in the middle of an interactive rebase. When this action is executed, all comments from the original todo file are stripped, and new help messages are appended to the end. Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17rebase -i: Refactor help messages for todo fileLibravatar Andrew Wong1-11/+20
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-10Merge branch 'maint-1.7.11' into maintLibravatar Junio C Hamano1-2/+1
* maint-1.7.11: Almost 1.7.11.6 gitweb: URL-decode $my_url/$my_uri when stripping PATH_INFO rebase -i: use full onto sha1 in reflog sh-setup: protect from exported IFS receive-pack: do not leak output from auto-gc to standard output t/t5400: demonstrate breakage caused by informational message from prune setup: clarify error messages for file/revisions ambiguity send-email: improve RFC2047 quote parsing fsck: detect null sha1 in tree entries do not write null sha1s to on-disk index diff: do not use null sha1 as a sentinel value
2012-09-10Merge branch 'mg/rebase-i-onto-reflog-in-full' into maint-1.7.11Libravatar Junio C Hamano1-2/+1
The reflog entries left by "git rebase" and "git rebase -i" were inconsistent (the interactive one gave an abbreviated object name). * mg/rebase-i-onto-reflog-in-full: rebase -i: use full onto sha1 in reflog
2012-08-29Merge branch 'mg/rebase-i-onto-reflog-in-full'Libravatar Junio C Hamano1-2/+1
The reflog entries left by "git rebase" and "git rebase -i" were inconsistent. * mg/rebase-i-onto-reflog-in-full: rebase -i: use full onto sha1 in reflog
2012-08-10rebase -i: use full onto sha1 in reflogLibravatar Michael J Gruber1-2/+1
'git rebase' uses the full onto sha1 for the reflog message whereas 'git rebase -i' uses the short sha1. This is not only inconsistent, but can lead to problems when the reflog is inspected at a later time at which that abbreviation may have become ambiguous. Make 'rebase -i' use the full onto sha1, as well. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-25Merge branch 'cw/rebase-i-root'Libravatar Junio C Hamano1-12/+13
Finishing touches to the "rebase -i --root" (new feature for 1.7.12). * cw/rebase-i-root: rebase -i: handle fixup of root commit correctly
2012-07-24rebase -i: handle fixup of root commit correctlyLibravatar Chris Webb1-12/+13
There is a bug with git rebase -i --root when a fixup or squash line is applied to the new root. We attempt to amend the commit onto which they apply with git reset --soft HEAD^ followed by a normal commit. Unlike a real commit --amend, this sequence will fail against a root commit as it has no parent. Fix rebase -i to use commit --amend for fixup and squash instead, and add a test for the case of a fixup of the root commit. Signed-off-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-15Merge branch 'cw/rebase-i-root'Libravatar Junio C Hamano1-6/+26
"git rebase [-i] --root $tip" can now be used to rewrite all the history down to the root. * cw/rebase-i-root: t3404: make test 57 work with dash and others Add tests for rebase -i --root without --onto rebase -i: support --root without --onto
2012-07-13Merge branch 'mz/rebase-no-mbox'Libravatar Junio C Hamano1-3/+1
Teach "am --rebasing" codepath to grab authorship, log message and the patch text directly out of existing commits. This will help rebasing commits that have confusing "diff" output in their log messages. * mz/rebase-no-mbox: am: don't call mailinfo if $rebasing am --rebasing: get patch body from commit, not from mailbox rebase --root: print usage on too many args rebase: don't source git-sh-setup twice
2012-06-26rebase -i: support --root without --ontoLibravatar Chris Webb1-6/+26
Allow --root to be specified to rebase -i without --onto, making it possible to edit and re-order all commits right back to the root(s). If there is a conflict to be resolved when applying the first change, the user will expect a sane index and working tree to get sensible behaviour from git-diff and friends, so create a sentinel commit with an empty tree to rebase onto. Automatically squash the sentinel with any commits rebased directly onto it, so they end up as root commits in their own right and retain their authorship and commit message. Implicitly use rebase -i for non-interactive rebase of --root without an --onto argument now that rebase -i can correctly do this. Signed-off-by: Chris Webb <chris@arachsys.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-26rebase: don't source git-sh-setup twiceLibravatar Martin von Zweigbergk1-3/+1
The git-sh-setup script is already sourced in git-rebase.sh before calling into git-rebase--(am|interactive|merge).sh. There are no other callers of these scripts. It is therefore unnecessary to source git-sh-setup again in them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-13rebase -i: teach "--exec <cmd>"Libravatar Lucien Kong1-0/+23
During an interactive rebase session, it is sometimes desirable to run tests on each commit in the resulting history. This can be done by adding "exec <test command>" when editing the insn sheet, but the command used for testing is often the same for all resulting commits. By passing "--exec <cmd>" from the command line, automatically add these "exec" lines after each commit in the final history. To work well with the --autosquash option, these are added at the end of each run of "fixup" and "squash". Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-10Merge branch 'nl/rebase-i-cheat-sheet' into maintLibravatar Junio C Hamano1-0/+2
* nl/rebase-i-cheat-sheet: rebase -i: remind that the lines are top-to-bottom
2012-04-30Merge branch 'nh/empty-rebase'Libravatar Junio C Hamano1-3/+32
"git rebase" learned to optionally keep commits that do not introduce any change in the original history. By Neil Horman * nh/empty-rebase: git-rebase: add keep_empty flag git-cherry-pick: Add test to validate new options git-cherry-pick: Add keep-redundant-commits option git-cherry-pick: add allow-empty option
2012-04-24git-rebase: add keep_empty flagLibravatar Neil Horman1-3/+32
Add a command line switch to git-rebase to allow a user the ability to specify that they want to keep any commits in a series that are empty. When git-rebase's type is am, then this option will automatically keep any commit that has a tree object identical to its parent. This patch changes the default behavior of interactive rebases as well. With this patch, git-rebase -i will produce a revision set passed to git-revision-editor, in which empty commits are commented out. Empty commits may be kept manually by uncommenting them. If the new --keep-empty option is used in an interactive rebase the empty commits will automatically all be uncommented in the editor. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-23Merge branch 'jk/rebase-i-submodule-conflict-only'Libravatar Junio C Hamano1-1/+1
Giving "--continue" to a conflicted "rebase -i" session skipped a commit that only results in changes to submodules. By John Keeping * jk/rebase-i-submodule-conflict-only: rebase -i continue: don't skip commits that only change submodules
2012-04-09rebase -i continue: don't skip commits that only change submodulesLibravatar John Keeping1-1/+1
When git-rebase--interactive stops due to a conflict and the only change to be committed is in a submodule, the test for whether there is anything to be committed ignores the staged submodule change. This leads rebase to skip creating the commit for the change. While unstaged submodule changes should be ignored to avoid needing to update submodules during a rebase, it is safe to remove the --ignore-submodules option to diff-index because --cached ensures that it is only checking the index. This was discussed in [1] and a test is included to ensure that unstaged changes are still ignored correctly. [1] http://thread.gmane.org/gmane.comp.version-control.git/188713 Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-20rebase -i: remind that the lines are top-to-bottomLibravatar Junio C Hamano1-0/+2
Nelson Benitez Leon opened a discussion with a patch with this in the note: Hi, I was using git rebase -i for some time now and never occured to me I could reorder the commit lines to affect the order the commits are applied, learnt that recently from a git tutorial. Nelson's patch was to stress the fact that the lines in the insn sheet can be re-ordered in a much more verbose way. Let's add a one-liner reminder and also remind that the lines in the insn sheet is read from top to bottom, unlike the "git log" output. Discussion-triggered-by: Nelson Benitez Leon Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-28Merge branch 'aw/rebase-i-stop-on-failure-to-amend' into maintLibravatar Junio C Hamano1-13/+23
* aw/rebase-i-stop-on-failure-to-amend: rebase -i: interrupt rebase when "commit --amend" failed during "reword"
2011-12-16Merge branch 'aw/rebase-i-stop-on-failure-to-amend'Libravatar Junio C Hamano1-13/+23
* aw/rebase-i-stop-on-failure-to-amend: rebase -i: interrupt rebase when "commit --amend" failed during "reword"
2011-11-30rebase -i: interrupt rebase when "commit --amend" failed during "reword"Libravatar Andrew Wong1-13/+23
"commit --amend" could fail in cases like the user empties the commit message, or pre-commit failed. When it fails, rebase should be interrupted and alert the user, rather than ignoring the error and continue on rebasing. This also gives users a way to gracefully interrupt a "reword" if they decided they actually want to do an "edit", or even "rebase --abort". Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-17"rebase -i": support special-purpose editor to edit insn sheetLibravatar Peter Oberndorfer1-1/+14
The insn sheet used by "rebase -i" is designed to be easily editable by any text editor, but an editor that is specifically meant for it (but is otherwise unsuitable for editing regular text files) could be useful by allowing drag & drop reordering in a GUI environment, for example. The GIT_SEQUENCE_EDITOR environment variable and/or the sequence.editor configuration variable can be used to specify such an editor, while allowing the usual editor to be used to edit commit log messages. As usual, the environment variable takes precedence over the configuration variable. It is envisioned that other "sequencer" based tools will use the same mechanism. Signed-off-by: Peter Oberndorfer <kumbayo84@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-26rebase -i: notice and warn if "exec $cmd" modifies the index or the working treeLibravatar Junio C Hamano1-3/+9
If "exec $cmd" touched the index or the working tree, and exited with non-zero status, the code did not check and warn that there now are uncommitted changes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-26rebase -i: clean error message for --continue after failed execLibravatar Matthieu Moy1-1/+17
After an "exec false" stops the rebase and gives the control back to the user, if changes are added to the index, "rebase --continue" fails with this message, which may technically be correct, but does not point at the real problem: .../git-rebase--interactive: line 774: .../.git/rebase-merge/author-script: No such file or directory We could try auto-amending HEAD, but this goes against the logic of .git/rebase-merge/author-script (see also the testcase 'auto-amend only edited commits after "edit"' in t3404-rebase-interactive.sh) to auto-amend something the user hasn't explicitely asked to edit. Instead of doing anything automatically, detect the situation and give a clean error message. While we're there, also clarify the error message in case '. "$author_script"' fails, which now corresponds to really weird senario where the author script exists but can't be read. Test-case-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-19rebase -i -p: include non-first-parent commits in todo listLibravatar Andrew Wong1-2/+1
Consider this graph: D---E (topic, HEAD) / / A---B---C (master) \ F (topic2) and the following three commands: 1. git rebase -i -p A 2. git rebase -i -p --onto F A 3. git rebase -i -p B Currently, (1) and (2) will pick B, D, C, and E onto A and F, respectively. However, (3) will only pick D and E onto B, but not C, which is inconsistent with (1) and (2). As a result, we cannot modify C during the interactive-rebase. The current behavior also creates a bug if we do: 4. git rebase -i -p C In (4), E is never picked. And since interactive-rebase resets "HEAD" to "onto" before picking any commits, D and E are lost after the interactive-rebase. This patch fixes the inconsistency and bug by ensuring that all children of upstream are always picked. This essentially reverts the commit: d80d6bc146232d81f1bb4bc58e5d89263fd228d4 When compiling the todo list, commits reachable from "upstream" should never be skipped under any conditions. Otherwise, we lose the ability to modify them like (3), and create a bug like (4). Two of the tests contain a scenario like (3). Since the new behavior added more commits for picking, these tests need to be updated to account for the additional pick lines. A new test has also been added for (4). Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-27rebase: write a reflog entry when finishingLibravatar Jeff King1-1/+3
When we finish a rebase, our detached HEAD is at the final result. We update the original branch ref with this result, and then point the HEAD symbolic ref at the updated branch. We write a reflog for the branch update, but not for the update of HEAD. Because we're already at the final result on the detached HEAD, moving to the branch actually doesn't change our commit sha1 at all. So in that sense, a reflog entry would be pointless. However, humans do read reflogs, and an entry saying "rebase finished: returning to refs/heads/master" can be helpful in understanding what is going on. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-06Merge branch 'aw/maint-rebase-i-p-no-ff'Libravatar Junio C Hamano1-1/+1
* aw/maint-rebase-i-p-no-ff: git-rebase--interactive.sh: preserve-merges fails on merges created with no-ff Conflicts: git-rebase--interactive.sh