more novice-friendly behaviour of `git add -p`

Hello all, I have encountered a couple of non-necessary difficulties when editing a patch during a `git add -p`.

Firstly, the help message says "To remove '-' lines, make them ' ' lines (context)." which is a bit confusing because that "them" refers to '-', not to 'lines'. I spent a good half hour changing '-' lines to lines containing a single white space but git was not very happy about it. I would suggest to change that line with "To remove '-' lines, change '-' into ' ' (for context)"

Secondly, as discussed here (http://git.661346.n2.nabble.com/git-add-patch-bug-with-split-edit-td2171634.html) and in numerous stackoverflow questions, the behaviour of the "edit" (e) option during an interactive add is a bit...bizarre: it requires the user to do a lot of gymnastic if (s)he is editing a hunk after having used the split (s) option, and nine times out of ten the patch will not apply cleanly. I would suggest to change the behaviour of the interactive add to only allow edits when the hunk has not been split (possibly with a one-line explanation for why editing is not possible appearing when inside a split hunk). Since editing is more powerful than splitting this would not result in a loss of generality, but, in my humble opinion, in a much nicer experience for novices and experts alike.

Best regards, enrico

enrico <enrico.guiraud@gmail.com> writes:

I think that sentence refers to a line line this in a patch:

    -This is what the line used to be

as a '-'-line. A line that does not change between preimage and postimage have SP instead of '-' at the beginning, and the sentence seems to refer to it as a ' '-line. So from that reading, "turning '-'-lines that you do not want to loes into ' '-lines" is perfectly sensible phrasing.

In any case, "edit" is about giving a low-level access and precise control to people who are familiar with (1) what each line of "diff" output means and (2) what is done to them by "patch" (rather, in Git's context, "apply").

I agree with you that "edit" mode is a too-advanced tool for those who are not comfortable with these two things. A solution would however not be to modify "edit" mode (which would affect those who are prepared to and want to use the "low-level access and precise control" to their advantage), but to introduce an easier-to-use, and perhaps a bit limited for safety, mode for those who are not the target audience for "edit" mode.

The "split" subcommand to split the hunk before applying was an attempt to go in that direction; it never allows you the user to make an arbitrary change to corrupt the patch and make it unusable. Perhaps you can mimick its spirit and come up with a new "guarded edit" command?

Junio C Hamano <gitster <at> pobox.com> writes:

I agree it is, and that little dash would definitely make the message less ambiguous. Git has a way to "explain itself" to its users so that they can become better as they use it, and these sort of messages play a very important part in this learning process.

I am not sure we are talking about the same issue. I am not pointing out that git is unsafe to less-than-very-expert users. Much more trivially, I am saying that the current behaviour of the "edit" mode, when coupled with hunk splitting, is needlessly frustrating (because of the issue described in the link I provided in my previous message). That's why I would argue that git would help wanna-be-experts better if it told them, in some way, that editing after splitting is generally a bad idea. Advanced users would not be bothered by this warning/lack-of-edit-after-splitting because, I think, they don't do it anyway. They already know it is a pain, so they either split or edit.