aboutsummaryrefslogtreecommitdiff
path: root/git-add--interactive.perl
Commit message (Collapse)AuthorAge
* add -i: do not dump patch during applicationThomas Rast2009-06-03
| | | | | | | | Remove a debugging print that snuck in at 7a26e65 (Revert "git-add--interactive: remove hunk coalescing", 2009-05-16). Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Revert "git-add--interactive: remove hunk coalescing"Junio C Hamano2009-05-16
| | | | | | | | This reverts commit 0beee4c6dec15292415e3d56075c16a76a22af54 but with a bit of twist, as we have added "edit hunk manually" hack and we cannot rely on the original line numbers of the hunks that were manually edited. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'mm/maint-add-p-quit'Junio C Hamano2009-04-20
|\ | | | | | | | | * mm/maint-add-p-quit: git add -p: add missing "q" to patch prompt
| * git add -p: add missing "q" to patch promptWincent Colaiuta2009-04-20
| | | | | | | | | | | | | | | | 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 <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * add-interactive: refactor mode hunk handlingJeff King2009-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git add -p: new "quit" command at the prompt.Matthieu Moy2009-04-19
| | | | | | | | | | | | | | | | | | 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 <gitster@pobox.com>
* | add-interactive: refactor mode hunk handlingJeff King2009-04-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git add -p: new "quit" command at the prompt.Matthieu Moy2009-04-15
| | | | | | | | | | | | | | | | | | 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 <gitster@pobox.com>
* | Merge branch 'jc/add-p-unquote'Junio C Hamano2009-03-05
|\ \ | |/ | | | | | | * jc/add-p-unquote: git-add -i/-p: learn to unwrap C-quoted paths
| * git-add -i/-p: learn to unwrap C-quoted pathsJunio C Hamano2009-02-18
| | | | | | | | | | | | | | | | | | | | 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 <gitster@pobox.com>
* | add -i: revisit hunk on editor failureDeskin Miller2009-02-11
|/ | | | | | | | | 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 <deskinm@umich.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add -p: get rid of Git.pm warnings about unitialized valuesStephan Beyer2009-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | 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 <s-beyer@gmx.net> Acked-By: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add -p: import Term::ReadKey with 'require'Thomas Rast2009-02-07
| | | | | | | | | eval{use...} is no good because the 'use' is evaluated at compile time, so manually 'require' it. We need to forward declare the functions we use, otherwise Perl raises a compilation error. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add -p: print errors in separate colorThomas Rast2009-02-05
| | | | | | | | Print interaction error messages in color.interactive.error, which defaults to the value of color.interactive.help. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add -p: prompt for single charactersThomas Rast2009-02-05
| | | | | | | | | | | | | | Use Term::ReadKey, if available and enabled with interactive.singlekey, to let the user answer add -p's prompts by pressing a single key. We're not doing the same in the main 'add -i' interface because file selection etc. may expect several characters. Two commands take an argument: 'g' can easily cope since it'll just offer a choice of chunks. '/' now (unconditionally, even without readkey) offers a chance to enter a regex if none was given. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add -p: trap Ctrl-D in 'goto' modeThomas Rast2009-02-04
| | | | | | | | | If the user hit Ctrl-D (EOF) while the script was in 'go to hunk?' mode, it threw an undefined variable error. Explicitly test for EOF and have it re-enter the goto prompt loop. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add -p: change prompt separator for 'g'Thomas Rast2009-02-04
| | | | | | | | | 57886bc (git-add -i/-p: Change prompt separater from slash to comma, 2008-11-27) changed the prompt separator to ',', but forgot to adapt the 'g' (goto) command. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* In add --patch, Handle K,k,J,j slightly more gracefully.William Pursell2009-02-01
| | | | | | | | Instead of printing the help menu, this will print "No next hunk" and then process the given hunk again. Signed-off-by: William Pursell <bill.pursell@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add / command in add --patchWilliam Pursell2009-02-01
| | | | | | | | This command allows the user to skip hunks that don't match the specified regex. Signed-off-by: William Pursell <bill.pursell@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-add -i/-p: Change prompt separater from slash to commaWilliam Pursell2009-02-01
| | | | | | | Otherwise the find command '/' soon to be introduced will be hard to see. Signed-off-by: William Pursell <bill.pursell@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add 'g' command to go to a hunkWilliam Pursell2008-12-04
| | | | | | | | | | When a minor change is made while the working directory is in a bit of a mess, it is somewhat difficult to wade through all of the hunks using git add --patch. This allows one to jump to the hunk that needs to be staged without having to respond 'n' to each preceding hunk. Signed-off-by: William Pursell <bill.pursell@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add subroutine to display one-line summary of hunksWilliam Pursell2008-12-04
| | | | | | | | | | | | This commit implements a rather simple-minded mechanism to display a one-line summary of the hunks in an array ref. The display consists of the line numbers and the first changed line, truncated to 80 characters. 20 lines are displayed at a time, and the index of the first undisplayed line is returned, allowing the caller to display more if desired. (The 20 and 80 should be made configurable.) Signed-off-by: William Pursell <bill.pursell@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add -p: warn if only binary changes presentThomas Rast2008-10-26
| | | | | | | | | | Current 'git add -p' will say "No changes." if there are no changes to text files, which can be confusing if there _are_ changes to binary files. Add some code to distinguish the two cases, and give a different message in the latter one. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'sp/win'Junio C Hamano2008-07-15
|\ | | | | | | | | | | | | * sp/win: We need to check for msys as well as Windows in add--interactive. Convert CR/LF to LF in tag signatures Fixed text file auto-detection: treat EOF character 032 at the end of file as printable
| * We need to check for msys as well as Windows in add--interactive.Mike Pape2008-07-11
| | | | | | | | | | | | Signed-off-by: Mike Pape <dotzenlabs@gmail.com> Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Make git-add -i accept ranges like 7-Ciaran McCreesh2008-07-15
| | | | | | | | | | | | | | | | | | git-add -i ranges expect number-number. But for the supremely lazy, typing in that second number when selecting "from patch 7 to the end" is wasted effort. So treat an empty second number in a range as "until the last item". Signed-off-by: Ciaran McCreesh <ciaran.mccreesh@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-add--interactive: manual hunk editing modeThomas Rast2008-07-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds a new option 'e' to the 'add -p' command loop that lets you edit the current hunk in your favourite editor. If the resulting patch applies cleanly, the edited hunk will immediately be marked for staging. If it does not apply cleanly, you will be given an opportunity to edit again. If all lines of the hunk are removed, then the edit is aborted and the hunk is left unchanged. Applying the changed hunk(s) relies on Johannes Schindelin's new --recount option for git-apply. Note that the "real patch" test intentionally uses (echo e; echo n; echo d) | git add -p even though the 'n' and 'd' are superfluous at first sight. They serve to get out of the interaction loop if git add -p wrongly concludes the patch does not apply. Many thanks to Jeff King <peff@peff.net> for lots of help and suggestions. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-add--interactive: remove hunk coalescingThomas Rast2008-07-02
| | | | | | | | | | | | | | | | | | Current git-apply has no trouble at all applying chunks that have overlapping context, as produced by the splitting feature. So we can drop the manual coalescing. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-add--interactive: replace hunk recounting with apply --recountThomas Rast2008-07-02
|/ | | | | | | | We recounted the postimage offsets to compensate for hunks that were not selected. Now apply --recount can do the job for us. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add--interactive: allow user to choose mode updateJeff King2008-03-27
| | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add--interactive: ignore mode change in 'p'atch commandJeff King2008-03-27
| | | | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add--interactive: handle initial commit betterJeff King2008-02-16
| | | | | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add--interactive: allow diff colors without interactive colorsJeff King2008-01-06
| | | | | | | | | | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add--interactive: remove unused diff colorsJeff King2008-01-06
| | | | | | | | | | | | | | 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Teach "git add -i" to colorize whitespace errorsWincent Colaiuta2007-12-08
| | | | | | | | | | | | | | | | | | | | | | 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 <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Color support for "git-add -i"Junio C Hamano2007-12-05
| | | | | | | | | | | | | | | | | | | 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.<slot>, 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 <gitster@pobox.com>
* git-add -i: add help text for list-and-choose UIWincent Colaiuta2007-12-03
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* add -i: allow prefix highlighting for "Add untracked" as well.Wincent Colaiuta2007-12-02
| | | | | | | | | | | | | | 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 <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Highlight keyboard shortcuts in git-add--interactiveWincent Colaiuta2007-11-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <win@wincent.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Document all help keys in "git add -i" patch mode.Ralf Wildenhues2007-11-28
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add "--patch" option to git-add--interactiveWincent Colaiuta2007-11-25
| | | | | | | | | | | | When the "--patch" option is supplied, the patch_update_cmd() function is called bypassing the main_loop() and exits. Seeing as builtin-add is the only caller of git-add--interactive we can impose a strict requirement on the format of the arguments to avoid possible ambiguity: an "--" argument must be used whenever any pathspecs are passed, both with the "--patch" option and without it. Signed-off-by: Wincent Colaiuta <win@wincent.com>
* git-add -i: allow multiple selection in patch subcommandJunio C Hamano2007-11-22
| | | | | | | | | | | | | This allows more than one files from the list to be chosen from the patch subcommand instead of going through the file one by one. This also updates the "list-and-choose" UI for usability. When the prompt ends with ">>", if you type '*' to choose all choices, the prompt immediately returns the choice without requiring an extra empty line to confirm the selection. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Add path-limiting to git-add--interactiveWincent Colaiuta2007-11-22
| | | | | | | | | | | | Implement Junio's suggestion that git-add--interactive should reproduce the path-limiting semantics of non-interactive git-add. In otherwords, if "git add -i" (unrestricted) shows paths from a set A, "git add -i paths..." should show paths from a subset of the set A and that subset should be defined with the existing ls-files pathspec semantics. Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Refactor patch_update_cmdWincent Colaiuta2007-11-22
| | | | | | | | | | | Split patch_update_cmd into two functions, one to prompt the user for a path to patch and another to do the actual work given that file path. This lays the groundwork for a future commit which will teach git-add--interactive to accept a path parameter and jump directly to the patch subcommand for that path, bypassing the interactive prompt. Signed-off-by: Wincent Colaiuta <win@wincent.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-ls-files: add --exclude-standardJeff King2007-11-15
| | | | | | | | This provides a way for scripts to get at the new standard exclude function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git add -i: Remove unused variablesJean-Luc Herren2007-10-15
| | | | | | Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git add -i: Fix parsing of abbreviated hunk headersJean-Luc Herren2007-10-15
| | | | | | | | | | | | | | | | | | The unified diff format allows one-line ranges to be abbreviated by omiting the size. The hunk header "@@ -10,1 +10,1 @@" can be expressed as "@@ -10 +10 @@", but this wasn't properly parsed in all cases. Such abbreviated hunk headers are generated when a one-line change (add, remove or modify) appears without context; for example because the file is a one-liner itself or because GIT_DIFF_OPTS was set to '-u0'. If the user then runs 'git add -i' and enters the 'patch' command for that file, perl complains about undefined variables. Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-add--interactive: Improve behavior on bogus inputJean-Luc Herren2007-09-29
| | | | | | | | | | | | | | 1) Previously, any menu would cause a perl error when entered '0', which is never a valid option. 2) Entering a bogus choice (like 998 or 4-2) surprisingly caused the same behavior as if the user had just hit 'enter', which means to carry out the selected action on the selected items. Entering such bogus input is now a no-op and the sub-menu doesn't exit. Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-add--interactive: Allow Ctrl-D to exitJean-Luc Herren2007-09-29
| | | | | | | | | | Hitting Ctrl-D (EOF) is a common way to exit shell-like tools. When in a sub-menu it will still behave as if an empty line had been entered, carrying out the action on the selected items and returning to the previous menu. Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Hack git-add--interactive to make it work with ActiveState PerlAlex Riesen2007-08-01
| | | | | | | It wont work for arguments with special characters (like ", : or *). It is generally not possible on Windows, so I didn't even try. Signed-off-by: Junio C Hamano <gitster@pobox.com>