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>
* 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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Earlier, when a path that was removed from the working tree was
chosen for update subcommand, you got an error like this:
error: git-resolve.sh: does not exist and --remove not passed
fatal: Unable to process file git-resolve.sh
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds hunk splitting and recounting the patch lines. The
'patch' subcommand now allows you to split a large hunk at
context lines in the middle.
Signed-off-by: Junio C Hamano <junkio@cox.net>
A script to be driven when the user says "git add --interactive"
is introduced.
When it is run, first it runs its internal 'status' command to
show the current status, and then goes into its internactive
command loop.
The command loop shows the list of subcommands available, and
gives a prompt "What now> ". In general, when the prompt ends
with a single '>', you can pick only one of the choices given
and type return, like this:
*** Commands ***
1: status 2: update 3: revert 4: add untracked
5: patch 6: diff 7: quit 8: help
What now> 1
You also could say "s" or "sta" or "status" above as long as the
choice is unique.
The main command loop has 6 subcommands (plus help and quit).
* 'status' shows the change between HEAD and index (i.e. what
will be committed if you say "git commit"), and between index
and working tree files (i.e. what you could stage further
before "git commit" using "git-add") for each path. A sample
output looks like this:
staged unstaged path
1: binary nothing foo.png
2: +403/-35 +1/-1 git-add--interactive.perl
It shows that foo.png has differences from HEAD (but that is
binary so line count cannot be shown) and there is no
difference between indexed copy and the working tree
version (if the working tree version were also different,
'binary' would have been shown in place of 'nothing'). The
other file, git-add--interactive.perl, has 403 lines added
and 35 lines deleted if you commit what is in the index, but
working tree file has further modifications (one addition and
one deletion).
* 'update' shows the status information and gives prompt
"Update>>". When the prompt ends with double '>>', you can
make more than one selection, concatenated with whitespace or
comma. Also you can say ranges. E.g. "2-5 7,9" to choose
2,3,4,5,7,9 from the list. You can say '*' to choose
everything.
What you chose are then highlighted with '*', like this:
staged unstaged path
1: binary nothing foo.png
* 2: +403/-35 +1/-1 git-add--interactive.perl
To remove selection, prefix the input with - like this:
Update>> -2
After making the selection, answer with an empty line to
stage the contents of working tree files for selected paths
in the index.
* 'revert' has a very similar UI to 'update', and the staged
information for selected paths are reverted to that of the
HEAD version. Reverting new paths makes them untracked.
* 'add untracked' has a very similar UI to 'update' and
'revert', and lets you add untracked paths to the index.
* 'patch' lets you choose one path out of 'status' like
selection. After choosing the path, it presents diff between
the index and the working tree file and asks you if you want
to stage the change of each hunk. You can say:
y - add the change from that hunk to index
n - do not add the change from that hunk to index
a - add the change from that hunk and all the rest to index
d - do not the change from that hunk nor any of the rest to index
j - do not decide on this hunk now, and view the next
undecided hunk
J - do not decide on this hunk now, and view the next hunk
k - do not decide on this hunk now, and view the previous
undecided hunk
K - do not decide on this hunk now, and view the previous hunk
After deciding the fate for all hunks, if there is any hunk
that was chosen, the index is updated with the selected hunks.
* 'diff' lets you review what will be committed (i.e. between
HEAD and index).
This is still rough, but does everything except a few things I
think are needed.
* 'patch' should be able to allow splitting a hunk into
multiple hunks.
* 'patch' does not adjust the line offsets @@ -k,l +m,n @@
in the hunk header. This does not have major problem in
practice, but it _should_ do the adjustment.
* It does not have any explicit support for a merge in
progress; it may not work at all.
Signed-off-by: Junio C Hamano <junkio@cox.net>
