From: Junio C Hamano <hidden> Date: 2016-06-15 22:54:51
Orgad Shaneh [off-list ref] writes:
That is not correct. git-config is ignored as well for commit.
What do you mean? As far as I can tell, if you have
[submodule "var"]
path = var
ignore = dirty
in $GIT_DIR/config, a work-tree-dirty submodule "var" is not
reported by "git status" and "git commit" without your patch, and
your patch does not seem to break that. The only difference your
patch makes is that if you had the above three-line block in
the .gitmodules file and not in $GIT_DIR/config, "git status"
ignored the dirtyness in the working tree, but "git commit" did
notice and report it.
What am I missing?
On Mon, Sep 24, 2012 at 9:06 PM, Junio C Hamano [off-list ref] wrote:
Orgad Shaneh [off-list ref] writes:
quoted
That is not correct. git-config is ignored as well for commit.
What do you mean? As far as I can tell, if you have
[submodule "var"]
path = var
ignore = dirty
in $GIT_DIR/config, a work-tree-dirty submodule "var" is not
reported by "git status" and "git commit" without your patch, and
your patch does not seem to break that. The only difference your
patch makes is that if you had the above three-line block in
the .gitmodules file and not in $GIT_DIR/config, "git status"
ignored the dirtyness in the working tree, but "git commit" did
notice and report it.
What am I missing?
I have:
[submodule "mod"]
url = [...]
ignore = dirty
in .git/config, and I removed the ignore part from .gitmodules to be even.
I made a change inside mod, git status doesn't report its dirtiness,
while git commit does.
git status:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: foo
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: .gitmodules
#
git commit:
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: foo
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
# (commit or discard the untracked or modified content in submodules)
#
# modified: .gitmodules
# modified: mod (modified content)
#
Now I get it! That's because I don't have submodule.mod.path!
config_name_for_path only gets initialized if path exists. Apparently
git submodule init doesn't configure 'path', so it stays
uninitialized.
- Orgad
On Mon, Sep 24, 2012 at 9:06 PM, Junio C Hamano [off-list ref] wrote:
quoted
Orgad Shaneh [off-list ref] writes:
quoted
That is not correct. git-config is ignored as well for commit.
What do you mean? As far as I can tell, if you have
[submodule "var"]
path = var
ignore = dirty
in $GIT_DIR/config, a work-tree-dirty submodule "var" is not
reported by "git status" and "git commit" without your patch, and
your patch does not seem to break that. The only difference your
patch makes is that if you had the above three-line block in
the .gitmodules file and not in $GIT_DIR/config, "git status"
ignored the dirtyness in the working tree, but "git commit" did
notice and report it.
What am I missing?
I have:
[submodule "mod"]
url = [...]
ignore = dirty
in .git/config, and I removed the ignore part from .gitmodules to be even.
I made a change inside mod, git status doesn't report its dirtiness,
while git commit does.
git status:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: foo
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: .gitmodules
#
git commit:
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: foo
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
# (commit or discard the untracked or modified content in submodules)
#
# modified: .gitmodules
# modified: mod (modified content)
#
Now I get it! That's because I don't have submodule.mod.path!
config_name_for_path only gets initialized if path exists. Apparently
git submodule init doesn't configure 'path', so it stays
uninitialized.
But submodule.mod.path should only be set in .gitmodules, not in
$GIT_DIR/config. Did you just remove the ignore setting from
.gitmodules or the path too?
On Mon, Sep 24, 2012 at 9:56 PM, Jens Lehmann [off-list ref] wrote:
Am 24.09.2012 21:16, schrieb Orgad Shaneh:
quoted
On Mon, Sep 24, 2012 at 9:06 PM, Junio C Hamano [off-list ref] wrote:
quoted
Orgad Shaneh [off-list ref] writes:
quoted
That is not correct. git-config is ignored as well for commit.
What do you mean? As far as I can tell, if you have
[submodule "var"]
path = var
ignore = dirty
in $GIT_DIR/config, a work-tree-dirty submodule "var" is not
reported by "git status" and "git commit" without your patch, and
your patch does not seem to break that. The only difference your
patch makes is that if you had the above three-line block in
the .gitmodules file and not in $GIT_DIR/config, "git status"
ignored the dirtyness in the working tree, but "git commit" did
notice and report it.
What am I missing?
I have:
[submodule "mod"]
url = [...]
ignore = dirty
in .git/config, and I removed the ignore part from .gitmodules to be even.
I made a change inside mod, git status doesn't report its dirtiness,
while git commit does.
git status:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: foo
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: .gitmodules
#
git commit:
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: foo
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
# (commit or discard the untracked or modified content in submodules)
#
# modified: .gitmodules
# modified: mod (modified content)
#
Now I get it! That's because I don't have submodule.mod.path!
config_name_for_path only gets initialized if path exists. Apparently
git submodule init doesn't configure 'path', so it stays
uninitialized.
But submodule.mod.path should only be set in .gitmodules, not in
$GIT_DIR/config. Did you just remove the ignore setting from
.gitmodules or the path too?
Just the ignore, and my patch of course.
If it is not set in $GIT_DIR/config, then config_name_for_path is not
initialized, and if it is not initialized, then
set_diffopt_flags_from_submodule_config does nothing
(handle_ignore_submodules_arg is not called). That is the main
problem.
- Orgad
On Mon, Sep 24, 2012 at 9:56 PM, Jens Lehmann [off-list ref] wrote:
quoted
Am 24.09.2012 21:16, schrieb Orgad Shaneh:
quoted
On Mon, Sep 24, 2012 at 9:06 PM, Junio C Hamano [off-list ref] wrote:
quoted
Orgad Shaneh [off-list ref] writes:
quoted
That is not correct. git-config is ignored as well for commit.
What do you mean? As far as I can tell, if you have
[submodule "var"]
path = var
ignore = dirty
in $GIT_DIR/config, a work-tree-dirty submodule "var" is not
reported by "git status" and "git commit" without your patch, and
your patch does not seem to break that. The only difference your
patch makes is that if you had the above three-line block in
the .gitmodules file and not in $GIT_DIR/config, "git status"
ignored the dirtyness in the working tree, but "git commit" did
notice and report it.
What am I missing?
I have:
[submodule "mod"]
url = [...]
ignore = dirty
in .git/config, and I removed the ignore part from .gitmodules to be even.
I made a change inside mod, git status doesn't report its dirtiness,
while git commit does.
git status:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: foo
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: .gitmodules
#
git commit:
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: foo
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
# (commit or discard the untracked or modified content in submodules)
#
# modified: .gitmodules
# modified: mod (modified content)
#
Now I get it! That's because I don't have submodule.mod.path!
config_name_for_path only gets initialized if path exists. Apparently
git submodule init doesn't configure 'path', so it stays
uninitialized.
But submodule.mod.path should only be set in .gitmodules, not in
$GIT_DIR/config. Did you just remove the ignore setting from
.gitmodules or the path too?
Just the ignore, and my patch of course.
If it is not set in $GIT_DIR/config, then config_name_for_path is not
initialized, and if it is not initialized, then
set_diffopt_flags_from_submodule_config does nothing
(handle_ignore_submodules_arg is not called). That is the main
problem.
But config_name_for_path can only be set via .gitmodules. It is set in
parse_submodule_config_option() called by submodule_config() which is
called from gitmodules_config() ... but only if .gitmodules doesn't
have a merge conflict.
So either your .gitmodules has a merge conflict or the logic setting
gitmodules_is_unmerged in gitmodules_config() is buggy.