On Thu, Jan 19, 2017 at 4:07 PM, Benjamin Fuchs <email@xxxxxxxxxxxxxxxx> wrote: > I expirienced that working with submodules can be confusing. This indicator > will make you notice very easy when you switch into a submodule. > The new prompt will look like this: (sub:master) > Adding a new optional env variable for the new feature. > > Signed-off-by: Benjamin Fuchs <email@xxxxxxxxxxxxxxxx> Thanks for making submodules better :) Relevant tangent, just posted today: https://public-inbox.org/git/20170119193023.26837-1-sbeller@xxxxxxxxxx/T/#u > --- > contrib/completion/git-prompt.sh | 37 ++++++++++++++++++++++++++++++++++++- > 1 file changed, 36 insertions(+), 1 deletion(-) > > diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh > index 97eacd7..4c82e7f 100644 > --- a/contrib/completion/git-prompt.sh > +++ b/contrib/completion/git-prompt.sh > @@ -93,6 +93,10 @@ > # directory is set up to be ignored by git, then set > # GIT_PS1_HIDE_IF_PWD_IGNORED to a nonempty value. Override this on the > # repository level by setting bash.hideIfPwdIgnored to "false". > +# > +# If you would like __git_ps1 to indicate that you are in a submodule, > +# set GIT_PS1_SHOWSUBMODULE. In this case a "sub:" will be added before > +# the branch name. > > # check whether printf supports -v > __git_printf_supports_v= > @@ -284,6 +288,32 @@ __git_eread () > test -r "$f" && read "$@" <"$f" > } > > +# __git_is_submodule > +# Based on: > +# http://stackoverflow.com/questions/7359204/git-command-line-know-if-in-submodule > +__git_is_submodule () > +{ > + local git_dir parent_git module_name path > + # Find the root of this git repo, then check if its parent dir is also a repo > + git_dir="$(git rev-parse --show-toplevel)" > + module_name="$(basename "$git_dir")" > + parent_git="$(cd "$git_dir/.." && git rev-parse --show-toplevel 2> /dev/null)" I wonder if we want to have better plumbing commands for submodules here as well: Here we only check if we have an embedded git repository, which may not be a submodule. It could be a standalone repo that just happens to be inside another. It could be a fake submodule [1], though I think the last time I brought these up, the upstream Git community considered these fake submodules are bug not worth fixing. And this doesn't cover the case that I addressed in the RFC-ish patch above: $ git submodule deinit --all $ cd <submodule> && git status # in an ideal world this tells you: # "You are in an un-populated submodule. To change the submodule state..." So I guess this is a good first approximation that actually gets most of the cases right, thereby helping a lot of people. But I wonder about these cornercases as well? [1] debuggable.com/posts/git-fake-submodules:4b563ee4-f3cc-4061-967e-0e48cbdd56cb Thanks, Stefan