git/git-add--interactive.perl, branch v2.26.2

git add -p: use non-zero exit code when the diff generation failed

2019-12-06T16:57:34Z

The first thing `git add -p` does is to generate a diff. If this diff cannot be generated, `git add -p` should not continue as if nothing happened, but instead fail. What we *actually* do here is much broader: we now verify for *every* `run_cmd_pipe()` call that the spawned process actually succeeded. Note that we have to change two callers in this patch, as we need to store the spawned process' output in a local variable, which means that the callers can no longer decide whether to interpret the `return <$fh>` in array or in scalar context. This bug was noticed while writing a test case for the diff.algorithm feature, and we let that test case double as a regression test for this fixed bug, too. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

add -i: show progress counter in the prompt

2019-10-03T22:12:19Z

Report the current hunk count and total number of hunks for the current file in the prompt. Also adjust the expected output in some tests to match. Signed-off-by: Kunal Tyagi Signed-off-by: Junio C Hamano

Merge branch 'nd/switch-and-restore'

2019-07-09T22:25:44Z

Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command. * nd/switch-and-restore: (46 commits) completion: disable dwim on "git switch -d" switch: allow to switch in the middle of bisect t2027: use test_must_be_empty Declare both git-switch and git-restore experimental help: move git-diff and git-reset to different groups doc: promote "git restore" user-manual.txt: prefer 'merge --abort' over 'reset --hard' completion: support restore t: add tests for restore restore: support --patch restore: replace --force with --ignore-unmerged restore: default to --source=HEAD when only --staged is specified restore: reject invalid combinations with --staged restore: add --worktree and --staged checkout: factor out worktree checkout code restore: disable overlay mode by default restore: make pathspec mandatory restore: take tree-ish from --source option instead checkout: split part of it to new command 'restore' doc: promote "git switch" ...

Merge branch 'pw/add-p-recount'

2019-07-09T22:25:37Z

"git checkout -p" needs to selectively apply a patch in reverse, which did not work well. * pw/add-p-recount: add -p: fix checkout -p with pathological context

add -p: fix checkout -p with pathological context

2019-06-13T17:00:30Z

Commit fecc6f3a68 ("add -p: adjust offsets of subsequent hunks when one is skipped", 2018-03-01) fixed adding hunks in the correct place when a previous hunk has been skipped. However it did not address patches that are applied in reverse. In that case we need to adjust the pre-image offset so that when apply reverses the patch the post-image offset is adjusted correctly. We subtract rather than add the delta as the patch is reversed (the easiest way to think about it is to consider a hunk of deletions that is skipped - in that case we want to reduce offset so we need to subtract). Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

restore: support --patch

2019-05-07T04:04:47Z

git-restore is different from git-checkout that it only restores the worktree by default, not both worktree and index. add--interactive needs some update to support this mode. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

Merge branch 'pw/add-p-recount'

2018-06-28T19:53:32Z

When user edits the patch in "git add -p" and the user's editor is set to strip trailing whitespaces indiscriminately, an empty line that is unchanged in the patch would become completely empty (instead of a line with a sole SP on it). The code introduced in Git 2.17 timeframe failed to parse such a patch, but now it learned to notice the situation and cope with it. * pw/add-p-recount: add -p: fix counting empty context lines in edited patches

add -p: fix counting empty context lines in edited patches

2018-06-11T16:45:19Z

recount_edited_hunk() introduced in commit 2b8ea7f3c7 ("add -p: calculate offset delta for edited patches", 2018-03-05) required all context lines to start with a space, empty lines are not counted. This was intended to avoid any recounting problems if the user had introduced empty lines at the end when editing the patch. However this introduced a regression into 'git add -p' as it seems it is common for editors to strip the trailing whitespace from empty context lines when patches are edited thereby introducing empty lines that should be counted. 'git apply' knows how to deal with such empty lines and POSIX states that whether or not there is an space on an empty context line is implementation defined [1]. Fix the regression by counting lines that consist solely of a newline as well as lines starting with a space as context lines and add a test to prevent future regressions. [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/diff.html Reported-by: Mahmoud Al-Qudsi Reported-by: Oliver Joseph Ash Reported-by: Jeff Felchner Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

add--interactive: compute the empty tree value

2018-05-02T04:59:53Z

The interactive add script hard-codes the object ID of the empty tree. To avoid any problems when changing hashes, compute this value when used and cache it for any future uses. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'pw/add-p-single'

2018-04-02T17:10:55Z

Hotfix. * pw/add-p-single: add -p: fix 2.17.0-rc* regression due to moved code