On Mon, Sep 12, 2022 at 12:17 PM David Blaikie wrote:
>
> On Sat, Sep 10, 2022 at 3:01 PM Kazu Hirata wrote:
> >
> > Thank you Aaron and David for your inputs.
> >
> > First and foremost, I apologize if I made your job harder by increasing the
> > number of commits you have to peel to get to the
On Sat, Sep 10, 2022 at 3:01 PM Kazu Hirata wrote:
>
> Thank you Aaron and David for your inputs.
>
> First and foremost, I apologize if I made your job harder by increasing the
> number of commits you have to peel to get to the real author.
>
> I hear that we are moving toward github pull reques
On Sat, Sep 10, 2022 at 6:01 PM Kazu Hirata wrote:
>
> Thank you Aaron and David for your inputs.
>
> First and foremost, I apologize if I made your job harder by increasing the
> number of commits you have to peel to get to the real author.
No worries at all! It's all a tradeoff. :-)
> I hear
On Thu, Sep 8, 2022 at 12:37 PM David Blaikie wrote:
>
> Mixed feelings here - Kazu's made a lot of cleanup/stylistic changes
> across the LLVM project for a while now, most, at least I think, are
> quite welcome (things like switching to range-based-for, std
> algorithms over llvm ones, llvm algo
Mixed feelings here - Kazu's made a lot of cleanup/stylistic changes
across the LLVM project for a while now, most, at least I think, are
quite welcome (things like switching to range-based-for, std
algorithms over llvm ones, llvm algorithms over manually written
loops, etc). But yeah, there's some
FWIW, sweeping NFC changes like this cause a fair amount of code churn
(which makes tools like git blame a bit harder to use) for a
relatively small improvement to code readability, which is why our
developer policy asks that you "Avoid committing formatting- or
whitespace-only changes outside of c
