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

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

[enrico]

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

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

[Junio C Hamano]

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

> 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 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?

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

[enrico]

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

> 
> enrico <enrico.guiraud <at> gmail.com> writes:
> 
> > 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 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.

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.

> 
> 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?
>

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.