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!
