On Mon, Dec 17, 2018 at 1:22 PM Steve Fink wrote:
> In theory, I would definitely prefer if all the code were auto-formatted
> during regular development(*), but in practice the performance means
> it's not as transparent as it needs to be -- I have noticed that since
> enabling the
On Fri, Dec 14, 2018 at 4:55 PM Kartikaya Gupta wrote:
> On Fri, Dec 14, 2018 at 1:58 PM Sylvestre Ledru
> wrote:
> > We have more and more tools at review phase (clang-format, flake8,
> eslint, clang-tidy, codespell, etc) which propose some auto-fixes.
>
> Honestly I find it quite annoying
In theory, I would definitely prefer if all the code were auto-formatted
during regular development(*), but in practice the performance means
it's not as transparent as it needs to be -- I have noticed that since
enabling the format-source extension, rebasing my patch stacks is
significantly
On Mon, Dec 17, 2018 at 9:33 AM Kartikaya Gupta wrote:
> Local commit hooks are even better, thanks! Are there instructions
> somewhere on how to set up the hooks and make sure they run properly?
>
We've yet to document these hooks but enabling them is very similar to
enabling the lint hooks
Local commit hooks are even better, thanks! Are there instructions
somewhere on how to set up the hooks and make sure they run properly?
On Mon, Dec 17, 2018 at 9:22 AM Ehsan Akhgari wrote:
>
> On Fri, Dec 14, 2018 at 7:20 AM Kartikaya Gupta wrote:
>>
>> Personally I would prefer if we rewrote
On Fri, Dec 14, 2018 at 7:20 AM Kartikaya Gupta wrote:
> Personally I would prefer if we rewrote the commits locally to be
> formatted prior to submitting it into Phabricator. That way everything
> stays in sync. Also usually clang-formatting a patch is the last thing
> I want to do before
Le 14/12/2018 à 22:55, Kartikaya Gupta a écrit :
On Fri, Dec 14, 2018 at 1:58 PM Sylvestre Ledru wrote:
We have more and more tools at review phase (clang-format, flake8, eslint,
clang-tidy, codespell, etc) which propose some auto-fixes.
Honestly I find it quite annoying when I'm trying to
Hi
> On 14 Dec 2018, at 7:57 pm, Sylvestre Ledru wrote:
>
> I think we should aim at option b) (updated automatically by bots after
> submission to Phabricator)
>
>
I don’t particularly fancy this idea. Finding yourself with different code on
Phabricator and locally is a good way to shoot
Personally I would prefer if we rewrote the commits locally to be
formatted prior to submitting it into Phabricator. That way everything
stays in sync. Also usually clang-formatting a patch is the last thing
I want to do before submission anyway. And doing it now is kind of
annoying if you have a
I think we should aim at option b) (updated automatically by bots after
submission to Phabricator)
We have more and more tools at review phase (clang-format, flake8,
eslint, clang-tidy, codespell, etc) which propose some auto-fixes.
Currently, the turn around time of the tools is 14m on
On Fri, Dec 14, 2018 at 1:58 PM Sylvestre Ledru wrote:
> We have more and more tools at review phase (clang-format, flake8, eslint,
> clang-tidy, codespell, etc) which propose some auto-fixes.
Honestly I find it quite annoying when I'm trying to review a patch
and the phabricator diff is filled
Previously I had shied away from ideas similar to (a) or (b) since I wasn't
sure if that would be what developers would expect and accept, given that
it would cause the change the reviewer sees to no longer match their local
change, which could cause hicups e.g. when trying to find the code that a
On Fri, Dec 07, 2018 at 03:08:51PM -0500, Andrew Halberstadt wrote:
> I think we should implement a) and do the formatting prior to submission.
> This prevents us from wasting reviewer time on format issues, and also
> makes sure that "what you see in phab, is what gets landed".
Also, that would
I think we should implement a) and do the formatting prior to submission.
This prevents us from wasting reviewer time on format issues, and also
makes sure that "what you see in phab, is what gets landed".
On Fri, Dec 7, 2018, 2:04 PM Gregory Szorc, wrote:
> On Fri, Dec 7, 2018 at 1:57 PM
On Fri, Dec 7, 2018 at 1:57 PM Botond Ballo wrote:
> On Fri, Dec 7, 2018 at 11:36 AM Sylvestre Ledru
> wrote:
> > In the meantime, we will be running a bot weekly to reformat the
> > mistakes and add the changeset into the ignore lists.
> > But in the long run this won’t be sustainable, so once
On Fri, Dec 7, 2018 at 11:36 AM Sylvestre Ledru wrote:
> In the meantime, we will be running a bot weekly to reformat the
> mistakes and add the changeset into the ignore lists.
> But in the long run this won’t be sustainable, so once we gain
> confidence that a good number of developers have
Le 05/12/2018 à 00:22, Botond Ballo a écrit :
> Hi, I'd like to ask a couple of clarifications about process here: *
Is clang-format invoked automatically as part of a pre-commit hook, or
something like that?
We have been working on that. There is a pending patch
Hi,
I'd like to ask a couple of clarifications about process here:
* Is clang-format invoked automatically as part of a pre-commit hook,
or something like that?
* If not, should we be invoking it manually before submitting a patch?
* If we submit a patch without having invoked it, will
On Thu, Nov 22, 2018 at 3:07 PM Ehsan Akhgari
wrote:
> Felipe, gps and I talked a bit about adding a similar
> .hg-blame-ignore-revs file in the tree which can contain Mercurial sha1
> changeset IDs for the rewrite commits to be skipped over, and people would
> be able to use the file through
On Thu, Nov 22, 2018 at 4:07 AM Jean-Yves Avenard
wrote:
> Hi
>
> > On 21 Nov 2018, at 3:54 am, Ehsan Akhgari
> wrote:
> >
> >
> > You will break the blame on VCS with this change
> >
> > Yes and no. Of course, just like many tree-wide mass changes in the past
> > (e.g. the MPL2 header update),
Hi
> On 21 Nov 2018, at 3:54 am, Ehsan Akhgari wrote:
>
>
> You will break the blame on VCS with this change
>
> Yes and no. Of course, just like many tree-wide mass changes in the past
> (e.g. the MPL2 header update), this will remain in the log.
>
> Mercurial and Git both support a -w
21 matches
Mail list logo
