On Wed, Sep 25, 2019 at 03:47:47PM +0200, David Sterba wrote: > On Tue, Sep 24, 2019 at 04:32:48PM -0400, Josef Bacik wrote: > > Hopefully all of it makes it this time, if you want you can pull from > > > > git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git \ > > extent-io-rearranging > > The size of the exported patch 1/4 is 109066 bytes and the diff itself > is incomprehensible to even see what code moves where and what is new. > > I'm still thinking if this is a good idea to apply a monster patch, even > it's just moving code around. The previous series splitting > extent-tree.c were better so I'd rather take that approach again. Some > of the functions belong logically together and won't break compilation > and would actually make it possible for a human to review. extent-tree.c was way different because a bunch of things had to be renamed and exported. Also extent-tree.c got split into many more files, so there was less bulk being moved around. extent_io.c is different because basically everything is exported already, so it's really just move definitions, move code. I literally just split vim'ed, cut and paste between the two files. Things like this are going to be impossible to review. It's a one time pain for more readability and better decisions down the road. I did my best to keep the logical changes to their own patch, but the fact is we have _a lot_ of code for each of these different logical things. I can turn it into 45 patches moving one function at a time, but who's going to go and check each individual patch? Josef
