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

From: Sibo Dong <[email protected]>

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

---
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(+)

index 16260bab73..5116016d39 100644
@@ -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

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

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 <[email protected]>

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.