Re: [PATCH 2/4] Teach git-add--interactive to accept a file path to patch

[Junio C Hamano <gitster@pobox.com>]

Wincent Colaiuta <win@wincent.com> writes:

> 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.

It is quite valid for users to run:

	git add -i \*.sh

and be able to choose from a list which paths to stage (as a
whole), as well as choose from a list which files to run the
per-hunk staging interface.  "git add \*.sh" won't give you any
chance to choose which ones to stage, and that's what we have
"-i" (interactive) mode in "git add" for.

I think you can massage "git add --partial foo" given by the
user internally into "git-add--interactive -i --patch foo".  I
strongly suspect that "direct to patch subcommand" mode needs
more than just initially jumping into the subcommand (for
example, you would want to exit when the patch selection
interaction ends, without going back to the main menu), and we
would want a signal stronger than mere presense of pathspecs to
trigger such a specialized behaviour.

By the way, the arguments on the command line to git commands
after "--" are generally pathspecs, iow, patterns to specify
groups of files.  Please do not introduce unnecessary
inconsistencies to the UI by requiring them to be exact pathname
only in this particular mode of the command and nowhere else.

There was one funny thing I fixed up.  The arguments to the
interactive_add() function in builtin-add.c was like this:

	int interactive_add(const char **argv, int argc)

Anybody who writes a function with such a signature and do not
notice its craziness before sending it out either (1) has never
programmed in C, (2) did not review the code before submitting,
or (3) worked too hard and was too tired.

I suspect, judging from the timestamp of your message, it was
(3) this time.  The collaborative development is not a race ---
don't work too hastily and too hard; please relax and review
after a good night's sleep before sending things out.