Re: Possible bug with git status in 1.7.0

Jens Lehmann wrote:

Yup, one line per submodule should be enough. But maybe it's nicer to
have the details /after/ the submodule name:

#	modified:   mod1 (Submodule has new commit(s), modified content, untracked content)

Then it fits more nicely with the output for files, no?

We could drop the "Submodule has " if people see it as a waste of screen
estate. Also i have no strong feelings about "content", i just happen to
think it is more appropriate as submodules can contain not only files but
other submodules too. Opinions?

Will send a patch for discussion as soon as i have something to show ...
  

How about

#	modified:   mod1 (submodule: new commit(s), modified content, untracked content)

trying to assure that what comes after the ":" is a list of comma 
separated properties.

This can make the thing easier to parse.  I know that there is a "git 
status ---porcelain" but from my understanding it will not be possible 
to get this kind of information from that command since its output 
format is frozen and not extensible, so many could resort to try to 
parse the "normal" git status output to get all the info about 
submodules at once.

Even better would be to have a "--interface_level 2" to go with 
---porcelain, to be able to pass this info even there.

BTW... about the --porcelain option, I wonder if considering an alias to 
--parseable could be on the list.  The plumbing/porcelain metaphor is 
really nice, but a --porcelain option can probably be a bit confusing 
for the beginner getting a

usage: git status [options] [--] <filepattern>...

    -v, --verbose         be verbose
    -s, --short           show status concisely
    --porcelain           show porcelain output format
    -z, --null            terminate entries with NUL
    -u, --untracked-files[=<mode>]
                          show untracked files, optional modes: all, 
normal, no. (Default: all)

considering that status is probably the first command the beginner may 
come into.

Sergio