Re: [PATCH 22/22] sequencer: refactor write_message()

Hi Kuba,

On Fri, 9 Sep 2016, Jakub Narębski wrote:

W dniu 09.09.2016 o 16:40, Johannes Schindelin napisał:

quoted

On Fri, 2 Sep 2016, Jakub Narębski wrote:

quoted

W dniu 01.09.2016 o 16:20, Johannes Schindelin pisze:

quoted

On Thu, 1 Sep 2016, Jakub Narębski wrote: 

quoted

W dniu 29.08.2016 o 10:06, Johannes Schindelin pisze:

quoted

quoted

quoted

 	if (commit_lock_file(&msg_file) < 0)
 		return error(_("Error wrapping up %s."), filename);

Another "while at it"... though the one that can be safely postponed
(well, the make message easier to understand part, not the quote
filename part):

  		return error(_("Error wrapping up writing to '%s'."), filename);

As I inherited this message, I'll keep it.

Well, please then add quotes while at it, at least, for consistency

  		return error(_("Error wrapping up '%s'."), filename);

I may do that as a final patch, once all the other concerns are addressed.
I really do not want to change the error message during the conversion.

Is not wanting to change error messages during conversion because of
your use of Scientist tool to catch errors in conversion process?

It is more out of an aversion to mix unrelated purposes in the same patch.
You will see that I inserted an extra patch with the purpose of fixing the
style, that touches all the relevant error messages in sequencer.c.

BTW. could you tell us what were those three regression caught by the
cross-validation?

Sure!

The first one was that my original version of the rebase-i-extra patches
did not reorder patches correctly when there was more than one space after
the fixup!. I fixed it, and added this test:

cbcd2cb (rebase -i: we allow extra spaces after fixup!/squash!, 2016-07-07)

The second one was that `git commit --fixup` unwraps the commit subject
into one long line and rebase -i *still* manages to find the correct
commit to fix up. The test is part of the rebase-i-extra patches (and
therefore you will find this commit only in my fork):

9fc25ce (t3415: test fixup with wrapped oneline, 2016-07-24)

The third one was an obscure one: when I marked a commit as 'edit' and
there was a merge conflict cherry-picking that particular commit, rebase
--continue would squash the resolved changes *into the previous* commit,
but with the cherry-picked commit's message. It was a simple, stupid
oversight to write the "amend" file in the "edit" code path even if the
cherry-pick failed.

All fixed, of course.

Ciao,
Dscho