| Message ID | 20231120151056.710510-1-cem@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] libxf-apply: Ignore Merge commits | expand |
On Mon, Nov 20, 2023 at 04:10:46PM +0100, cem@kernel.org wrote: > From: Carlos Maiolino <cem@kernel.org> > > 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@kernel.org> > --- > > 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. --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 >
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@kernel.org wrote: > > From: Carlos Maiolino <cem@kernel.org> > > > > 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@kernel.org> > > --- > > > > 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 > >
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!"