[PATCH] git-prompt.sh: make `option` a local variable

[PATCH] git-prompt.sh: make `option` a local variable

[Sibo Dong via GitGitGadget]

From: Sibo Dong <sibo.dong@outlook.com>

Other variables like `key` and `value` are local to this completion
script, so I think the same should be done with `option`.

Signed-off-by: Sibo Dong <sibo.dong@outlook.com>
---
    git-prompt.sh: make option a local variable
    
    This is very trivial, but variables like key and value are local to 
    git-prompt.sh, so I think the same should be done with option. I have 
    GIT_PS1_SHOW_UPSTREAM set to verbose in my ~/.bashrc, so option gets set
    to verbose in my Bash session whenever I change directories to a local
    repository with a remote.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-775%2Fdongsibo%2Ffix-git-prompt-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-775/dongsibo/fix-git-prompt-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/775

 contrib/completion/git-prompt.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 16260bab73..5116016d39 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -137,6 +137,7 @@ __git_ps1_show_upstream ()
 	done <<< "$output"
 
 	# parse configuration values
+	local option
 	for option in ${GIT_PS1_SHOWUPSTREAM}; do
 		case "$option" in
 		git|svn) upstream="$option" ;;

base-commit: 898f80736c75878acc02dc55672317fcc0e0a5a6
-- 
gitgitgadget

Re: [PATCH] git-prompt.sh: make `option` a local variable

[Junio C Hamano]

"Sibo Dong via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Sibo Dong <sibo.dong@outlook.com>
>
> Other variables like `key` and `value` are local to this completion
> script, so I think the same should be done with `option`.
>
> Signed-off-by: Sibo Dong <sibo.dong@outlook.com>
> ---
>     git-prompt.sh: make option a local variable
>     
>     This is very trivial, but variables like key and value are local to 
>     git-prompt.sh, so I think the same should be done with option.

That explains why we might consider localizing option; another thing
to consider is if it is safe to just blindly localize it.

Here is how I would explain and justify the change, if I were
writing it:

    git-prompt.sh: localize `option` in __git_ps1_show_upstream

    The variable 'option' is used in __git_ps1_show_upstream()
    without being localized.

    This clobbers the variable the user may be using for other
    purposes, which is bad.  Luckily, $option is not used to carry
    information around in the script as a global variable.  The use
    of it in this script has very limited scope (namely, only inside
    this function), so just declare that it is "local".


following the usual pattern:

 - start with the observation on the codebase before your change,
 - explain what the problem is with the current state,
 - outline the solution and explain why it is the right thing to do, and
 - order the codebase to "be like so".


> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> index 16260bab73..5116016d39 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -137,6 +137,7 @@ __git_ps1_show_upstream ()
>  	done <<< "$output"
>  
>  	# parse configuration values
> +	local option
>  	for option in ${GIT_PS1_SHOWUPSTREAM}; do
>  		case "$option" in
>  		git|svn) upstream="$option" ;;

Looks OK to me.

Re: [PATCH] git-prompt.sh: make `option` a local variable

[Sibo Dong]

Thank you for the feedback Junio; I'm a bit new to contributing. Since
you've justified this change much better than I have, is there any need
for further action on my part?
-- 
Sibo Dong <sibo.dong@mail.utoronto.ca>

Re: [PATCH] git-prompt.sh: make `option` a local variable

[Junio C Hamano]

Sibo Dong <sibo.dong@mail.utoronto.ca> writes:

> Thank you for the feedback Junio; I'm a bit new to contributing. Since
> you've justified this change much better than I have, is there any need
> for further action on my part?

The reviews by others are offered and taken as input to improve the
patch(es), but they are merely sugestions.  It is up to the original
contributors to either disagree and not take them with explanation,
or agree with and take them to improve their patch(es) before
sending the next iteration.

So, at least you'd need to say if you agree with the suggested
change and to what degree.  Since you've done so, I can save one
roundtrip by rewriting the proposed commit log message myself while
queuing your patch ;-)

Thanks.