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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]