On Sat, 2011-04-02 at 12:16 -0700, Junio C Hamano wrote: > Laszlo Papp <djszapi@xxxxxxxxxxxx> writes: > > 3) It would be nice to have one command (with no (git) alias for sure) > > to see the difference like "git diff" but also the new files. > > Doesn't "git diff" show the difference for files you told git about via > the "add -N" interface? After the above "addition" of RENAMING, if I ask > "git diff" (or "git diff HEAD"), I get what I expect to see (addition of > the contents taken from the whole file in the working tree). > > Again, please describe what you think should be the right output if it > differs from your expectation. > To give some context: the problem here is that "git add -N" was being used as a glorified way of saying "show the content of a file I have just added in "git diff" output along with unstaged content", as is described in the manual for "git add" as one of the purposes of -N. All the other problems are somewhat invented issues stemming from this one. That is, a result of blindly following instructions to "try git add -N if you want to see the output in diff", without the implications having been explained first. The alternative, "git add everything else, then use git diff --cached" I believe is unsuitable because the goal is to have "git diff" 'just work' in future runs, without the need for additional commands being run. Honestly I do not quite understand the exact use-case. An option such as --treat-new-as-unstaged might solve this better, but of course suffers from the problem of having a terrible name. I greatly suspect that the name being terrible is a sign of the idea not being fleshed-out enough yet. There are also various cases involving renames where it would not be clear at all how to handle things. -- Will > Also having said that, I notice that "git diff --cached" behaves as if an > empty blob is added in such a case. I am not sure if we want to special > case this. After all paths marked with "git add -N" does _not_ have a > concrete contents in the index by definition (as the user told "I'll tell > you later" but hasn't done so), and may want to behave more like unmerged > entries for certain operations (i.e. the path does exist, but comparing > something with it does not have a usual meaning, etc.) > > -- > 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 -- 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