Benjamin Fuchs <email@xxxxxxxxxxxxxxxx> writes: > I expirienced that working with submodules can be confusing. This indicator > will make you notice very easy when you switch into a submodule. I am not quite sure what the above wants to say. If you work on two projects, A and B, then having something that quickly reminds you which one you are in is beneficial and people often do so by having the current directory name in the prompt. The log message needs to explain why working on a submodule C of a project A is any more special, i.e. why are the existing ways the users are using to remind them between A and B cannot be used for C. > 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 () It seems like this function is checking if you are "IN" submodule, not "IS" submodule. A misnamed function? > +{ > + 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")" This does not give "module_name" in the sense the word is used in the submodule subsystem. If this variable is useful, call that with "path" in its name (I do not think it alone is useful at all). > + parent_git="$(cd "$git_dir/.." && git rev-parse --show-toplevel 2> /dev/null)" > + if [[ -n $parent_git ]]; then > + # List all the submodule paths for the parent repo > + while read path > + do > + if [[ "$path" != "$module_name" ]]; then continue; fi > + if [[ -d "$git_dir/../$path" ]]; then return 0; fi > + done < <(cd $parent_git && git submodule --quiet foreach 'echo $path' 2> /dev/null) Instead of doing this "loop over submodules and just get true or false", it may make a lot more sense to find the module name and report that. That would allow you to have the actual submodule name, not a generic "sub:" which does not help the users to tell which one of 47 submodules they have in their top-level project they are currently in. If your projects are layed out like so /home/bf/projects/A/ /home/bf/projects/A/lib/B/ -- submodule /home/bf/projects/A/Doc/ -- another submodule /home/bf/projects/A/Doc/technical -- a subdirectory of Doc submodule and you are in /home/bf/projects/A/Doc/technical/ subdirectory, your $git_dir variable (which is grossly misnamed, too; call it "top" perhaps?) would be "/home/bf/projects/A/Doc" and then your $parent_git variable (again, that is misnamed; call it "parent_top"?) would be "/home/bf/projects/A". The submodule path to the submodule you are currently in is "Doc" (you learn it as the difference between these two). You can ask the top-level project the name of the submodule that is currently at "Doc" with "submodule--helper name". Unless the project has moved it since it first added the submodule, the module name may also be "Doc", but if it were moved, it may be different. And that "module name" is a more useful thing than a hardcoded string "sub:" to use in the prompt, I would think.