git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Eenrico <enrico.guiraud@gmail.com>
Date
May 20, 2016, 15:32 UTC
Message-ID
<loom.20160520T172851-785@post.gmane.org>
In-Reply-To
<xmqq7feohirb.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster <at> pobox.com> writes:
Show 20 quoted lines
> 
> 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.

Show 20 quoted lines
> 
> 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.

Previous: Junio C Hamano
Message 3 of 3 in “more novice-friendly behaviour of `git add -p`”
  1. enricoMay 20, 2016
  2. Junio C HamanoMay 20, 2016
  3. enricoMay 20, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.