Re: linux-next: duplicate patches in the slab tree

[Christian Brauner]

On Mon, Sep 09, 2024 at 11:40:25AM GMT, Vlastimil Babka wrote:
> On 9/9/24 11:16, Christian Brauner wrote:
> > On Mon, Sep 09, 2024 at 09:18:57AM GMT, Vlastimil Babka wrote:
> >> On 9/9/24 09:12, Stephen Rothwell wrote:
> >> > Hi all,
> >> > 
> >> > The following commits are also in the vfs-brauner tree as different
> >> > commits (but the same patches):
> >> > 
> >> >   c0390d541128 ("fs: pack struct file")
> >> >   ea566e18b4de ("fs: use kmem_cache_create_rcu()")
> >> >   d345bd2e9834 ("mm: add kmem_cache_create_rcu()")
> >> >   e446f18e98e8 ("mm: remove unused argument from create_cache()")
> >> >   0f389adb4b80 ("mm: Removed @freeptr_offset to prevent doc warning")
> >> > 
> >> > These are commits
> >> > 
> >> >   f2b8943e64a8 ("fs: pack struct file")
> >> >   d1e381aa30cb ("fs: use kmem_cache_create_rcu()")
> >> >   ba8108d69e5b ("mm: add kmem_cache_create_rcu()")
> >> >   a85ba9858175 ("mm: remove unused argument from create_cache()")
> >> >   6e016babce7c ("mm: Removed @freeptr_offset to prevent doc warning")
> >> > 
> >> > in the vfs-brauner tree.
> >> > 
> >> > These duplicates are causing unnecessary comflicts ...
> >> 
> >> Thanks,
> >> 
> >> Christian told me merging the vfs.file branch (a necessary prerequisity for
> >> one series in slab) would be ok as it was stable at that point. What
> >> happened? If I do redo with a new merge, will that stay unchanged until the
> >> merge window?
> > 
> > Hm, that's very odd that the IDs changed. The only thing that I did was
> > b4 trailers -u on the branch to quickly check whether I missed an RvBs
> > or Acks. But there were none so I assumed that the commit ids wouldn't
> 
> I guess b4 could be smarter and not perform/rollback the history rewrite if
> there's nothing to change.
> I hope I would have caught such surprise by trying git push without --force
> if I assumed there was no rebase and only new patches added on top. But
> maybe you had some intended rebase in some of the newer patches there.
> 
> > change. Let me check and rollback if that was the case.
> 
> Thank!

No problem. I promised a stable branch so you'll get one. :)

So I rebased vfs.file onto the previous patches and pushed it out.
Note that I've merged an additional series into vfs.file but that should
not matter to you as long as you keep using our shared base.

Note, I also pulled

git pull -S slab slab/for-6.12/kmem_cache_args

into vfs.file.slab for a test and that works fine so commit ids should
be back to their previous state. But please do double-check.