git/add-patch.c, branch v2.29.2

Merge branch 'pw/add-p-edit-ita-path'

2020-09-22T19:36:28Z

"add -p" now allows editing paths that were only added in intent. * pw/add-p-edit-ita-path: add -p: fix editing of intent-to-add paths

Merge branch 'jk/add-i-fixes'

2020-09-19T00:58:04Z

"add -i/-p" fixes. * jk/add-i-fixes: add--interactive.perl: specify --no-color explicitly add-patch: fix inverted return code of repo_read_index()

Merge branch 'pw/add-p-leakfix'

2020-09-19T00:58:03Z

Leakfix. * pw/add-p-leakfix: add -p: fix memory leak

add -p: fix editing of intent-to-add paths

2020-09-09T19:49:01Z

A popular way of partially staging a new file is to run `git add -N ` and then use the hunk editing of `git add -p` to select the part of the file that the user wishes to stage. Since 85953a3187 ("diff-files --raw: show correct post-image of intent-to-add files", 2020-07-01) this has stopped working as intent-to-add paths are now show as new files rather than changes to an empty blob and `git apply` refused to apply a creation patch for a path that was marked as intent-to-add. 7cfde3fa0f ("apply: allow "new file" patches on i-t-a entries", 2020-08-06) fixed the problem with apply but it still wasn't possible to edit the added hunk properly. 2c8bd8471a ("checkout -p: handle new files correctly", 2020-05-27) had previously changed `add -p` to handle new files but it did not implement patch editing correctly. The perl version simply forbade editing and the C version opened the editor with the full diff rather that just the hunk which meant that the user had to edit the hunk header manually to get it to work. The root cause of the problem is that added files store the diff header with the hunk data rather than separating the two as we do for other changes. Changing added files to store the diff header separately fixes the editing problem at the expense of having to special case empty additions as they no longer have any hunks associated with them, only the diff header. The changes move some existing code into a conditional changing the indentation, they are best viewed with --color-moved-ws=allow-indentation-change (or --ignore-space-change works well to get an overview of the changes) Signed-off-by: Phillip Wood Reported-by: Thomas Sullivan Reported-by: Yuchen Ying Signed-off-by: Junio C Hamano

add -p: fix memory leak

2020-09-08T21:51:38Z

asan reports that the C version of `add -p` is not freeing all the memory it allocates. Fix this by introducing a function to clear `struct add_p_state` and use it instead of freeing individual members. Signed-off-by: Phillip Wood Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

add-patch: fix inverted return code of repo_read_index()

2020-09-08T21:48:29Z

After applying hunks to a file with "add -p", the C patch_update_file() function tries to refresh the index (just like the perl version does). We can only refresh the index if we're able to read it in, so we first check the return value of repo_read_index(). But unlike many functions, where "0" is success, that function is documented to return the number of entries in the index. Hence we should be checking for success with a non-negative return value. Neither the tests nor any users seem to have noticed this, probably due to a combination of: - this affects only the C version, which is not yet the default - following it up with any porcelain command like "git diff" or "git commit" would refresh the index automatically. But you can see the problem by running the plumbing "git diff-files" immediately after "add -p" stages all hunks. Running the new test with GIT_TEST_ADD_I_USE_BUILTIN=1 fails without the matching code change. Signed-off-by: Jeff King Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'pw/add-p-allowed-options-fix'

2020-09-03T19:37:02Z

"git add -p" update. * pw/add-p-allowed-options-fix: add -p: fix checking of user input add -p: use ALLOC_GROW_BY instead of ALLOW_GROW

add -p: fix checking of user input

2020-08-17T18:44:42Z

When a file has been deleted the C version of add -p allows the user to edit a hunk even though 'e' is not in the list of allowed responses. (I think 'e' is disallowed because if the file is edited it is no longer a deletion and we're not set up to rewrite the diff header). The invalid response was allowed because the test that determines whether to display 'e' was not duplicated correctly in the code that processes the user's choice. Fix this by using flags that are set when constructing the prompt and checked when processing the user's choice rather than repeating the check itself. Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

add -p: use ALLOC_GROW_BY instead of ALLOW_GROW

2020-08-17T18:41:50Z

This simplifies the code slightly, especially the third case where hunk_nr was incremented a few lines before ALLOC_GROW(). Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

Merge branch 'jk/strvec'

2020-08-10T17:23:57Z

The argv_array API is useful for not just managing argv but any "vector" (NULL-terminated array) of strings, and has seen adoption to a certain degree. It has been renamed to "strvec" to reduce the barrier to adoption. * jk/strvec: strvec: rename struct fields strvec: drop argv_array compatibility layer strvec: update documention to avoid argv_array strvec: fix indentation in renamed calls strvec: convert remaining callers away from argv_array name strvec: convert more callers away from argv_array name strvec: convert builtin/ callers away from argv_array name quote: rename sq_dequote_to_argv_array to mention strvec strvec: rename files from argv-array to strvec argv-array: rename to strvec argv-array: use size_t for count and alloc