git/git-add--interactive.perl, branch v1.6.3

Merge branch 'mm/maint-add-p-quit'

2009-04-20T10:39:38Z

* mm/maint-add-p-quit: git add -p: add missing "q" to patch prompt

git add -p: add missing "q" to patch prompt

2009-04-20T10:38:44Z

Commit cbd3a01 added a new "q" subcommand to the "git add -p" command loop, but forgot to add it to the prompt. Signed-off-by: Wincent Colaiuta Signed-off-by: Junio C Hamano

add-interactive: refactor mode hunk handling

2009-04-19T19:35:38Z

The original implementation considered the mode separately from the rest of the hunks, asking about it outside the main hunk-selection loop. This patch instead places a mode change as the first hunk in the loop. This has two advantages: 1. less duplicated code (since we use the main selection loop). This also cleans up an inconsistency, which is that the main selection loop separates options with a comma, whereas the mode prompt used slashes. 2. users can now skip the mode change and come back to it, search for it (via "/mode"), etc, as they can with other hunks. To facilitate this, each hunk is now marked with a "type". Mode hunks are not considered for splitting (which would make no sense, and also confuses the split_hunk function), nor are they editable. In theory, one could edit the mode lines and change to a new mode. In practice, there are only two modes that git cares about (0644 and 0755), so either you want to move from one to the other or not (and you can do that by staging or not staging). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

git add -p: new "quit" command at the prompt.

2009-04-19T19:35:37Z

There's already 'd' to stop staging hunks in a file, but no explicit command to stop the interactive staging (for the current files and the remaining ones). Of course you can do 'd' and then ^C, but it would be more intuitive to allow 'quit' action. Signed-off-by: Junio C Hamano

add-interactive: refactor mode hunk handling

2009-04-16T08:06:52Z

git add -p: new "quit" command at the prompt.

2009-04-16T02:41:35Z

Merge branch 'jc/add-p-unquote'

2009-03-05T23:41:41Z

* jc/add-p-unquote: git-add -i/-p: learn to unwrap C-quoted paths

git-add -i/-p: learn to unwrap C-quoted paths

2009-02-18T18:53:49Z

The underlying plumbing commands are not run with -z option, so the paths returned from them need to be unquoted as needed. Remove the now stale BUGS section from git-add documentaiton as suggested by Teemu Likonen. Signed-off-by: Junio C Hamano

add -i: revisit hunk on editor failure

2009-02-12T07:51:15Z

Similar to the behaviour for editing a commit message, let terminating the editor with a failure abort the current hunk edit and revisit the option selection for the hunk. Signed-off-by: Deskin Miller Signed-off-by: Junio C Hamano

add -p: get rid of Git.pm warnings about unitialized values

2009-02-08T21:06:33Z

After invoking git add -p I always got the warnings: Use of uninitialized value $_[3] in exec at Git.pm line 1282. Use of uninitialized value $args[2] in join or string at Git.pm line 1264. A bisect showed that these warnings occur in a301973 "add -p: print errors in separate color" the first time. They can be reproduced by setting color.ui (or color.interactive) to "auto" and unsetting color.interactive.help and color.interactive.error. I am using Perl 5.10.0. The reason of the warning is that color.interactive.error defaults to color.interactive.help which defaults to nothing in the specific codepath. It defaults to 'red bold' some lines above which could lead to the wrong assumption that it always defaults to 'red bold' now. This patch lets it default to 'red bold', blowing the warnings away. Signed-off-by: Stephan Beyer Acked-By: Thomas Rast Signed-off-by: Junio C Hamano