Re: git add -p with new file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

> On Fri, Dec 09, 2016 at 01:43:24PM -0500, Ariel wrote:
> ...
>> But it doesn't have to be that way. You could make add -p identical to add
>> without options, except the -p prompts to review diffs first.
>
> The question is whether you would annoy people using "-p" if you started
> including untracked files by default. I agree because it's inherently an
> interactive process that we can be looser with backwards compatibility.

It might be interactive, but it will be irritating that we suddenly
have to see hundreds of lines in an untracked file before we are
asked to say "no I do not want to add this file" and have to do so
for all the untracked files that happen to match the given pathspec.

It might make it less irritating if one of the interactive choices
offered in the first prompt were N that tells the command: "No,
ignore all the untracked paths", though.  I dunno.

Also, because "git add -p" (no pathspec) is NOT a no-op, the
similarity Ariel sees with "git add" (no other options) does not
hold.  As you kept explaining (but perhaps not successfully being
understood yet), "add -p" works like "add -u", and it will make the
command incoherent if we allowed "git add -p <path>" to add new
paths, exactly because "git add -u <path>" does not do so.  Of
course that can be fixed by allowing "git add -u" to also add new
paths that match pathspec.

Of course, Ariel can vote for making "add -p" more like "add" (with
no options) than "add -u".  I _think_ it is a better way to solve
the incoherence than making "add -u" to add new paths.  But what it
means is that "add -p <paths>" works on both tracked and untracked
paths that match the given pathspec <paths>, and also "add -p" (no
pathspec) must become a no-op (because "add" without option and
pathspec is).




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]