Re: Re* git commit fails under some circumstances

On Sat, 2011-04-02 at 12:16 -0700, Junio C Hamano wrote:

Laszlo Papp [off-list ref] writes:

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html