Re: [PATCH] git-prompt.sh: add submodule indicator
From: Stefan Beller <hidden>
Date: 2017-01-20 00:38:08
On Thu, Jan 19, 2017 at 4:07 PM, Benjamin Fuchs [off-list ref] 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 <redacted>
Thanks for making submodules better :) Relevant tangent, just posted today: https://public-inbox.org/git/20170119193023.26837-1-sbeller@google.com/T/#u
quoted hunk ↗ jump to hunk
--- 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