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
next prev parent 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).