git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Benjamin Fuchs <email@benjaminfuchs.de>
Cc: git@vger.kernel.org, szeder.dev@gmail.com, sbeller@google.com,
	sandals@crustytoothpaste.net, ville.skytta@iki.fi
Subject: Re: [PATCH 1/4] git-prompt.sh: add submodule indicator
Date: Mon, 30 Jan 2017 15:48:31 -0800
Message-ID: <xmqqr33krtww.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <1485809065-11978-2-git-send-email-email@benjaminfuchs.de>

Benjamin Fuchs <email@benjaminfuchs.de> 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.

  reply index

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-30 20:44 [PATCH 0/4] git-prompt.sh: Full patch for " Benjamin Fuchs
2017-01-30 20:44 ` [PATCH 1/4] git-prompt.sh: add " Benjamin Fuchs
2017-01-30 23:48   ` Junio C Hamano [this message]
2017-01-31  0:10     ` Benjamin Fuchs
2017-01-31  3:11       ` Junio C Hamano
2017-02-06  4:23         ` Stefan Beller
2017-02-06  5:55           ` Jacob Keller
2017-02-06 10:13             ` Stefan Beller
2017-01-30 20:44 ` [PATCH 2/4] git-prompt.sh: rework of " Benjamin Fuchs
2017-01-30 20:44 ` [PATCH 4/4] git-prompt.sh: add tests for " Benjamin Fuchs
2017-01-31 18:32   ` SZEDER Gábor
2017-01-31 22:06     ` Junio C Hamano
2017-01-31 22:12       ` Stefan Beller
2017-03-07  3:45         ` [RFC PATCH] rev-parse: add --show-superproject-working-tree Stefan Beller
2017-03-07  5:13           ` Junio C Hamano
2017-03-07  7:16             ` Junio C Hamano
2017-03-07  7:23               ` Junio C Hamano
2017-03-07 18:44           ` Junio C Hamano
2017-03-07 20:40             ` Stefan Beller
2017-03-07 22:49               ` Junio C Hamano
2017-03-08  0:56                 ` [PATCHv2] " Stefan Beller
2017-03-08  1:30                   ` Junio C Hamano
2017-03-08  6:01                   ` Junio C Hamano
2017-03-08 19:20                     ` [PATCHv3] " Stefan Beller
2017-03-08 22:28                       ` Junio C Hamano
2017-03-08 23:07                         ` [PATCHv4] " Stefan Beller
2017-03-08 23:51                           ` Junio C Hamano
2017-03-17 22:28                           ` Jonathan Nieder
2017-03-17 22:51                             ` [PATCH] Documentation/git-worktree: use working tree for trees on the file system Stefan Beller
2017-03-17 22:55                               ` Jonathan Nieder
2017-03-17 23:04                                 ` Stefan Beller
2017-03-18 17:24                                   ` Junio C Hamano
2017-03-18  1:47                                 ` Junio C Hamano
2017-03-18  1:36                               ` Junio C Hamano
2017-03-20 17:29                                 ` Stefan Beller
2017-03-20 18:12                                   ` Junio C Hamano
2017-03-20 18:50                                     ` Jonathan Nieder
2017-03-20 19:22                                       ` [PATCH 0/2] use "working trees" instead of "worktree" in our API Stefan Beller
2017-03-20 19:22                                         ` [PATCH 1/2] git.c: introduce --working-tree superseding --work-tree Stefan Beller
2017-03-20 19:58                                           ` Jonathan Nieder
2017-03-20 19:22                                         ` [PATCH 2/2] revparse: introduce --is-inside-working-tree Stefan Beller
2017-03-20 20:00                                           ` Jonathan Nieder
2017-03-20 19:37                                         ` [PATCH 0/2] use "working trees" instead of "worktree" in our API Junio C Hamano
2017-03-21 10:37                                       ` [PATCH] Documentation/git-worktree: use working tree for trees on the file system Duy Nguyen
2017-03-21 15:48                                         ` Junio C Hamano
2017-03-23 17:06                                           ` Michael J Gruber
2017-03-23 17:55                                             ` Junio C Hamano
2017-03-25 12:07                                               ` Duy Nguyen
2017-04-07 13:59                                                 ` Michael J Gruber
2017-04-07 16:14                                                   ` Jacob Keller
2017-03-25 12:05                                           ` Duy Nguyen

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqr33krtww.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=email@benjaminfuchs.de \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    --cc=sbeller@google.com \
    --cc=szeder.dev@gmail.com \
    --cc=ville.skytta@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox