git/git-rebase--interactive.sh, branch v2.13.2

doc: replace more gmane links

2017-05-10T04:13:13Z

Signed-off-by: Junio C Hamano

rebase -i: use the rebase--helper builtin

2017-02-09T22:55:40Z

Now that the sequencer learned to process a "normal" interactive rebase, we use it. The original shell script is still used for "non-normal" interactive rebases, i.e. when --root or --preserve-merges was passed. Please note that the --root option (via the $squash_onto variable) needs special handling only for the very first command, hence it is still okay to use the helper upon continue/skip. Also please note that the --no-ff setting is volatile, i.e. when the interactive rebase is interrupted at any stage, there is no record of it. Therefore, we have to pass it from the shell script to the rebase--helper. Note: the test t3404 had to be adjusted because the the error messages produced by the sequencer comply with our current convention to start with a lower-case letter. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'jk/rebase-i-squash-count-fix'

2017-01-18T23:12:13Z

"git rebase -i" with a recent update started showing an incorrect count when squashing more than 10 commits. * jk/rebase-i-squash-count-fix: rebase--interactive: count squash commits above 10 correctly

rebase--interactive: count squash commits above 10 correctly

2017-01-08T03:26:53Z

We generate the squash commit message incrementally running a sed script once for each commit. It parses "This is a combination of commits" from the first line of the existing message, adds one to , and uses the result as the number of our current message. Since f2d17068fd (i18n: rebase-interactive: mark comments of squash for translation, 2016-06-17), the first line may be localized, and sed uses a pretty liberal regex, looking for: /^#.*([0-9][0-9]*)/ The "[0-9][0-9]*" tries to match double digits, but it doesn't quite work. The first ".*" is greedy, so if you have: This is a combination of 10 commits. it will eat up "This is a combination of 1", leaving "0" to match the first "[0-9]" digit, and then skipping the optional match of "[0-9]*". As a result, the count resets every 10 commits, and a 15-commit squash would end up as: # This is a combination of 5 commits. # This is the 1st commit message: ... # This is the commit message #2: ... and so on .. # This is the commit message #10: ... # This is the commit message #1: ... # This is the commit message #2: ... etc, up to 5 ... We can fix this by making the ".*" less greedy. Instead of depending on ".*?" working portably, we can just limit the match to non-digit characters, which accomplishes the same thing. Reported-by: Brandon Tolsch Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'va/i18n-even-more'

2016-12-27T08:11:45Z

* va/i18n-even-more: i18n: fix misconversion in shell scripts

i18n: fix misconversion in shell scripts

2016-12-20T17:36:23Z

An earlier series that was merged at 2703572b3a ("Merge branch 'va/i18n-even-more'", 2016-07-13) failed to use $(eval_gettext "string with \$variable interpolation") and instead used gettext in a few places, and ended up showing the variable names in the message, e.g. $ git submodule fatal: $program_name cannot be used without a working tree. Catch these mistakes with $ git grep -n '[^_]gettext .*\\\$' and fix them all to use eval_gettext instead. Reported-by: Josh Bleecher Snyder Acked-by: Vasco Almeida Signed-off-by: Junio C Hamano

Merge branch 'js/rebase-i-commentchar-fix'

2016-11-23T19:23:17Z

"git rebase -i" did not work well with core.commentchar configuration variable for two reasons, both of which have been fixed. * js/rebase-i-commentchar-fix: rebase -i: handle core.commentChar=auto stripspace: respect repository config rebase -i: highlight problems with core.commentchar

rebase -i: handle core.commentChar=auto

2016-11-21T19:00:41Z

When 84c9dc2 (commit: allow core.commentChar=auto for character auto selection, 2014-05-17) extended the core.commentChar functionality to allow for the value 'auto', it forgot that rebase -i was already taught to handle core.commentChar, and in turn forgot to let rebase -i handle that new value gracefully. Reported by Taufiq Hoven. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'rt/rebase-i-broken-insn-advise' into maint

2016-09-29T23:49:46Z

When "git rebase -i" is given a broken instruction, it told the user to fix it with "--edit-todo", but didn't say what the step after that was (i.e. "--continue"). * rt/rebase-i-broken-insn-advise: rebase -i: improve advice on bad instruction lines

Merge branch 'jk/rebase-i-drop-ident-check' into maint

2016-09-29T23:49:41Z

Even when "git pull --rebase=preserve" (and the underlying "git rebase --preserve") can complete without creating any new commit (i.e. fast-forwards), it still insisted on having a usable ident information (read: user.email is set correctly), which was less than nice. As the underlying commands used inside "git rebase" would fail with a more meaningful error message and advice text when the bogus ident matters, this extra check was removed. * jk/rebase-i-drop-ident-check: rebase-interactive: drop early check for valid ident