From: enrico <enrico.guiraud@gmail.com>
To: git@vger.kernel.org
Subject: Re: more novice-friendly behaviour of `git add -p`
Date: Fri, 20 May 2016 15:32:54 +0000 (UTC) [thread overview]
Message-ID: <loom.20160520T172851-785@post.gmane.org> (raw)
In-Reply-To: xmqq7feohirb.fsf@gitster.mtv.corp.google.com
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.
prev parent reply other threads:[~2016-05-20 15:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-20 13:06 more novice-friendly behaviour of `git add -p` enrico
2016-05-20 15:05 ` Junio C Hamano
2016-05-20 15:32 ` enrico [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20160520T172851-785@post.gmane.org \
--to=enrico.guiraud@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).