Date:   Thu, 26 May 2022 13:53:17 +1000
From:   Dave Chinner <david@...morbit.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     linux-xfs <linux-xfs@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Eric Sandeen <sandeen@...deen.net>,
        "Darrick J. Wong" <djwong@...nel.org>
Subject: Re: [GIT PULL] xfs: new code for 5.19

On Wed, May 25, 2022 at 07:56:31PM -0700, Linus Torvalds wrote:
> On Wed, May 25, 2022 at 7:21 PM Dave Chinner <david@...morbit.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.

Weird.

> 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..

$ git reset --hard origin/master
Updating files: 100% (6994/6994), done.
HEAD is now at d7227785e384 Merge tag 'sound-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
$ git merge xfs-5.19-for-next 
Auto-merging fs/xfs/xfs_file.c
Auto-merging fs/xfs/xfs_log_cil.c
Auto-merging fs/xfs/xfs_super.c
Merge made by the 'ort' strategy.
 fs/xfs/Makefile                    |    1 +
....
 fs/xfs/xfs_xattr.c                 |    2 +-
 105 files changed, 4862 insertions(+), 2773 deletions(-)
 create mode 100644 fs/xfs/xfs_attr_item.c
 create mode 100644 fs/xfs/xfs_attr_item.h
$

> > 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).

Those one came from pull requests with informative signed
tags. We're trying to move more of our development processes to
using signed pull reqs when eveything is done, so this hopefully
will happen more often.

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

Yeah, those are merges from local topic branches where I pulled in
individual patches or entire series from the mailing list via 'b4 am
-o - <msg_id> | git am -s'. AFAICT there is no way to have this
retain the patch series cover letter, which generally contains what
I would want to be putting into the merge commit message.

I'll keep that in mind for future composes, though I do wish there
was an easy way to just have b4/git manage cover letters as part of
the topic branch so they can feed into local merge commits just as
easily remote pulls do....

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com

Powered by blists - more mailing lists