git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Keeping <john@keeping.me.uk>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Elia Pinto <gitter.spiros@gmail.com>
Subject: Re: [PATCH 0/3] Fix $((...)) coding style
Date: Thu, 4 Feb 2016 15:53:16 +0000	[thread overview]
Message-ID: <20160204155316.GI29880@serenity.lan> (raw)
In-Reply-To: <alpine.DEB.2.20.1602041619430.2964@virtualbox>

On Thu, Feb 04, 2016 at 04:27:49PM +0100, Johannes Schindelin wrote:
> On Thu, 4 Feb 2016, John Keeping wrote:
> 
> > On Thu, Feb 04, 2016 at 02:13:47PM +0100, Johannes Schindelin wrote:
> > > Whatever the outcome, the inconsistency must be fixed.
> > 
> > I disagree.  Unless there are other changes in the same area, the noise
> > isn't worth it.
> > 
> > However, I do think we need to agree on a policy so that new code can be
> > consistent.  This should then be documented in CodingGuidelines.
> 
> If you want to enforce it in the future, how can you possibly be against
> fixing the inconsistency in the existing code? Sorry, I am really unable
> to understand this.

I avoided quoting CodingGuidelines in my previous message, but it says:

 - Fixing style violations while working on a real change as a
   preparatory clean-up step is good, but otherwise avoid useless code
   churn for the sake of conforming to the style.

   "Once it _is_ in the tree, it's not really worth the patch noise to
   go and fix it up."
   Cf. http://article.gmane.org/gmane.linux.kernel/943020

> Also, we *did* document the policy in the CodingGuidelines:
> 
> 	As for more concrete guidelines, just imitate the existing code
> 
> So. There you are. By that token, my patch series was the correct thing to
> do because the first arithmetic expression introduced into a shell script
> in Git's source code had no spaces.

This is the first point I made.  To take one example, in
git-filter-branch.sh there are five occurrences of the sequence "$((";
your patch changes four of them to remove spaces.  If we standardise on
having spaces only one needs to change:

$ git grep -F '$((' origin/master -- git-filter-branch.sh
origin/master:git-filter-branch.sh:             elapsed=$(($now - $start_timestamp))
origin/master:git-filter-branch.sh:             remaining=$(( ($commits - $count) * $elapsed / $count ))
origin/master:git-filter-branch.sh:                     next_sample_at=$(( ($elapsed + 1) * $count / $elapsed ))
origin/master:git-filter-branch.sh:                     next_sample_at=$(($next_sample_at + 1))
origin/master:git-filter-branch.sh:     git_filter_branch__commit_count=$(($git_filter_branch__commit_count+1))

I chose git-filter-branch.sh simply because it was touched by this patch
set but it is not an outlier in this regard.  Some crude statistics
across all of git.git:

# No space after plus
$ git grep -F '$((' | grep '\+[\$0-9]' | wc -l
34

# With space after plus
$ git grep -F '$((' | grep '\+ [\$0-9]' | wc -l
96

  reply	other threads:[~2016-02-04 15:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-04 12:01 [PATCH 0/3] Fix $((...)) coding style Johannes Schindelin
2016-02-04 12:02 ` [PATCH 1/3] filter-branch: fix style of $((...) construct Johannes Schindelin
2016-02-04 12:02 ` [PATCH 2/3] rebase--interactive: adjust the coding style of $((...)) Johannes Schindelin
2016-02-04 12:03 ` [PATCH 3/3] rebase --merge: adjust $((...)) coding style Johannes Schindelin
2016-02-04 12:14 ` [PATCH 0/3] Fix " John Keeping
2016-02-04 12:38   ` Johannes Schindelin
2016-02-04 13:01     ` John Keeping
2016-02-04 13:13       ` Johannes Schindelin
2016-02-04 14:06         ` John Keeping
2016-02-04 15:27           ` Johannes Schindelin
2016-02-04 15:53             ` John Keeping [this message]
2016-02-04 19:43               ` Junio C Hamano
2016-02-04 19:43               ` Junio C Hamano

Reply instructions:

You may reply publicly 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

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

  git send-email \
    --in-reply-to=20160204155316.GI29880@serenity.lan \
    --to=john@keeping.me.uk \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=gitter.spiros@gmail.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).