Re: What's cooking in git.git (Aug 2018, #04; Fri, 17)

[Phillip Wood <phillip.wood@talktalk.net>]

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.

> 
> * pw/add-p-select (2018-07-26) 4 commits
>  - add -p: optimize line selection for short hunks
>  - add -p: allow line selection to be inverted
>  - add -p: select modified lines correctly
>  - add -p: select individual hunk lines
> 
>  "git add -p" interactive interface learned to let users choose
>  individual added/removed lines to be used in the operation, instead
>  of accepting or rejecting a whole hunk.
> 
>  Will hold.
>  cf. <d622a95b-7302-43d4-4ec9-b2cf3388c653@talktalk.net>
>  I found the feature to be hard to explain, and may result in more
>  end-user complaints, but let's see.

Thanks, I'll send some follow up patches to improve the help and
documentation next month.

Best Wishes

Phillip