From: Jeff King <peff@peff.net>
Date: Tue, 10 Jan 2012 18:38:33 GMT
Subject: Re: Please support add -p with a new file, to add only part of the file
Message-ID: <20120110183833.GA15787@sigill.intra.peff.net>
In-Reply-To: <7vpqer9znv.fsf@alter.siamese.dyndns.org>

On Tue, Jan 10, 2012 at 10:32:20AM -0800, Junio C Hamano wrote:

> Thomas Rast <trast@student.ethz.ch> writes:
> 
> > A not-so-proper solution might of course start by looking at which files
> > are untracked, and only run the 'git add -N' immediately before patch
> > application.
> 
> Isn't the real issue that we mistakenly gave an impression that "add -p"
> is the primary interface to the users, and forgot to tell them about the
> more general "add -i", which "add -p" is a small subset of?

Maybe it is just me, but I find "add -p" insanely useful, and the rest
of "add -i" to be worthless clutter. The "add -p" functionality is not
easily available anywhere else, but the rest of "add -i" can be easily
(and often more efficiently) mimicked using existing git commands.

> Even if you start with "add -N", there won't be individual "hunks" you can
> pick and choose from diffing emptiness and the whole new file, so you end
> up using "edit hunk" interface.

I don't think the main impetus for this is that people necessarily want
to pick and choose hunks from added files. I think it is simply a nice
workflow to do:

  $ hack hack hack
  $ git add -p ;# inspect and add changes
  $ git commit

which is very similar to the traditional git workflow:

  $ hack hack hack
  $ git diff ;# inspect changes
  $ git add foo ;# add changes
  $ git commit

I find myself using "add -p" almost exclusively these days, as it
combines the two middle steps (and even though I usually am just hitting
"y" after inspection, when I _do_ want to make a change, I am right
there in the hunk selection loop already).

-Peff