Re: [PATCH v2] style(git-gui): Fix mixed tabs & spaces; Prefer tabs.
- From
Pratyush Yadav <me@yadavpratyush.com>
- Date
- Sep 9, 2020, 04:51 UTC
- Message-ID
- <20200909045108.j5ovnbk35cmghgcz@yadavpratyush.com>
- In-Reply-To
- <20200822222431.35027-1-serg.partizan@gmail.com>
Hi Serg,
Thanks for the patch.
> Subject: [PATCH v2] style(git-gui): Fix mixed tabs & spaces; Prefer tabs.
s/style(git-gui)/git-gui/
On 23/08/20 01:24AM, Serg Tereshchenko wrote:
> Here is cleaned up version of the patch.
A line like this should not be a part of the actual commit message. It is some extra commentary for the reviewers. The way you have submitted this patch, this line would end up in the commit message. The usual way of doing something like this is to use "scissors".
You can add this line:
--- 8< ---
This "scissors" line can tell git-am (when the option --scissors) to ignore everything above it. That makes my job a little bit easier when applying your patch :-)
Show 7 quoted lines
> Spaces replaced with tabs when possible. In some cases just replacing > spaces with tabs would break readability, so it was left as it is. > > Signed-off-by: Serg Tereshchenko <serg.partizan@gmail.com> > --- > git-gui.sh | 154 ++++++++++++++++++++++++++--------------------------- > 1 file changed, 77 insertions(+), 77 deletions(-)
Most of the changes here look good to me. One comment below.
Show 115 quoted lines
>
> diff --git a/git-gui.sh b/git-gui.sh
> index 49bd86e..847c3c9 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -947,15 +947,15 @@ if {![regsub {^git version } $_git_version {} _git_version]} {
> }
>
> proc get_trimmed_version {s} {
> - set r {}
> - foreach x [split $s -._] {
> - if {[string is integer -strict $x]} {
> - lappend r $x
> - } else {
> - break
> - }
> - }
> - return [join $r .]
> + set r {}
> + foreach x [split $s -._] {
> + if {[string is integer -strict $x]} {
> + lappend r $x
> + } else {
> + break
> + }
> + }
> + return [join $r .]
> }
> set _real_git_version $_git_version
> set _git_version [get_trimmed_version $_git_version]
> @@ -967,7 +967,7 @@ if {![regexp {^[1-9]+(\.[0-9]+)+$} $_git_version]} {
> -type yesno \
> -default no \
> -title "[appname]: warning" \
> - -message [mc "Git version cannot be determined.
> + -message [mc "Git version cannot be determined.
>
> %s claims it is version '%s'.
>
> @@ -1181,44 +1181,44 @@ enable_option transport
> disable_option bare
>
> switch -- $subcommand {
> -browser -
> -blame {
> - enable_option bare
> -
> - disable_option multicommit
> - disable_option branch
> - disable_option transport
> -}
> -citool {
> - enable_option singlecommit
> - enable_option retcode
> -
> - disable_option multicommit
> - disable_option branch
> - disable_option transport
> + browser -
> + blame {
> + enable_option bare
> +
> + disable_option multicommit
> + disable_option branch
> + disable_option transport
> + }
> + citool {
> + enable_option singlecommit
> + enable_option retcode
> +
> + disable_option multicommit
> + disable_option branch
> + disable_option transport
> +
> + while {[llength $argv] > 0} {
> + set a [lindex $argv 0]
> + switch -- $a {
> + --amend {
> + enable_option initialamend
> + }
> + --nocommit {
> + enable_option nocommit
> + enable_option nocommitmsg
> + }
> + --commitmsg {
> + disable_option nocommitmsg
> + }
> + default {
> + break
> + }
> + }
>
> - while {[llength $argv] > 0} {
> - set a [lindex $argv 0]
> - switch -- $a {
> - --amend {
> - enable_option initialamend
> - }
> - --nocommit {
> - enable_option nocommit
> - enable_option nocommitmsg
> + set argv [lrange $argv 1 end]
> }
> - --commitmsg {
> - disable_option nocommitmsg
> - }
> - default {
> - break
> - }
> - }
> -
> - set argv [lrange $argv 1 end]
> }
> }
> -}I'm not on board with this entire hunk. In many C projects (like Linux, Git, etc) the "switch" and the "case" are on the same indent level. I can see instances of this in almost every switch-case block in git-gui.sh as well. We should stick to the local convention here and drop this hunk.
I can make these changes locally and merge them so no need to re-roll... unless you have any counter points that is.
-- Regards, Pratyush Yadav