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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/9/24 13:02, Christian Brauner wrote:
> On Mon, Sep 09, 2024 at 12:42:53PM GMT, Christian Brauner wrote:
>> On Mon, Sep 09, 2024 at 12:35:37PM GMT, Vlastimil Babka wrote:
>> > On 9/9/24 12:13, Christian Brauner wrote:
>> > > On Mon, Sep 09, 2024 at 11:40:25AM GMT, Vlastimil Babka wrote:
>> > >> 
>> > >> > 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.
>> > 
>> > It seems I'll be fine indeed as our shared base 0f389adb4b80 is back, but
>> > looks like the top-most merge commit 3a3e007d8946 is wrong as it has
>> > 6e016babce7c (the rewrite of 0f389adb4b80) as parent instead, so there are
>> > now duplicated commits in vfs.file itself:
>> > 
>> > https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs.file
>> 
>> Thanks! Ffs, let me go fix that.
> 
> Ok, how's it looking now?

vfs.file seems ok to me now, but vfs.all has merged the older version of it
thus is not ok yet, as Stephen pointed out. Thanks.




[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux