git/git-add--interactive.perl, 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

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--interactive.perl: specify --no-color explicitly

2020-09-08T21:49:11Z

Our color tests of "git add -p" do something a bit different from how a normal user would behave: we pretend there's a pager in use, so that Git thinks it's OK to write color to a non-tty stdout. This comes from 8539b46534 (t3701: avoid depending on the TTY prerequisite, 2019-12-06), which allows us to avoid a lot of complicated mock-tty code. However, those environment variables also make their way down to sub-processes of add--interactive, including the "diff-files" we run to generate the patches. As a result, it thinks it should output color, too. So in t3701.50, for example, the machine-readable version of the diff we get unexpectedly has color in it. We fail to parse it as a diff and think there are zero hunks. The test does still pass, though, because even with zero hunks we'll dump the diff header (and we consider those unparseable bits to be part of the header!), and so the output still has the expected color codes in it. We don't notice that the command was totally broken and failed to apply anything. And in fact we're not really testing what we think we are about the color, either. While add--interactive does correctly show the version we got from running "diff-files --color", we'd also pass the test if we had accidentally shown the machine-readable version, too, since it (erroneously) has color codes in it. One could argue that the test isn't very realistic; it's setting up this "pretend there's a pager" situation to get around the tty restrictions of the test environment. So one option would be to move back towards using a real tty. But the behavior of add--interactive really is user-visible here. If a user, for whatever reason, did run "git --paginate add --patch" (perhaps because their pager is really a filter or something), the command would totally fail to do anything useful. Since we know that we don't want color in this output, let's just make add--interactive more defensive, and say "--no-color" explicitly. It doesn't hurt anything in the common case, but it fixes this odd case and lets our test function properly again. Note that the C builtin run_add_p() already passes --no-color, so it doesn't need a similar fix. That will eventually replace this perl code anyway, but the test change here will be valuable for ensuring that. Signed-off-by: Jeff King Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

checkout -p: handle new files correctly

2020-05-27T21:50:20Z

The original patch selection code was written for `git add -p`, and the fundamental unit on which it works is a hunk. We hacked around that to handle deletions back in 24ab81ae4d (add-interactive: handle deletion of empty files, 2009-10-27). But `git add -p` would never see a new file, since we only consider the set of tracked files in the index. However, since the same machinery was used for `git checkout -p` & friends, we can see new files. Handle this case specifically, adding a new prompt for it that is modeled after the `deleted file` case. This also fixes the problem where added _empty_ files could not be staged via `git checkout -p`. Reported-by: Merlin Büge Helped-by: Jeff King Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

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