On Tue, Jan 10, 2012 at 10:32:20AM -0800, Junio C Hamano wrote: > Thomas Rast <trast@xxxxxxxxxxxxxxx> 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 -- 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