pw/rebase-i-author-script-fix, was Re: What's cooking in git.git (Aug 2018, #04; Fri, 17)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Team,

On Mon, 20 Aug 2018, Phillip Wood wrote:

> On 17/08/2018 23:44, Junio C Hamano wrote:
> > Here are the topics that have been cooking.  Commits prefixed with
> > '-' are only in 'pu' (proposed updates) while commits prefixed with
> > '+' are in 'next'.  The ones marked with '.' do not appear in any of
> > the integration branches, but I am still holding onto them.
> 
> > * pw/rebase-i-author-script-fix (2018-08-07) 2 commits
> >  - sequencer: fix quoting in write_author_script
> >  - sequencer: handle errors from read_author_ident()
> > 
> >  Recent "git rebase -i" update started to write bogusly formatted
> >  author-script, with a matching broken reading code.  These are
> >  being fixed.
> > 
> >  Undecided.
> >  Is it the list consensus to favor this "with extra code, read the
> >  script written by bad writer" approach?
> 
> I think there was agreement between myself and Eric on the last version,
> I'm not sure anyone else has expressed an opinion. The problem with
> fixing the quoting without any backwards compatibility is that if git is
> upgraded while a rebase is stopped read_author_script() will happily use
> the broken quoting to create a corrupted author name in the new commit
> if the name contains "'".
> 
> The compatibility code in the latest version relies on the missing "'"
> at the end of the GIT_AUTHOR_DATE line which is fixed by
> es/rebase-i-author-script-fix which is now in master. If there is a
> release with es/rebase-i-author-script-fix but not
> pw/rebase-i-author-script-fix we'll have to rethink as the detection
> wont be reliable. I have a branch that fixes read_author_script() to use
> sq_dequote() at
> https://github.com/phillipwood/git/commits/wip/fix-author-script. At the
> moment it has compatibility with broken quoting, but I could strip that
> out and then sq_dequote() will return an error with the broken quoting
> and the user would have to restart the rebase. So one option is to drop
> this series and wait for me to finish the improved solution next month.

Having thought about it, I am now convinced that it wold be overkill to
cater to "upgrade in the middle of a rebase". I think we should drop that
part, as it uglifies the code rather a lot, and the impact is not worth
the effort IMHO.

Ciao,
Johannes