git/git-rebase.sh, branch v2.16.2

rebase: rebasing can also be done when HEAD is detached

2017-12-19T18:02:47Z

Attempting to rebase when the HEAD is detached and is already up to date with upstream (so there's nothing to do), the following message is shown Current branch HEAD is up to date. which is clearly wrong as HEAD is not a branch. Handle the special case of HEAD correctly to give a more precise error message. Signed-off-by: Kaartic Sivaraam Signed-off-by: Junio C Hamano Signed-off-by: Kaartic Sivaraam Signed-off-by: Junio C Hamano

rebase: distinguish user input by quoting it

2017-12-19T18:02:44Z

Signed-off-by: Kaartic Sivaraam Signed-off-by: Junio C Hamano Signed-off-by: Kaartic Sivaraam Signed-off-by: Junio C Hamano

rebase: consistently use branch_name variable

2017-12-19T18:02:14Z

The variable "branch_name" holds the parameter in "git rebase ", but one codepath did not use it after assigning $1 to it (instead it kept using $1). Make it use the variable consistently. Also, update an error message to say there is no such branch or commit, as we are expecting either of them, and not limiting ourselves to a branch name. Signed-off-by: Kaartic Sivaraam Signed-off-by: Junio C Hamano Signed-off-by: Kaartic Sivaraam Signed-off-by: Junio C Hamano

Merge branch 'ks/rebase-no-git-foo'

2017-11-27T02:06:39Z

Mentions of "git-rebase" and "git-am" (dashed form) still remained in end-user visible strings emitted by the "git rebase" command; they have been corrected. * ks/rebase-no-git-foo: git-rebase: clean up dashed-usages in messages

Merge branch 'tz/redirect-fix'

2017-11-27T02:06:33Z

A few scripts (both in production and tests) incorrectly redirected their error output. These have been corrected. * tz/redirect-fix: rebase: fix stderr redirect in apply_autostash() t/lib-gpg: fix gpgconf stderr redirect to /dev/null

git-rebase: clean up dashed-usages in messages

2017-11-21T00:34:13Z

Signed-off-by: Kaartic Sivaraam Signed-off-by: Junio C Hamano

rebase: fix stderr redirect in apply_autostash()

2017-11-14T02:51:42Z

The intention is to ignore all output from the 'git stash apply' call. Adjust the order of the redirection to ensure that both stdout and stderr are redirected to /dev/null. Signed-off-by: Todd Zullinger Signed-off-by: Junio C Hamano

Merge branch 'bc/rev-parse-parseopt-fix'

2017-10-03T06:42:47Z

Recent versions of "git rev-parse --parseopt" did not parse the option specification that does not have the optional flags (*=?!) correctly, which has been corrected. * bc/rev-parse-parseopt-fix: parse-options: only insert newline in help text if needed parse-options: write blank line to correct output stream t0040,t1502: Demonstrate parse_options bugs git-rebase: don't ignore unexpected command line arguments rev-parse parseopt: interpret any whitespace as start of help text rev-parse parseopt: do not search help text for flag chars t1502: demonstrate rev-parse --parseopt option mis-parsing

git-rebase: don't ignore unexpected command line arguments

2017-09-19T03:13:09Z

Currently, git-rebase will silently ignore any unexpected command-line switches and arguments (the command-line produced by git rev-parse). This allowed the rev-parse bug, fixed in the preceding commits, to go unnoticed. Let's make sure that doesn't happen again. We shouldn't be ignoring unexpected arguments. Let's not. Signed-off-by: Brandon Casey Signed-off-by: Junio C Hamano

Merge branch 'kw/rebase-progress'

2017-08-23T21:13:07Z

"git rebase", especially when it is run by mistake and ends up trying to replay many changes, spent long time in silence. The command has been taught to show progress report when it spends long time preparing these many changes to replay (which would give the user a chance to abort with ^C). * kw/rebase-progress: rebase: turn on progress option by default for format-patch format-patch: have progress option while generating patches