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

Re: Possible bug with git status in 1.7.0

From
Jens Lehmann <jens.lehmann@web.de>
Date
Feb 17, 2010, 20:52 UTC
Message-ID
<4B7C5711.8060708@web.de>
In-Reply-To
<4B7C490B.8030902@gmail.com>
Am 17.02.2010 20:52, schrieb Sergio Callegari:
Show 27 quoted lines
> Junio C Hamano wrote:
>> You are getting reminded that you either forgot to "git add" that file in
>> the submodule, or you forgot to add that file to .gitignore in the
>> submodule.
>>   
> 
> Thanks for the explanation!
> 
> The wording of the reminder is a bit unclear, though.  Suppose that the
> problem is with submodule "mod".
> 
> What you get from git status is a notice that something is modified but
> not updated, with the following suggestion
> 
> # Changed but not
> updated:                                                                                     
> 
> #   (use "git add <file>..." to update what will be committed)
> 
> and then the notice about what is in fact modified
> 
> #       modified:   mod
> 
> 
> So the first problem is that now git status provides a hint that may be
> confusing.  One gets the idea that he needs to add mod (to store a new
> commit id in the index) and not to add a file in mod.

That is a very valid point. I am currently working on git status being more explicit about the type of modification. I just asked for comments on this issue on February 14th in the thread titled "[PATCH/RFC] git diff --submodule: Show detailed dirty status of submodules" (Gmane is down for me right now, so i am sorry: no link today).

The changes i have in mind for git status would also include giving a better hint, as you rightfully pointed out.

Show 25 quoted lines
> As a second issue, note that mod is in fact not really modified being that
> 
> 1) no tracked file in it has been modified.
> 2) no new commit has been made
> 
> and the fact is that from git status I cannot recognize anymore if the
> module is really changed (the module commit id has changed) or has
> uncommited changes (some tracked file is changed) or is merely polluted
> by untracked files, so now I always need to explore the submodule.
> 
> It is true that this can be solved putting more stuff in .gitignore.
> However, it might be a matter of taste, but I do not like putting all
> byproducts in .gitignore  because not doing so allows me to
> differentiate between
> 
> - files that are just garbage
> - files that are not tracked but may be still precious
> 
> and selectively clean either category using the -x or -X options of git
> clean.
> 
> 
> So, it would be nice to improve the feedback of git status for this
> particular case and possibly have an option to avoid status being so
> wordy about untracked files.

So i assume that my proposal to explicitly state that a submodule has new commits, modified files and/or untracked files would solve your woes?

Previous: Sergio CallegariNext: Sergio Callegari
Message 4 of 7 in “Possible bug with git status in 1.7.0”
  1. SergioFeb 17, 2010
  2. Junio C HamanoFeb 17, 2010
  3. Sergio CallegariFeb 17, 2010
  4. Jens LehmannFeb 17, 2010
  5. Sergio CallegariFeb 19, 2010
  6. Jens LehmannFeb 19, 2010
  7. Sergio CallegariFeb 20, 2010

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.