git/sequencer.c, branch v2.13.2

Merge branch 'ab/c-translators-comment-style' into maint

2017-06-05T00:03:10Z

Update the C style recommendation for notes for translators, as recent versions of gettext tools can work with our style of multi-line comments. * ab/c-translators-comment-style: C style: use standard style for "TRANSLATORS" comments

Merge branch 'jt/use-trailer-api-in-commands' into maint

2017-06-04T01:21:06Z

"git cherry-pick" and other uses of the sequencer machinery mishandled a trailer block whose last line is an incomplete line. This has been fixed so that an additional sign-off etc. are added after completing the existing incomplete line. * jt/use-trailer-api-in-commands: sequencer: add newline before adding footers

Merge branch 'pw/rebase-i-regression-fix' into maint

2017-06-04T01:20:55Z

Just the first one of three? new tests that follows up a regression fix. * pw/rebase-i-regression-fix: rebase -i: add missing newline to end of message rebase -i: silence stash apply rebase -i: fix reflog message

C style: use standard style for "TRANSLATORS" comments

2017-05-30T23:01:42Z

Change all the "TRANSLATORS: [...]" comments in the C code to use the regular Git coding style, and amend the style guide so that the example there uses that style. This custom style was necessary back in 2010 when the gettext support was initially added, and was subsequently documented in commit cbcfd4e3ea ("i18n: mention "TRANSLATORS:" marker in Documentation/CodingGuidelines", 2014-04-18). GNU xgettext hasn't had the parsing limitation that necessitated this exception for almost 3 years. Since its 0.19 release on 2014-06-02 it's been able to recognize TRANSLATOR comments in the standard Git comment syntax[1]. Usually we'd like to keep compatibility with software that's that young, but in this case literally the only person who needs to be using a gettext newer than 3 years old is Jiang Xin (the only person who runs & commits "make pot" results), so I think in this case we can make an exception. This xgettext parsing feature was added after a thread on the Git mailing list[2] which continued on the bug-gettext[3] list, but we never subsequently changed our style & styleguide, do so. There are already longstanding changes in git that use the standard comment style & have their TRANSLATORS comments extracted properly without getting the literal "*"'s mixed up in the text, as would happen before xgettext 0.19. Commit 7ff2683253 ("builtin-am: implement -i/--interactive", 2015-08-04) added one such comment, which in commit df0617bfa7 ("l10n: git.pot: v2.6.0 round 1 (123 new, 41 removed)", 2015-09-05) got picked up in the po/git.pot file with the right format, showing that Jiang already runs a modern xgettext. The xgettext parser does not handle the sort of non-standard comment style that I'm amending here in sequencer.c, but that isn't standard Git comment syntax anyway. With this change to sequencer.c & "make pot" the comment in the pot file is now correct: #. TRANSLATORS: %s will be "revert", "cherry-pick" or -#. * "rebase -i". +#. "rebase -i". 1. http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=10af7fe6bd 2. <2ce9ec406501d112e032c8208417f8100bed04c6.1397712142.git.worldhello.net@gmail.com> (https://public-inbox.org/git/2ce9ec406501d112e032c8208417f8100bed04c6.1397712142.git.worldhello.net@gmail.com/) 3. https://lists.gnu.org/archive/html/bug-gettext/2014-04/msg00016.html Signed-off-by: Ævar Arnfjörð Bjarmason Acked-by: Jiang Xin Signed-off-by: Junio C Hamano

rebase -i: add missing newline to end of message

2017-05-20T09:25:20Z

The message that's printed when auto-stashed changes are successfully restored was missing '\n' at the end. Signed-off-by: Phillip Wood Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

rebase -i: silence stash apply

2017-05-20T09:24:28Z

The shell version of rebase -i silences the status output from 'git stash apply' when restoring the autostashed changes. The C version does not. Having the output from git stash apply on the screen is distracting as it makes it difficult to find the message from git rebase saying that the rebase succeeded. Also the status information that git stash prints talks about looking in .git/rebase-merge/done to see which commits have been applied. As .git/rebase-merge is removed shortly after the message is printed before rebase -i exits this is confusing. Signed-off-by: Phillip Wood Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

rebase -i: fix reflog message

2017-05-20T09:24:25Z

When rebase -i was converted to C a bug was introduced into the code that creates the reflog message. Instead of saying rebase -i (finish): onto it says rebase -i (finish): onto as the strbuf is not reset between reading the value of and . Signed-off-by: Phillip Wood Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'sh/rebase-i-reread-todo-after-exec'

2017-05-01T05:14:44Z

"git rebase -i" failed to re-read the todo list file when the command specified with the `exec` instruction updated it. * sh/rebase-i-reread-todo-after-exec: rebase -i: reread the todo list if `exec` touched it

rebase -i: reread the todo list if `exec` touched it

2017-04-27T01:56:26Z

In the scripted version of the interactive rebase, there was no internal representation of the todo list; it was re-read before every command. That allowed the hack that an `exec` command could append (or even completely rewrite) the todo list. This hack was broken by the partial conversion of the interactive rebase to C, and this patch reinstates it. We also add a small test to verify that this fix does not regress in the future. Signed-off-by: Stephen Hicks Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

sequencer: add newline before adding footers

2017-04-27T00:48:50Z

When encountering a commit message that does not end in a newline, sequencer does not complete the line before determining if a blank line should be added. This causes the "(cherry picked..." and sign-off lines to sometimes appear on the same line as the last line of the commit message. This behavior was introduced by commit 967dfd4 ("sequencer: use trailer's trailer layout", 2016-11-29). However, a revert of that commit would not resolve this issue completely: prior to that commit, a conforming footer was deemed to be non-conforming by has_conforming_footer() if there was no terminating newline, resulting in both conforming and non-conforming footers being treated the same when they should not be. Resolve this issue, both for conforming and non-conforming footers, and in both do_pick_commit() and append_signoff(), by always adding a newline to the commit message if it does not end in one before checking the footer for conformity. Reported-by: Brian Norris Signed-off-by: Jonathan Tan Signed-off-by: Junio C Hamano