user/sven/git.git/git-add--interactive.perl, branch v1.5.6.4

add--interactive: allow user to choose mode update

2008-03-27T20:54:57Z

When using the 'p'atch command, instead of just throwing out any mode change, present it to the user in the same way that we show hunks. This way, the mode change can be staged independently from the changes to the contents. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

add--interactive: ignore mode change in 'p'atch command

2008-03-27T20:54:56Z

When a path is examined in the patch subcommand, any mode changes in the file are given to use in the diff header by git-diff. If no hunks are staged, then we throw out that header and do not touch the path. But if _any_ hunks are staged, we use the header, and the mode is changed together with the contents. Since the 'p'atch command should just be dealing with hunks that are shown to the user, it makes sense to just ignore mode changes entirely. We do squirrel away the mode, though, since the next patch will allow users to select the mode update separately. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

add--interactive: handle initial commit better

2008-02-16T09:02:44Z

There were several points where we looked at the HEAD commit; for initial commits, this is meaningless. So instead we: - show staged status data as a diff against the empty tree instead of HEAD - show file diffs as creation events - use "git rm --cached" to revert instead of going back to the HEAD commit We magically reference the empty tree to implement this. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

add--interactive: allow diff colors without interactive colors

2008-01-07T02:41:44Z

Users with color.diff set to true/auto will not see color in "git add -i" unless they also set color.interactive. This changes the semantics of color.interactive to control only the coloring of the interaction aspect of the command and let color.diff to control the color of hunk picker, which would arguably be more convenient. Old $use_color variable is now renamed to $menu_use_color to make it clear that it is about coloring the interaction. The "colored" subroutine now checks if the passed color is defined, instead of checking $use_color variable, to decide if the lines should be colored. The various variables that define colors for different parts of the output are set or unset depending on the setting of color.interactive and color.diff configuration variables. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

add--interactive: remove unused diff colors

2008-01-07T02:41:44Z

When color support was added, we colored the diffs ourselves. However, 4af756f3 changed this to simply run "git diff-files" twice, keeping the colored output separately. This makes the internal diff color variables obsolete with one exception: when splitting hunks, we have to manually recreate the fragment for each part of the split. Thus we keep $fraginfo_color around to do that correctly. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Teach "git add -i" to colorize whitespace errors

2007-12-08T10:53:19Z

Rather than replicating the colorization logic of "git diff-files" we rely on "git diff-files" itself. This guarantees consistent colorization in and outside "git add -i". Seeing as speed is not a concern here (the bottleneck is how fast the user can read, not how fast "git diff-files" runs) we do this by actually running it twice, once without color and once with. In this way as the whitespace colorization provided by "git diff-files" evolves (per-path attributes, new classes of whitespace error), "git add -i" will automatically benefit from it and stay in synch. Also, by working with two sets of diff output (an uncolorized one for internal processing and a colorized one for display only) we minimize the risk of regressions because the changes required to implement this are minimally invasive. Signed-off-by: Wincent Colaiuta Signed-off-by: Junio C Hamano

Color support for "git-add -i"

2007-12-06T01:57:11Z

This is mostly lifted from earlier series by Dan Zwell, but updated to use "git config --get-color" and "git config --get-colorbool" to make it simpler and more consistent with commands written in C. A new configuration color.interactive variable is like color.diff and color.status, and controls if "git-add -i" uses color. A set of configuration variables, color.interactive., are used to define what color is used for the prompt, header, and help text. For perl scripts, Git.pm provides $repo->get_color() method, which takes the slot name and the default color, and returns the terminal escape sequence to color the output text. $repo->get_colorbool() method can be used to check if color is set to be used for a given operation. Signed-off-by: Junio C Hamano

git-add -i: add help text for list-and-choose UI

2007-12-03T09:04:28Z

Signed-off-by: Junio C Hamano

add -i: allow prefix highlighting for "Add untracked" as well.

2007-12-02T19:09:22Z

These changes make the automatic prefix highlighting work with the "Add untracked" subcommand in git-add--interactive by explicitly handling arrays, hashes and strings internally (previously only arrays and hashes were handled). In addition, prefixes which have special meaning for list_and_choose (things like "*" for "all" and "-" for "deselect) are explicitly excluded (highlighting these prefixes would be misleading). Signed-off-by: Wincent Colaiuta Signed-off-by: Junio C Hamano

Highlight keyboard shortcuts in git-add--interactive

2007-11-30T20:37:40Z

The user interface provided by the command loop in git-add--interactive gives the impression that subcommands can only be launched by entering an integer identifier from 1 through 8. A "hidden" feature is that any string can be entered, and a regex search anchored at the beginning of the string is used to find the uniquely matching option. This patch makes this feature a little more obvious by highlighting the first character of each subcommand (for example "patch" is displayed as "[p]atch"). A new function is added to detect the shortest unique prefix and this is used to decide what to highlight. Highlighting is also applied when choosing files. In the case where the common prefix may be unreasonably large highlighting is omitted; in this patch the soft limit (above which the highlighting will be omitted for a particular item) is 0 (in other words, there is no soft limit) and the hard limit (above which highlighting will be omitted for all items) is 3, but this can be tweaked. The actual highlighting is done by the highlight_prefix function, which will enable us to implement ANSI color code-based highlighting (most likely using underline or boldface) in the future. Signed-off-by: Wincent Colaiuta Acked-by: Jeff King Signed-off-by: Junio C Hamano