git tree updates....
Lachlan,
I just noticed you've been updating the git tree. You might want to change the order that certain patches have been committed - the changes to the fs/inode.c needed to be committed before the changes to fs/xfs/xfs_inode.c that use them. They've been committed the wrong way around and about 20 commits apart, so there's significant region in the commit history where the kernel will fail to build. Given the distance between the commits, there's a fair chance that a git bisect could land in this range of compiliation failures.
Any chance of redoing these commits before you push to Linus so that they are ordered correctly in the git tree?
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Quoted 11 lines · Dave Chinner
Lachlan,
I just noticed you've been updating the git tree. You might want to change the order that certain patches have been committed - the changes to the
fs/inode.cneeded to be committed before the changes tofs/xfs/xfs_inode.cthat use them. They've been committed the wrong way around and about 20 commits apart, so there's significant region in the commit history where the kernel will fail to build. Given the distance between the commits, there's a fair chance that a git bisect could land in this range of compiliation failures.
Quoted 2 lines
Any chance of redoing these commits before you push to Linus so that they are ordered correctly in the git tree?
Yeah I'll try to get them back in the right order. Our merge tools conveniently missed anything outside fs/xfs so I didn't realise I had missed them until after I merge all the XFS mods. I just wanted to get something out for linux-next and also since the cvs tree was busted.
Out of curiosity Dave, why didn't you send those changes directly to Linus?
Quoted 12 lines · Lachlan McIlroy
Quoted 11 lines · Dave Chinner
Lachlan,
I just noticed you've been updating the git tree. You might want to change the order that certain patches have been committed - the changes to the
fs/inode.cneeded to be committed before the changes tofs/xfs/xfs_inode.cthat use them. They've been committed the wrong way around and about 20 commits apart, so there's significant region in the commit history where the kernel will fail to build. Given the distance between the commits, there's a fair chance that a git bisect could land in this range of compiliation failures.
Quoted 7 lines
Quoted 2 lines
Any chance of redoing these commits before you push to Linus so that they are ordered correctly in the git tree?
Yeah I'll try to get them back in the right order. Our merge tools conveniently missed anything outside fs/xfs so I didn't realise I had missed them until after I merge all the XFS mods. I just wanted to get something out for linux-next and also since the cvs tree was busted.
Fair enough - I wasn't sure that you noticed it.
Quoted 2 lines
Out of curiosity Dave, why didn't you send those changes directly to Linus?
Because trying to co-ordinate an dependent updates in different trees is extremely painful. We'd have to delay the XFS update till the inode patches were in mainline anyway, so it makes little sense to separate them....
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
While we at it, the b0rked m_vfsmount addition for DMAPI keeps on leaking into the git tree for -next..
Quoted 2 lines · Christoph Hellwig
While we at it, the b0rked
m_vfsmountaddition for DMAPI keeps on leaking into the git tree for -next..
Thanks for pointing that out - that shouldn't have happened. It wont be going to mainline.
The OSS xfs trees are in a bit of a mess and have been for a while. I've been wanting to clean them up but figured it would be easier to wait until we've moved over to git internally and then clone new trees.