El 22/11/2007, a las 10:50, Junio C Hamano escribió:
Jeff King <peff@xxxxxxxx> writes:
On Wed, Nov 21, 2007 at 04:18:57PM -0800, Junio C Hamano wrote:
What I meant was that if "git add -i" (unrestricted) shows paths
from a set A, "git add -i paths..." should show paths from a
subset of the set A and that subset should be defined with the
existing ls-files pathspec semantics.
Ah, I think that is definitely the right behavior. But it does
raise one
more question: is going right into the 'add hunk' interface the
correct
behavior, or is that an orthogonal issue?
I am moderately negative about "paths imply jump to patch
subcommand". An option to git-add--interactive that tells which
subcommand to initially choose is probably acceptable, though.
Let me explain a little why I started this series. Basically, given
file "foo" which had multiple changes in it I wanted to stage only
selected hunks; so I typed:
git add -i foo
Which of course didn't work. What I wanted to do was jump straight
into the patch subcommand (hence this series).
If I wanted to add entire files I would have just typed:
git add foo
So I don't think the proposal to add "-p" (jump to "patch" subcommand)
and "-a" (jump to "add untracked" subcommand) are a very good idea,
seeing as we already have builtin-add for adding entire files.
Cheers,
Wincent
-
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
