On Fri, 9 Sep 2016, Jakub Narębski wrote:
> W dniu 09.09.2016 o 16:40, Johannes Schindelin napisał:
> > On Fri, 2 Sep 2016, Jakub Narębski wrote:
> >> W dniu 01.09.2016 o 16:20, Johannes Schindelin pisze:
> >>> On Thu, 1 Sep 2016, Jakub Narębski wrote:
> >>>> W dniu 29.08.2016 o 10:06, Johannes Schindelin pisze:
> >>>>> 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
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
All fixed, of course.