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?
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.
Whatever you do, you should aim to make it easier to use than
$ 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
Personally, I think it is a very tall order to tweak "add -p / edit"
interface to make it easier to use than the above four command sequence,
the second one among which is the most time and braincell consuming part
of the process, especially when "add -p / edit" gives you has to be
unnecessarily distracting by having '+' prefix.
--
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