Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220526022053.GY2306852@dread.disaster.area>
In-Reply-To: <20220526022053.GY2306852@dread.disaster.area>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed, 25 May 2022 19:56:31 -0700
Message-ID: <CAHk-=wg8R2sYVKi7bgwVN8n-exN766PSJwYg+18SLbR=+vQtVA@mail.gmail.com>
Subject: Re: [GIT PULL] xfs: new code for 5.19
To:     Dave Chinner <david@fromorbit.com>
Cc:     linux-xfs <linux-xfs@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Eric Sandeen <sandeen@sandeen.net>,
        "Darrick J. Wong" <djwong@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, May 25, 2022 at 7:21 PM Dave Chinner <david@fromorbit.com> wrote:
>
> Can you please pull the XFS updates for 5.19 from the tag listed
> below? It merges cleanly with the TOT kernel I just pulled a couple
> of minutes ago, though the diffstat I got on merge:
>
> 105 files changed, 4862 insertions(+), 2773 deletions(-)
>
> is slightly different to the diffstat the pull request generated.

Funky. I get the same diffstat that you list below in the pull
request, not the above.

Different diff algorithms do get different results, so the actual line
numbers vary a bit with the default myers vs minimal vs patience vs
histogram algorithms. But while that changes line numbers, it
shouldn't then change the actual number of files...

I wonder what the difference is, but I'm not going to delve into it
further since what I see matches the pull request and it all looks
fine.

I do notice that if I use

   git diff -C10 ..

to make git more eagerly find file copies, I get

 [...]
 104 files changed, 4444 insertions(+), 3125 deletions(-)
 copy fs/xfs/{xfs_bmap_item.c => xfs_attr_item.c} (13%)
 create mode 100644 fs/xfs/xfs_attr_item.h

and adding "-B/10%" to make git also look for rewrites (ie files that
might be better shown as "remove file and then re-add") gives:

 [..]
 104 files changed, 5449 insertions(+), 4130 deletions(-)
 rewrite fs/xfs/libxfs/xfs_attr.c (43%)
 copy fs/xfs/{xfs_bmap_item.c => xfs_attr_item.c} (13%)
 create mode 100644 fs/xfs/xfs_attr_item.h
 rewrite fs/xfs/xfs_log.h (31%)
 rewrite fs/xfs/xfs_message.h (30%)

so it might be something along those lines where our git configs
differ. I couldn't get it to give "105 files", though.

Not important. I just got curious.

And it might also be as simple as you just having had something else
in your tree at the same time, that you didn't want to send, but
forgot about when you did the test-merge. That would be the simplest
explanation..

> If I've made any mistakes or done stuff that is considered wrong or
> out of date, let me know and I'll fix them up - it's been a while
> since I built a tree for upstream merge.

It all looks fine.

I might wish that your merge commit messages were a bit more
consistent about the merge details ("why and what"), but you are most
definitely not the only one with that, and a number of them are quite
nice (ie the merge of the large extent counters has a nice informative
commit message, as does the rmap speedup one).

And then some of them are the uninformative one-lines that just say
"Merge branch X"

               Linus