git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Re* git commit fails under some circumstances

From
Will Palmer <wmpalmer@gmail.com>
Date
Apr 5, 2011, 08:14 UTC
Message-ID
<1301991295.2320.11.camel@wpalmer.simply-domain>
In-Reply-To
<7vhbagh3aw.fsf@alter.siamese.dyndns.org>
On Sat, 2011-04-02 at 12:16 -0700, Junio C Hamano wrote:
Show 12 quoted lines
> 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
Show 12 quoted lines
> 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
Previous: Junio C HamanoNext: Junio C Hamano
Message 3 of 8 in “git commit fails under some circumstances”
  1. Laszlo PappApr 2, 2011
  2. Re* git commit fails under some circumstancesJunio C Hamano, Apr 2, 2011
  3. Will PalmerApr 5, 2011
  4. Junio C HamanoApr 5, 2011
  5. Will PalmerApr 5, 2011
  6. Jeff KingApr 5, 2011
  7. Junio C HamanoApr 6, 2011
  8. Jeff KingApr 6, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.