Re: [PATCH 3/3] git submodule update should give notice when run without init beforehand
On 18/09/13 22:22, Tay Ray Chuan wrote: > Hi Chris, > > I think you mentioned usability issues with git-submodule before on > the git mailing list, so I thought you might be interested in taking a > look at this patch. It's attached below, you can also view it at > > > http://thread.gmane.org/gmane.comp.version-control.git/1379266703-29808-3-git-send-email-rcta...@gmail.com > > I would be interested in hearing what you think. > The case I had was that an un-init'd submodule was still a directory on the file system so 'cd submodule' would work and it could go unnoticed that we hadn't entered the submodule. Your change might have helped somewhat but the bigger problem was that the work-tree representation of an un-init'd submodule is a directory. There was never any thought to actually run 'git submodule update' because the developer in question thought they already had. I think Jens' autoinit may be the right direction. It certainly would be what we'd want for our use-case at $dayjob. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] git submodule update should give notice when run without init beforehand
Am 18.09.2013 12:12, schrieb Tay Ray Chuan: > On Tue, Sep 17, 2013 at 1:06 AM, Jens Lehmann wrote: > > Thanks Jens for having a look! > >> Am 15.09.2013 19:38, schrieb Tay Ray Chuan: >>> When 'update' is run with no path in a repository with uninitialized >>> submodules, the program terminates with no output, and zero status code. >>> Be more helpful to users by mentioning this. >> >> [snip] it would be rather nasty to error out on every submodule >> update. > > Just to be sure we're on the right page, with this patch, the 'update' > command still exits with status code zero (non-error), so this patch > doesn't make it error out. Ok, sorry for the confusion. But I still think we should not change the default to print these messages, but make it an opt-in. And the commit message (and maybe the documentation too) should talk about the use cases where this makes sense. >> After the 'autoinit' configuration (which lets upstream hint that >> certain submodules should be initialized on clone) has materialzed we >> might want to enable this error for these specific submodules. > > That's cool, I'm looking forward to this. Could you point me to > somewhere detailing this? Not yet. I'm still wrestling with the autoupdate series, which is the logical step before autoinit. autoupdate enables to configure that initialized submodules are updated on checkout, reset, merge and all the other work tree manipulating commands. autoinit then also clones the repos of submodules into .git/modules and inits them in .git/config, so that autoupdate will automagically populate them. Unfortunately autoupdate is a rather largish series touching lots of commands and needing tons of tests ... > But in the meantime, on top of the advice.* config, how about having a > submodule..ignoreUninit config to disable the message on a > per-submodule basis? I'd not add such an option unless users request it because it helps their not-so-terribly-specific use case. >> But in >> any case the error message should contain a hint on how you can get >> rid of the error in case you know what you are doing ;-). > > The message does mention that you can throw in an --init to fix the > problem. This "hint" is similar to what git-submodule prints when a > is passed (see region at line 807). But for a lot of users that isn't a solution, as they never want to init it, they want to ignore it. And if you explicitly ask to update a special submodule, that message is ok. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] git submodule update should give notice when run without init beforehand
On Tue, Sep 17, 2013 at 1:06 AM, Jens Lehmann wrote: Thanks Jens for having a look! > Am 15.09.2013 19:38, schrieb Tay Ray Chuan: >> When 'update' is run with no path in a repository with uninitialized >> submodules, the program terminates with no output, and zero status code. >> Be more helpful to users by mentioning this. > > [snip] it would be rather nasty to error out on every submodule > update. Just to be sure we're on the right page, with this patch, the 'update' command still exits with status code zero (non-error), so this patch doesn't make it error out. > After the 'autoinit' configuration (which lets upstream hint that > certain submodules should be initialized on clone) has materialzed we > might want to enable this error for these specific submodules. That's cool, I'm looking forward to this. Could you point me to somewhere detailing this? But in the meantime, on top of the advice.* config, how about having a submodule..ignoreUninit config to disable the message on a per-submodule basis? > But in > any case the error message should contain a hint on how you can get > rid of the error in case you know what you are doing ;-). The message does mention that you can throw in an --init to fix the problem. This "hint" is similar to what git-submodule prints when a is passed (see region at line 807). -- Cheers, Ray Chuan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] git submodule update should give notice when run without init beforehand
Am 15.09.2013 19:38, schrieb Tay Ray Chuan:
> When 'update' is run with no path in a repository with uninitialized
> submodules, the program terminates with no output, and zero status code.
> Be more helpful to users by mentioning this.
Hmm, this patch is changing the default behavior, right? I assume the
motivation for this patch is to help people who tend to forget to init
submodules they need to have checked out, which is a good idea. But I
think this should not be enabled by default, as in a lot of use cases
one or more uninitialized submodules are present on purpose. In those
use cases it would be rather nasty to error out on every submodule
update.
After the 'autoinit' configuration (which lets upstream hint that
certain submodules should be initialized on clone) has materialzed we
might want to enable this error for these specific submodules. But in
any case the error message should contain a hint on how you can get
rid of the error in case you know what you are doing ;-).
> This may be controlled by an advice.* option.
>
> Signed-off-by: Tay Ray Chuan
> ---
> Documentation/config.txt| 5 +
> git-submodule.sh| 16 ++--
> t/t7406-submodule-update.sh | 5 -
> 3 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index ec57a15..79313f9 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -202,6 +202,11 @@ advice.*::
> rmHints::
> In case of failure in the output of linkgit:git-rm[1],
> show directions on how to proceed from the current state.
> + submoduleUpdateUninit::
> + When linkgit:git-submodule[1] `update` is run with no `path`
> + arguments in a repository with uninitialized submodules,
> + mention that uninitalized submodules are indeed present, and
> + that they may be initialized with the `--init` option.
> --
>
> core.fileMode::
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 2979197..56f3dc2 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -777,6 +777,7 @@ cmd_update()
> cloned_modules=
> module_list "$@" | {
> err=
> + has_uninit=
> while read mode sha1 stage sm_path
> do
> die_if_unmatched "$mode"
> @@ -807,9 +808,13 @@ cmd_update()
> then
> # Only mention uninitialized submodules when its
> # path have been specified
> - test "$#" != "0" &&
> - say "$(eval_gettext "Submodule path '\$displaypath' not
> initialized
> + if test "$#" != "0"
> + then
> + say "$(eval_gettext "Submodule path
> '\$displaypath' not initialized
> Maybe you want to use 'update --init'?")"
> + else
> + has_uninit=1
> + fi
> continue
> fi
>
> @@ -940,6 +945,13 @@ Maybe you want to use 'update --init'?")"
> IFS=$OIFS
> exit 1
> fi
> +
> + if test -n "$has_uninit" \
> + -a "$(git config --bool --get advice.submoduleUpdateUninit)" !=
> "false"
> + then
> + say "$(eval_gettext "Uninitialized submodules were detected;
> +Maybe you want to use 'update --init'?")"
> + fi
> }
> }
>
> diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
> index 00475eb..8dbe410 100755
> --- a/t/t7406-submodule-update.sh
> +++ b/t/t7406-submodule-update.sh
> @@ -76,8 +76,11 @@ test_expect_success 'submodule update warns without
> init beforehand' '
> )
> '
>
> -test_expect_success 'submodule update is silent without init beforehand' '
> +test_expect_success 'submodule update warns without init beforehand' '
> (cd super2 &&
> + test_must_fail git config --get advice.submoduleUpdateUninit &&
> + test -n "$(git submodule update)" &&
> + git config advice.submoduleUpdateUninit false &&
>test -z "$(git submodule update)"
> )
> '
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] git submodule update should give notice when run without init beforehand
When 'update' is run with no path in a repository with uninitialized
submodules, the program terminates with no output, and zero status code.
Be more helpful to users by mentioning this.
This may be controlled by an advice.* option.
Signed-off-by: Tay Ray Chuan
---
Documentation/config.txt| 5 +
git-submodule.sh| 16 ++--
t/t7406-submodule-update.sh | 5 -
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec57a15..79313f9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -202,6 +202,11 @@ advice.*::
rmHints::
In case of failure in the output of linkgit:git-rm[1],
show directions on how to proceed from the current state.
+ submoduleUpdateUninit::
+ When linkgit:git-submodule[1] `update` is run with no `path`
+ arguments in a repository with uninitialized submodules,
+ mention that uninitalized submodules are indeed present, and
+ that they may be initialized with the `--init` option.
--
core.fileMode::
diff --git a/git-submodule.sh b/git-submodule.sh
index 2979197..56f3dc2 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -777,6 +777,7 @@ cmd_update()
cloned_modules=
module_list "$@" | {
err=
+ has_uninit=
while read mode sha1 stage sm_path
do
die_if_unmatched "$mode"
@@ -807,9 +808,13 @@ cmd_update()
then
# Only mention uninitialized submodules when its
# path have been specified
- test "$#" != "0" &&
- say "$(eval_gettext "Submodule path '\$displaypath' not
initialized
+ if test "$#" != "0"
+ then
+ say "$(eval_gettext "Submodule path
'\$displaypath' not initialized
Maybe you want to use 'update --init'?")"
+ else
+ has_uninit=1
+ fi
continue
fi
@@ -940,6 +945,13 @@ Maybe you want to use 'update --init'?")"
IFS=$OIFS
exit 1
fi
+
+ if test -n "$has_uninit" \
+ -a "$(git config --bool --get advice.submoduleUpdateUninit)" !=
"false"
+ then
+ say "$(eval_gettext "Uninitialized submodules were detected;
+Maybe you want to use 'update --init'?")"
+ fi
}
}
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 00475eb..8dbe410 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -76,8 +76,11 @@ test_expect_success 'submodule update warns without
init beforehand' '
)
'
-test_expect_success 'submodule update is silent without init beforehand' '
+test_expect_success 'submodule update warns without init beforehand' '
(cd super2 &&
+test_must_fail git config --get advice.submoduleUpdateUninit &&
+test -n "$(git submodule update)" &&
+git config advice.submoduleUpdateUninit false &&
test -z "$(git submodule update)"
)
'
--
1.8.4.rc4.527.g303b16c
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
