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

add--interactive: respect diff.compactionHeuristic

2016-06-16T18:38:58Z

We use plumbing to generate the diff, so it doesn't automatically pick up UI config like compactionHeuristic. Let's forward it on, since interactive adding is porcelain. Note that we only need to handle the "true" case. There's no point in passing --no-compaction-heuristic when the variable is false, since nothing else could have turned it on. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

add--interactive: allow custom diff highlighting programs

2016-02-28T18:53:54Z

The patch hunk selector of add--interactive knows how ask git for colorized diffs, and correlate them with the uncolored diffs we apply. But there's not any way for somebody who uses a diff-filter tool like contrib's diff-highlight to see their normal highlighting. This patch lets users define an arbitrary shell command to pipe the colorized diff through. The exact output shouldn't matter (since we just show the result to humans) as long as it is line-compatible with the original diff (so that hunk-splitting can split the colorized version, too). I left two minor issues with the new system that I don't think are worth fixing right now, but could be done later: 1. We only filter colorized diffs. Theoretically a user could want to filter a non-colorized diff, but I find it unlikely in practice. Users who are doing things like diff-highlighting are likely to want color, too. 2. add--interactive will re-colorize a diff which has been hand-edited, but it won't have run through the filter. Fixing this is conceptually easy (just pipe the diff through the filter), but practically hard to do without using tempfiles (it would need to feed data to and read the result from the filter without deadlocking; this raises portability questions with respect to Windows). I've punted on both issues for now, and if somebody really cares later, they can do a patch on top. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'ak/add-i-empty-candidates'

2015-02-17T18:15:20Z

The interactive "show a list and let the user choose from it" interface "add -i" used showed and prompted to the user even when the candidate list was empty, against which the only "choice" the user could have made was to choose nothing. * ak/add-i-empty-candidates: add -i: return from list_and_choose if there is no candidate

add -i: return from list_and_choose if there is no candidate

2015-01-22T22:44:36Z

The list_and_choose() helper is given a prompt and a list, asks the user to make selection from the list, and then returns a list of items chosen. Even when it is given an empty list as the original candidate set to choose from, it gave a prompt to the user, who can only say "I am done choosing". Return an empty result when the input is an empty list without bothering the user. The existing caller must already have a logic to say "Nothing to do" or an equivalent when the returned list is empty (i.e. the user chose to select nothing) if it is necessary, so no change to the callers is necessary. This fixes the case where "add untracked" is asked in "git add -i" and there is no untracked files in the working tree. We used to give an empty list of files to choose from with a prompt, but with this change, we no longer do. Signed-off-by: Alexander Kuleshov Signed-off-by: Junio C Hamano

add--interactive: leave main loop on read error

2014-12-15T18:12:20Z

The main hunk loop for add--interactive will loop if it does not get a known input. This is a good thing if the user typed some invalid input. However, if we have an uncorrectable read error, we'll end up looping infinitely. We can fix this by noticing read errors (i.e., returns undef) and breaking out of the loop. One easy way to trigger this is if you have an editor that does not take over the terminal (e.g., one that spawns a window in an existing process and waits), start the editor with the hunk-edit command, and hit ^C to send SIGINT. The editor process dies due to SIGINT, but the perl add--interactive process does not (perl suspends SIGINT for the duration of our system() call). We return to the main loop, but further reads from stdin don't work. The SIGINT _also_ killed our parent git process, which orphans our process group, meaning that further reads from the terminal will always fail. We loop infinitely, getting EIO on each read. Note that there are several other spots where we read from stdin, too. However, in each of those cases, we do something sane when the read returns undef (breaking out of the loop, taking the input as "no", etc). They don't need similar treatment. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jl/nor-or-nand-and'

2014-04-08T19:00:28Z

Eradicate mistaken use of "nor" (that is, essentially "nor" used not in "neither A nor B" ;-)) from in-code comments, command output strings, and documentations. * jl/nor-or-nand-and: code and test: fix misuses of "nor" comments: fix misuses of "nor" contrib: fix misuses of "nor" Documentation: fix misuses of "nor"

code and test: fix misuses of "nor"

2014-03-31T22:29:33Z

Signed-off-by: Justin Lebar Signed-off-by: Junio C Hamano

git-add--interactive: warn if module for interactive.singlekey is missing

2014-03-03T22:11:18Z

Suggested-by: Junio C Hamano Signed-off-by: Simon Ruderich Signed-off-by: Junio C Hamano

add-interactive: handle unborn branch in patch mode

2013-10-25T21:54:17Z

The list_modified function already knows how to handle an unborn branch by diffing against the empty tree. However, the diff we perform to get the actual hunks does not. Let's use the same logic for both diffs. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

add--interactive: fix external command invocation on Windows

2013-09-04T17:35:25Z

Back in 21e9757e (Hack git-add--interactive to make it work with ActiveState Perl, 2007-08-01), the invocation of external commands was changed to use qx{} on Windows. The rationale was that the command interpreter on Windows is not a POSIX shell, but rather Windows's CMD. That patch was wrong to include 'msys' in the check whether to use qx{} or not: 'msys' identifies MSYS perl as shipped with Git for Windows, which does not need the special treatment; qx{} should be used only with ActiveState perl, which is identified by 'MSWin32'. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano