Re: git add -p with new file

From: Jeff King <peff@peff.net>
Date: Dec 9, 2016, 14:11 UTC
Message-ID: <20161209141129.r53b4rbtgd76fn2a@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.2.11.1612062012540.13185@cherryberry.dsgml.com>

On Tue, Dec 06, 2016 at 08:18:59PM -0500, Ariel wrote:

Show 10 quoted lines

> If you do git add -p new_file it says:
> 
> No changes.
> 
> Which is a rather confusing message. I would expect it to show me the
> content of the file in patch form, in the normal way that -p works, let me
> edit it, etc.
> 
> (Note: I am aware I can do -N first, but when I specifically enter the name
> of a new file I feel it should figure out what I mean.)

Keep in mind that the argument to "git add -p" is not a filename, but a "pathspec" that can match many files. What should:

  git init
  mkdir subdir
  for i in one two; do echo $i >subdir/$i; done
  git add -p subdir

do? Or for that matter, "git add -p ."? It's contrary to the rest of git-add for specifying pathspecs to actually make things _more_ inclusive rather than less.

So I don't think triggering the change of behavior based on the presence of a pathspec makes sense.

Historically "add -p" has been more like "add -u" in updating tracked files. We have "-A" for "update everything _and_ new files". It doesn't seem unreasonable to me to have a variant of "-p" that is similar.

I don't think that variant should just be "add -N everything, and then run add -p". As Duy points out, the patch for a new file is just one big block. But the decision of "do I want to start tracking this untracked file" is potentially an interesting one.

-Peff