From: Benjamin Fuchs Date: Tue, 31 Jan 2017 00:10:15 GMT Subject: Re: [PATCH 1/4] git-prompt.sh: add submodule indicator Message-ID: In-Reply-To: Hi Junio, thanks for your reply. Some of your suggestions are covered by my rework in Patch [2/4]. In [2/4] I got rid of the loop by feedback of Gábor. Sorry if my patch wasn't well formed. On 31.01.2017 00:48, Junio C Hamano wrote: > Benjamin Fuchs 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. A submodule can be anywhere in your parent git repository. And while walking through the parent repository it is sometime a good reminder to know when to just entered a submodule. Because now all git command will work on the submodule. I guess this indicator is a good way to show that. And with patch [2/4] (and fixed it with [3/4]) I also introduced the "dirty" indicator for the submodule, which can show you, that your current checked out state in the submodule is not the one committed to the parent. > >> 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? Reworked in Patch [2/4] >> +{ >> + 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). Reworked in Patch [2/4] > >> + 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. Reworked in Patch [2/4].