On Mon, Nov 20, 2023 at 08:51:51AM -0800, Darrick J. Wong wrote: > On Mon, Nov 20, 2023 at 04:10:46PM +0100, cem@xxxxxxxxxx wrote: > > From: Carlos Maiolino <cem@xxxxxxxxxx> > > > > Merge commits in the kernel tree, only polutes the patch list to be > > imported into libxfs, explicitly ignore them. > > > > Signed-off-by: Carlos Maiolino <cem@xxxxxxxxxx> > > --- > > > > I'm considering here my own usecase, I never used merge commits, and sometimes > > they break the synchronization, so they make no good for me during libxfs-sync. > > The downside of ignoring merge commits is that Linus edited > xfs_rtbitmap.c in the 6.7 merge commit to get rid of the weird code that > casts a struct timespec64 to a u64 rtpick sequence counter and has > screwed things up for years. Well... My curse catches me again... Every time I say "I am not going to use it", something happens to prove me wrong :) Thanks for letting me know, I didn't get to 6.7 libxfs-sync yet, so, please, just ignore this patch. Carlos > > --D > > > tools/libxfs-apply | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/tools/libxfs-apply b/tools/libxfs-apply > > index 097a695f9..aa2530f4d 100755 > > --- a/tools/libxfs-apply > > +++ b/tools/libxfs-apply > > @@ -445,8 +445,8 @@ fi > > > > # grab and echo the list of commits for confirmation > > echo "Commits to apply:" > > -commit_list=`git rev-list $hashr | tac` > > -git log --oneline $hashr |tac > > +commit_list=`git rev-list --no-merges $hashr | tac` > > +git log --oneline --no-merges $hashr |tac > > read -r -p "Proceed [y|N]? " response > > if [ -z "$response" -o "$response" != "y" ]; then > > fail "Aborted!" > > -- > > 2.41.0 > >