Re: Re* git commit fails under some circumstances

[Will Palmer <wmpalmer@gmail.com>]

On Sat, 2011-04-02 at 12:16 -0700, Junio C Hamano wrote:
> Laszlo Papp <djszapi@archlinux.us> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html