All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Lattarini <stefano.lattarini@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] build: don't duplicate substitution of make variables
Date: Tue, 11 Sep 2012 22:17:55 +0200	[thread overview]
Message-ID: <504F9C73.1040409@gmail.com> (raw)
In-Reply-To: <7vd31sgww4.fsf@alter.siamese.dyndns.org>

On 09/11/2012 09:52 PM, Junio C Hamano wrote:
> Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> 
>> On 09/11/2012 07:27 PM, Junio C Hamano wrote:
>>
>>> These two hunks suggest that you may be favoring spaces, but other
>>> places you seem to use tabs, so...
>>>
>> I can convert the new tabs to spaces if you prefer (that would have been
>> my preference too, but thought trying to follow the "Git preferences"
>> was more important).  No big deal either way for me.
> 
> If this were other parts of the system, my preference would be to
> use tabs, but because I do not help very much in the autoconf part
> myself, I do not have a particular preference.  If it is more common
> to indent the configure.ac script with spaces,
>
There is no general standard about it that I know of; it's just that
GNU projects tend to prefer space-based indentation over tab-based one,
and since I mostly touch configure.ac files from GNU projects, I've
picked up the habit.

> that would be more
> familiar to the folks who work on it, and I do not have much against
> choosing and sticking to space indented configure.ac file if that is
> the policy.
> 
Then I might send a patch that normalize indentation in configure.ac
to "spaces only", if that's OK with you.  But that's obviously for a
separated thread.

> But if this patch is not about cleaning up the style to make it
> conform to a policy (whichever it is), I would have preferred to see
> a clean-up patch as a separate step, not mixed together with this.
>
The reason those few clean-ups are mixed into this patch is that the
pre-existing strange indentation style was actually making it more
difficult for me to grasp the code flow; that is, I didn't see them
as a cosmetic change, but as a way to make it easier for me and the
reader to see that my changes were correct and sensible.

> That's all; either way, no big deal.
> 
OK.  Just let me know if you'd still prefer to have the indentation
cleanups done by a preparatory patch, and I'll send a re-roll.

Thanks,
  Stefano

      reply	other threads:[~2012-09-11 20:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-11 15:45 [PATCH 1/2] build: improve GIT_CONF_SUBST signature Stefano Lattarini
2012-09-11 15:45 ` [PATCH 2/2] build: don't duplicate substitution of make variables Stefano Lattarini
2012-09-11 17:27   ` Junio C Hamano
2012-09-11 18:26     ` Stefano Lattarini
2012-09-11 19:52       ` Junio C Hamano
2012-09-11 20:17         ` Stefano Lattarini [this message]

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=504F9C73.1040409@gmail.com \
    --to=stefano.lattarini@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.