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

add-interactive: Clarify “remaining hunks in the file”

2010-06-13T17:05:02Z

The "a" and "d" commands to ‘add --patch’ (accept/reject rest of file) interact with "j", "g", and "/" (skip some hunks) in a perhaps confusing way: after accepting or rejecting all _later_ hunks in the file, they return to the earlier, skipped hunks and prompt the user about them again. This behavior can be very useful in practice. One can still accept or reject _all_ undecided hunks in a file by using the "g" command to move to hunk #1 first. Reported-by: Frédéric Brière Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

Merge branch 'jk/maint-add--interactive-delete'

2010-03-07T20:47:14Z

* jk/maint-add--interactive-delete: add-interactive: fix bogus diff header line ordering

add-interactive: fix bogus diff header line ordering

2010-02-23T03:23:49Z

When we look at a patch for adding hunks interactively, we first split it into a header and a list of hunks. Some of the header lines, such as mode changes and deletion, however, become their own selectable hunks. Later when we reassemble the patch, we simply concatenate the header and the selected hunks. This leads to patches like this: diff --git a/file b/file index d95f3ad..0000000 --- a/file +++ /dev/null deleted file mode 100644 @@ -1 +0,0 @@ -content Notice how the deletion comes _after_ the ---/+++ lines, when it should come before. In many cases, we can get away with this as git-apply accepts the slightly bogus input. However, in the specific case of a deletion line that is being applied via "apply -R", this malformed patch triggers an assert in git-apply. This comes up when discarding a deletion via "git checkout -p". Rather than try to make git-apply accept our odd input, let's just reassemble the patch in the correct order. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'maint'

2009-12-09T06:47:09Z

* maint: add-interactive: fix deletion of non-empty files pull: clarify advice for the unconfigured error case

Merge branch 'jk/maint-add-p-delete-fix' into maint

2009-12-09T06:37:50Z

* jk/maint-add-p-delete-fix: add-interactive: fix deletion of non-empty files

add-interactive: fix deletion of non-empty files

2009-12-08T07:52:46Z

Commit 24ab81a fixed the deletion of empty files, but broke deletion of non-empty files. The approach it took was to factor out the "deleted" line from the patch header into its own hunk, the same way we do for mode changes. However, unlike mode changes, we only showed the special "delete this file" hunk if there were no other hunks. Otherwise, the user would annoyingly be presented with _two_ hunks: one for deleting the file and one for deleting the content. This meant that in the non-empty case, we forgot about the deleted line entirely, and we submitted a bogus patch to git-apply (with "/dev/null" as the destination file, but not marked as a deletion). Instead, this patch combines the file deletion hunk and the content deletion hunk (if there is one) into a single deletion hunk which is either staged or not. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jn/editor-pager'

2009-11-21T07:48:52Z

* jn/editor-pager: Provide a build time default-pager setting Provide a build time default-editor setting am -i, git-svn: use "git var GIT_PAGER" add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR" Teach git var about GIT_PAGER Teach git var about GIT_EDITOR Suppress warnings from "git var -l" Do not use VISUAL editor on dumb terminals Handle more shell metacharacters in editor names

Merge branch 'jk/maint-add-p-empty' into maint

2009-11-16T08:02:44Z

* jk/maint-add-p-empty: add-interactive: handle deletion of empty files

Merge branch 'jk/maint-add-p-empty'

2009-11-16T00:40:46Z

* jk/maint-add-p-empty: add-interactive: handle deletion of empty files

add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"

2009-11-13T20:20:50Z

Use the new "git var GIT_EDITOR" feature to decide what editor to use, instead of duplicating its logic elsewhere. This should make the behavior of commands in edge cases (e.g., editor names with spaces) a little more consistent. Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano