On 09/28, Johannes Schindelin wrote:
> Hi all,
>
> On Thu, 10 Aug 2017, Johannes Schindelin wrote:
>
> > On Tue, 8 Aug 2017, Brandon Williams wrote:
> >
> > > On 08/08, Stefan Beller wrote:
> > > > On Tue, Aug 8, 2017 at 5:05 AM, Johannes Schindelin
> > > > wrote:
> >
Hi all,
On Thu, 10 Aug 2017, Johannes Schindelin wrote:
> On Tue, 8 Aug 2017, Brandon Williams wrote:
>
> > On 08/08, Stefan Beller wrote:
> > > On Tue, Aug 8, 2017 at 5:05 AM, Johannes Schindelin
> > > wrote:
> > > >
> > > > On Mon, 7 Aug 2017, Brandon Williams
Hi,
brian m. carlson wrote:
>> On Wed, Aug 09, 2017 at 03:53:17PM -0700, Stefan Beller wrote:
>>> We may have different opinions on what is readable/beautiful code.
>>> If we were to follow a mutual agreed style that is produced by a tool,
>>> we could use clean/smudge filters with different
On Wed, Aug 09, 2017 at 07:19:00PM -0400, Jeff King wrote:
> On Wed, Aug 09, 2017 at 03:53:17PM -0700, Stefan Beller wrote:
>
> > >> Right, the reason I stopped pursuing it was that I couldn't find a way
> > >> to have it make suggestions for new code without nagging about existing
> > >> code.
Hi Junio,
On Thu, 10 Aug 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Wed, 9 Aug 2017, Stefan Beller wrote:
> >
> >> > I am sure that something even better will be possible: a Continuous
> >> > "Integration" that fixes the coding style
On 13/08/17 18:33, Junio C Hamano wrote:
> Ramsay Jones writes:
>> Hmm, on reflection, it may be a bit too crude! :-D
>
> As you already saw in the output from this, I think this is a good
> illustration that shows why we want an incremental tool that works
> on
Ramsay Jones writes:
> As a start, how about something like this:
>
> -- >8 --
> $ git diff
> diff --git a/Makefile b/Makefile
> index 461c845d3..7555def45 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2440,6 +2440,18 @@ $(SP_OBJ): %.sp: %.c GIT-CFLAGS FORCE
>
On 13/08/17 17:14, Ramsay Jones wrote:
>
>
> On 13/08/17 05:41, Jeff King wrote:
>> On Fri, Aug 11, 2017 at 09:39:11PM -0700, Junio C Hamano wrote:
>>
Yeah, I just dug in the archive. The script I ran way back when was
actually clang-format-diff.
>>>
>>> I am confident with the
On 13/08/17 05:41, Jeff King wrote:
> On Fri, Aug 11, 2017 at 09:39:11PM -0700, Junio C Hamano wrote:
>
>>> Yeah, I just dug in the archive. The script I ran way back when was
>>> actually clang-format-diff.
>>
>> I am confident with the competence of people around here that we can
>> come up
On Fri, Aug 11, 2017 at 09:39:11PM -0700, Junio C Hamano wrote:
> > Yeah, I just dug in the archive. The script I ran way back when was
> > actually clang-format-diff.
>
> I am confident with the competence of people around here that we can
> come up with a reasonable checker for obvious style
Jeff King writes:
> On Fri, Aug 11, 2017 at 10:52:37AM -0700, Brandon Williams wrote:
>
>> On 08/09, Stefan Beller wrote:
>> > On Wed, Aug 9, 2017 at 3:53 PM, Stefan Beller wrote:
>> >
>> > > I would think based on these options, a pre commit hook can be
>> >
On Fri, Aug 11, 2017 at 10:52:37AM -0700, Brandon Williams wrote:
> On 08/09, Stefan Beller wrote:
> > On Wed, Aug 9, 2017 at 3:53 PM, Stefan Beller wrote:
> >
> > > I would think based on these options, a pre commit hook can be
> > > written that formats precisely the
On 8/10/2017 5:30 PM, Brandon Williams wrote:
On 08/10, Junio C Hamano wrote:
Brandon Williams writes:
On 08/10, Junio C Hamano wrote:
I vaguely recall that there was a discussion to have SubmitGit wait
for success from Travis CI; if that is already in place, then I
Brandon Williams writes:
>> checkpatch.pl also warns a SP immediately before HT, which I do pay
>
> I'm sorry what's 'HT'?
Horizontal tab.
"man ascii" or http://man7.org/linux/man-pages/man7/ascii.7.html
On 08/09, Stefan Beller wrote:
> On Wed, Aug 9, 2017 at 3:53 PM, Stefan Beller wrote:
>
> > I would think based on these options, a pre commit hook can be
> > written that formats precisely the touched lines of code of each file.
>
> I did not search enough,
On 08/09, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >>> > +# Insert a space after a cast
> >>> > +# x = (int32) y;notx = (int32)y;
> >>> > +SpaceAfterCStyleCast: true
> >>>
> >>> Hmph, I thought we did the latter, i.e. cast sticks to the casted
> >>>
On 08/10, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > On 08/10, Junio C Hamano wrote:
> >
> >> I vaguely recall that there was a discussion to have SubmitGit wait
> >> for success from Travis CI; if that is already in place, then I can
> >> sort of see how it would
Brandon Williams writes:
> On 08/10, Junio C Hamano wrote:
>
>> I vaguely recall that there was a discussion to have SubmitGit wait
>> for success from Travis CI; if that is already in place, then I can
>> sort of see how it would help individual contributors to have the
>>
On 08/10, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > On Wed, 9 Aug 2017, Stefan Beller wrote:
> >
> >> > I am sure that something even better will be possible: a Continuous
> >> > "Integration" that fixes the coding style automatically by using
> >> >
Johannes Schindelin writes:
> On Wed, 9 Aug 2017, Stefan Beller wrote:
>
>> > I am sure that something even better will be possible: a Continuous
>> > "Integration" that fixes the coding style automatically by using
>> > `filter-branch` (avoiding the merge conflicts
Hi Stefan,
On Wed, 9 Aug 2017, Stefan Beller wrote:
> > I am sure that something even better will be possible: a Continuous
> > "Integration" that fixes the coding style automatically by using
> > `filter-branch` (avoiding the merge conflicts that would arise if
> > `rebase -i` was used).
>
> I
On Wed, Aug 09, 2017 at 03:53:17PM -0700, Stefan Beller wrote:
> >> Right, the reason I stopped pursuing it was that I couldn't find a way
> >> to have it make suggestions for new code without nagging about existing
> >> code. If we were to aggressively reformat to match the tool for existing
>
On Wed, Aug 9, 2017 at 3:53 PM, Stefan Beller wrote:
> I would think based on these options, a pre commit hook can be
> written that formats precisely the touched lines of code of each file.
I did not search enough, "clang-tidy-diff.py --fix" should be all that is needed
On Wed, Aug 9, 2017 at 7:03 AM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Wed, Aug 09 2017, Jeff King jotted:
>
>> On Mon, Aug 07, 2017 at 06:25:54PM -0700, Brandon Williams wrote:
>>
>>> I'm sure this sort of thing comes up every so often on the list but back at
>>> git-merge I
>>
>> I'm sure both of these things will probably happen if we decide to make
>> use of a code-formatter. This RFC is really just trying to ask the
>> question: "Is this something we want to entertain doing?"
>> My response would be 'Yes' but there's many other opinions to consider
>> first :)
Hi,
On Tue, 8 Aug 2017, Brandon Williams wrote:
> On 08/08, Stefan Beller wrote:
> > On Tue, Aug 8, 2017 at 5:05 AM, Johannes Schindelin
> > wrote:
> > > Hi Brandon,
> > >
> > > On Mon, 7 Aug 2017, Brandon Williams wrote:
> > >
> > >> Add a '.clang-format' file which
On Wed, Aug 09 2017, Jeff King jotted:
> On Mon, Aug 07, 2017 at 06:25:54PM -0700, Brandon Williams wrote:
>
>> I'm sure this sort of thing comes up every so often on the list but back at
>> git-merge I mentioned how it would be nice to not have to worry about style
>> when reviewing patches as
On Mon, Aug 07, 2017 at 06:25:54PM -0700, Brandon Williams wrote:
> I'm sure this sort of thing comes up every so often on the list but back at
> git-merge I mentioned how it would be nice to not have to worry about style
> when reviewing patches as that is something mechanical and best left to a
Junio C Hamano writes:
>>> > +# Insert a space after a cast
>>> > +# x = (int32) y;notx = (int32)y;
>>> > +SpaceAfterCStyleCast: true
>>>
>>> Hmph, I thought we did the latter, i.e. cast sticks to the casted
>>> expression without SP.
>>
>> I've seen both and I wasn't
Brandon Williams writes:
>> > +# Add a line break after the return type of top-level functions
>> > +# int
>> > +# foo();
>> > +AlwaysBreakAfterReturnType: TopLevel
>>
>> We do that?
>
> Haha So generally no we don't do this. Though there are definitely many
> places in our
On 08/08, Stefan Beller wrote:
> On Tue, Aug 8, 2017 at 5:05 AM, Johannes Schindelin
> wrote:
> > Hi Brandon,
> >
> > On Mon, 7 Aug 2017, Brandon Williams wrote:
> >
> >> Add a '.clang-format' file which outlines the git project's coding
> >> style. This can be used
On 08/08, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > Add a '.clang-format' file which outlines the git project's coding
> > style. This can be used with clang-format to auto-format .c and .h
> > files to conform with git's style.
> >
> > Signed-off-by: Brandon
Brandon Williams writes:
> Add a '.clang-format' file which outlines the git project's coding
> style. This can be used with clang-format to auto-format .c and .h
> files to conform with git's style.
>
> Signed-off-by: Brandon Williams
> ---
>
> I'm sure
On Tue, Aug 8, 2017 at 5:05 AM, Johannes Schindelin
wrote:
> Hi Brandon,
>
> On Mon, 7 Aug 2017, Brandon Williams wrote:
>
>> Add a '.clang-format' file which outlines the git project's coding
>> style. This can be used with clang-format to auto-format .c and .h
>>
Hi Brandon,
On Mon, 7 Aug 2017, Brandon Williams wrote:
> Add a '.clang-format' file which outlines the git project's coding
> style. This can be used with clang-format to auto-format .c and .h
> files to conform with git's style.
>
> Signed-off-by: Brandon Williams
> ---
>
Add a '.clang-format' file which outlines the git project's coding
style. This can be used with clang-format to auto-format .c and .h
files to conform with git's style.
Signed-off-by: Brandon Williams
---
I'm sure this sort of thing comes up every so often on the list but
36 matches
Mail list logo