Jeff King <peff@xxxxxxxx> writes:
>> 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.
Well, read the subject of your e-mail and tell me what it says ;-)
And that is why I was contrasting an imaginary workflow to use the
existing "add -p" with requested "allow it to be used with new files" with
what somebody may "emulate" without help from "add -p" machinery, which
is:
$ cp newfile.c newfile.c-saved
$ edit newfile.c ;# delete all the things you do not want for now
$ git add newfile.c
$ mv newfile.c-saved newfile.c
I just had to point the above out, even though I agree with the use case
you shown below for final verification. They are quite different topic, as
"git diff" won't be very useful for 'inspect changes' step in the "new
file" case to begin with.
> $ 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).
--
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