Re: [PATCH 0/3] Fix $((...)) coding style

2016-02-04 Thread Junio C Hamano
Junio C Hamano writes: > One thing I was wondering about the $(( ... )) syntax while reading > this thread was about the SP around the expression, i.e. > > var=$(( $term1 * $term2 + $term3 )) > > vs > > var=$(($term1 * $term2 + $term3)) > > I personally do not have strong preference b

Re: [PATCH 0/3] Fix $((...)) coding style

2016-02-04 Thread Junio C Hamano
John Keeping writes: > 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. > >"On

Re: [PATCH 0/3] Fix $((...)) coding style

2016-02-04 Thread John Keeping
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 change

Re: [PATCH 0/3] Fix $((...)) coding style

2016-02-04 Thread Johannes Schindelin
Hi John, 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 thin

Re: [PATCH 0/3] Fix $((...)) coding style

2016-02-04 Thread John Keeping
On Thu, Feb 04, 2016 at 02:13:47PM +0100, Johannes Schindelin wrote: > On Thu, 4 Feb 2016, John Keeping wrote: > > > Although I don't think the historic context is useful in deciding which > > direction to go in the future. > > Being a maintainer, I find that argument particularly hard to defend.

Re: [PATCH 0/3] Fix $((...)) coding style

2016-02-04 Thread Johannes Schindelin
Hi John, On Thu, 4 Feb 2016, John Keeping wrote: > Although I don't think the historic context is useful in deciding which > direction to go in the future. Being a maintainer, I find that argument particularly hard to defend. But sure, you go ahead and prepare a patch series that turns everythi

Re: [PATCH 0/3] Fix $((...)) coding style

2016-02-04 Thread John Keeping
On Thu, Feb 04, 2016 at 01:38:51PM +0100, Johannes Schindelin wrote: > On Thu, 4 Feb 2016, John Keeping wrote: > > > Using spaces around operators also matches our C coding style. > > Well, by that reasoning you should go the whole nine yards and write > > lineno = $(( $lineno + 1 )) > >

Re: [PATCH 0/3] Fix $((...)) coding style

2016-02-04 Thread Johannes Schindelin
Hi John, On Thu, 4 Feb 2016, John Keeping wrote: > Using spaces around operators also matches our C coding style. Well, by that reasoning you should go the whole nine yards and write lineno = $(( $lineno + 1 )) Except you can't. Because shell code is inherently not like C code. What I

Re: [PATCH 0/3] Fix $((...)) coding style

2016-02-04 Thread John Keeping
On Thu, Feb 04, 2016 at 01:01:39PM +0100, Johannes Schindelin wrote: > I noticed through a nearby patch series that was submitted by Elia that > some of the $((...)) expressions introduced in scripts that I introduced > to Git's source code did not match the existing code's convention: > previously

[PATCH 0/3] Fix $((...)) coding style

2016-02-04 Thread Johannes Schindelin
I noticed through a nearby patch series that was submitted by Elia that some of the $((...)) expressions introduced in scripts that I introduced to Git's source code did not match the existing code's convention: previously these expressions did not contain any spaces, now *some* do. This patch ser