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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 22, 2007, 11:29 UTC
Message-ID: <7vlk8q5xj4.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <887C3CB1-D21B-4143-8D4E-BF37709FA102@wincent.com>

Wincent Colaiuta <win@wincent.com> writes:

Show 7 quoted lines

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