user/sven/git.git/git-rebase--interactive.sh, branch v1.5.6.4

rebase-i: keep old parents when preserving merges

2008-07-16T22:13:53Z

When "rebase -i -p" tries to preserve merges of unrelated branches, it lost some parents: - When you have more than two parents, the commit in the new history ends up with fewer than expected number of parents and this breakage goes unnoticed; - When you are rebasing a merge with two parents and one is lost, the command tries to cherry-pick the original merge commit, and the command fails. Signed-off-by: Stephan Beyer Signed-off-by: Junio C Hamano

git-rebase -i: mention the short command aliases in the todo list

2008-06-08T20:46:37Z

git rebase -i already supports 'p', 'e' and 's' as aliases for 'pick', 'edit' and 'squash', but one could know it only by reading the source code. If a user rebases a lot, it's quite handy, so mention these short forms as well. Signed-off-by: Miklos Vajna Signed-off-by: Junio C Hamano

rebase --interactive: Compute upstream SHA1 before switching branches

2008-06-03T03:36:14Z

If the upstream argument to rebase (the first argument) was relative to HEAD and the name of the branch to rebase (the second argument) was given, the upstream would have been interpreted relative to the second argument. In particular, this command git rebase -i HEAD topic would always finish with "Nothing to do". (a1bf91e fixed the same issue for non-interactive rebase.) Signed-off-by: Johannes Sixt Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Ignore dirty submodule states during rebase and stash

2008-05-15T23:12:43Z

When rebasing or stashing, chances are that you do not care about dirty submodules, since they are not updated by those actions anyway. So ignore the submodules' states. Note: the submodule states -- as committed in the superproject -- will still be stashed and rebased, it is _just_ the state of the submodule in the working tree which is ignored. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

remove use of "tail -n 1" and "tail -1"

2008-03-13T07:57:52Z

The "-n" syntax is not supported by System V versions of tail (which prefer "tail -1"). Unfortunately "tail -1" is not actually POSIX. We had some of both forms in our scripts. Since neither form works everywhere, this patch replaces both with the equivalent sed invocation: sed -ne '$p' Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

grep portability fix: don't use "-e" or "-q"

2008-03-13T07:57:52Z

System V versions of grep (such as Solaris /usr/bin/grep) don't understand either of these options. git's usage of "grep -e pattern" fell into one of two categories: 1. equivalent to "grep pattern". -e is only useful here if the pattern begins with a "-", but all of the patterns are hardcoded and do not begin with a dash. 2. stripping comments and blank lines with grep -v -e "^$" -e "^#" We can fortunately do this in the affirmative as grep '^[^#]' Uses of "-q" can be replaced with redirection to /dev/null. In many tests, however, "grep -q" is used as "if this string is in the expected output, we are OK". In this case, it is fine to just remove the "-q" entirely; it simply makes the "verbose" mode of the test slightly more verbose. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Prompt to continue when editing during rebase --interactive

2008-02-27T19:23:22Z

On hitting an edit point in an interactive rebase, git should prompt the user to run "git rebase --continue" Signed-off-by: Jonathan del Strother Signed-off-by: Junio C Hamano

rebase -i: accept -m as advertised in the man page

2008-02-11T20:18:53Z

Signed-off-by: Uwe Kleine-K,Av(Bnig Signed-off-by: Junio C Hamano

Squelch bogus progress output from git-rebase--interactive

2008-01-15T04:04:02Z

The command repeats "Rebasing (1/1)" many times even when there is only one task remaining, because mark_action_done() is called to skip comment and empty lines in the TODO file. This should fix it. Signed-off-by: Junio C Hamano

git-rebase -i: clean-up error check codepath.

2007-12-30T20:51:42Z

After replaying a single change, the code performed a number of checks, but some of them were for sanity checking, failures from which should make the command abort, and others were checks to see if it should make a new commit object. Stringing them together with "&&" was wrong. Signed-off-by: Junio C Hamano