git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Benjamin Fuchs <email@benjaminfuchs.de>
To: Junio C Hamano <gitster@pobox.com>
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: Tue, 31 Jan 2017 01:10:15 +0100
Message-ID: <c872072a-4754-051d-81e7-1e2166560733@benjaminfuchs.de> (raw)
In-Reply-To: <xmqqr33krtww.fsf@gitster.mtv.corp.google.com>

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 <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.
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].


  reply index

Thread overview: 53+ 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
2017-01-31  0:10     ` Benjamin Fuchs [this message]
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-31 18:06   ` SZEDER Gábor
2017-01-30 20:44 ` [PATCH 3/4] git-prompt.sh: fix for submodule 'dirty' indicator Benjamin Fuchs
2017-01-30 20:44 ` [PATCH 4/4] git-prompt.sh: add tests for submodule indicator 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=c872072a-4754-051d-81e7-1e2166560733@benjaminfuchs.de \
    --to=email@benjaminfuchs.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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