Jeff King [off-list ref] writes:
quoted
I am also not really sure what problem this feature is trying to solve.
If the "problem"(?) is that it should act more like "git add" instead of
"git add -u", for whatever reason, this may be fine (but the
configuration option is a must-have then).
I think the problem is just that "add -p" does not give the whole story
of what you might want to do before making a commit.
The same is shared by "git diff [HEAD]", by the way. It is beyond
me why people use "add -p", not "git diff [HEAD]", for the final
sanity check before committing.
Perhaps the latter is not advertised well enough? "add -p" does not
even page so it is not very useful way to check what is being added
if you are adding a new file (unless you are doing a toy example to
add a 7-line file).
quoted
quoted
I'd also probably add interactive.showUntracked to make the whole thing
optional (but I think it would be OK to default it to on).
Hm, "interactive.showUntracked" is a confusing name because "git add -i"
(interactive) already handles untracked files.
Sure, that was just meant for illustration. I agree there's probably a
better name.
"interactive.*" is not a sensible hierarchy to use, because things
other than "add" can go interactive.
addPatch.showUntracked?
On Tue, Dec 13, 2016 at 10:48:07AM -0800, Junio C Hamano wrote:
quoted
I think the problem is just that "add -p" does not give the whole story
of what you might want to do before making a commit.
The same is shared by "git diff [HEAD]", by the way. It is beyond
me why people use "add -p", not "git diff [HEAD]", for the final
sanity check before committing.
Perhaps the latter is not advertised well enough? "add -p" does not
even page so it is not very useful way to check what is being added
if you are adding a new file (unless you are doing a toy example to
add a 7-line file).
I use "add -p" routinely for my final add-and-sanity-check, and it is
certainly not because I don't know about "git diff". I think it's just
nice to break it into bite-size chunks and sort them into "yes, OK" or
"no, not yet" bins. The lack of paging isn't usually a problem, because
this "add -p" is useful precisely when you have a lot of little changes
spread across the code base.
I'd probably also run "git diff" if I wanted to look at something
bigger. And I routinely use "git status", too, to see the full state of
my tree.
To me they are all tools in the toolbox, and I can pick the one that
works best in any given situation, or that I just feel like using that
day.
quoted
quoted
Hm, "interactive.showUntracked" is a confusing name because "git add -i"
(interactive) already handles untracked files.
Sure, that was just meant for illustration. I agree there's probably a
better name.
"interactive.*" is not a sensible hierarchy to use, because things
other than "add" can go interactive.
addPatch.showUntracked?
Hmm, I wonder if interactive.diffFilter was mis-named then. The
description is written in such a way as to cover other possible
interactive commands showing a diff.
It might be possible to do the same here: come up with a general option
that _could_ cover new situations, but right now just applies here. Or
maybe it would be too confusing.
TBH, I wasn't all that concerned with the name yet. Whoever writes the
patch can figure it out, and _then_ we can all bikeshed it. :)
-Peff