From: Junio C Hamano <hidden> Date: 2016-06-15 22:48:18
Sergio [off-list ref] writes:
if you have a submodule and the submodule contains
untracked files, "git status" in 1.7.0 keeps showing
the module as modified.
But of of course it is useless to "git add" the module
or to try to "git commit -a", since the index entry is ok
Of course it is useless to "git add" in the superproject, and this is
an intended bugfix.
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.
if you have a submodule and the submodule contains
untracked files, "git status" in 1.7.0 keeps showing
the module as modified.
But of of course it is useless to "git add" the module
or to try to "git commit -a", since the index entry is ok
Of course it is useless to "git add" in the superproject, and this is
an intended bugfix.
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.
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.
Sergio
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.
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?
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.
Missed that, thanks for pointing out
quoted
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?
Yes! My ideal behavior (if I am not asking too much) would be trying to
keep the status as little wordy as possible (1 line per submodule)
e.g. something like
# modified module (commit id): mod1
# modified module (modified files): mod2
# modified module (untracked files): mod3
# modified module (modified files, untracked files): mod4
# modified module (commit id, modified files, untracked files): mod5
and with an option to avoid complaining about untracked files in the
submodules
e.g. if option is not selected, entry about mod3 would not be printed at
all.
And of course it would be useful to modify the suggestions into
something like
# (use "git add <file>/<submodule>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
# (enter modules that have modified/untracked files to perform actions on them)
Thanks,
Sergio
Yes! My ideal behavior (if I am not asking too much) would be trying to
keep the status as little wordy as possible (1 line per submodule)
e.g. something like
# modified module (commit id): mod1
# modified module (modified files): mod2
# modified module (untracked files): mod3
# modified module (modified files, untracked files): mod4
# modified module (commit id, modified files, untracked files): mod5
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 ...
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