Re: linux-next: duplicate patches in the gfs2 and xfs trees
On Thu, Jul 12, 2018 at 07:16:18AM +0200, Andreas Gruenbacher wrote: > Hi Stephen, > > On 12 July 2018 at 06:41, Stephen Rothwell wrote: > > Hi Andreas, > > > > On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher > > wrote: > >> > >> this is what I'm seeing (git log --pretty=oneline --abbrev-commit > >> --graph ^origin/master gfs2/for-next): > >> > >> * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize > >> == PAGE_SIZE > >> * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads > >> * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next > >> |\ > >> | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support > >> to iomap_readpage_actor > >> | * ec181f6782d8 iomap: support direct I/O to inline data > >> | * 09230435dffd iomap: refactor iomap_dio_actor > >> | * c03cea42149d iomap: add initial support for writes without buffer heads > >> | * 72b4daa24129 iomap: add an iomap-based readpage and readpages > >> implementation > >> * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap > >> * | 2e2834ef1797 GFS2: Fix recovery issues for spectators > >> * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next > >> |\ \ > >> | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end} > >> | * | 967bcc91b044 gfs2: iomap direct I/O support > >> | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup > >> | * | 64bc06bb32ee gfs2: iomap buffered write support > >> | * | d505a96a3b16 gfs2: Further iomap cleanups > >> | |/ > >> | * e184fde6f3f5 iomap: add private pointer to struct iomap > >> | * 63899c6f8851 iomap: add a page_done callback > >> | * 19e0c58f6552 iomap: generic inline data handling > >> | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously > >> | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new > >> | * a6d639da63ae fs: factor out a __generic_write_end helper > >> * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t > >> * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of > >> posix_acl_to_xattr > >> * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have > >> blocks reserved > >> * d1475c07f7ce GFS2: rgrp free blocks used incorrectly > >> * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd > >> * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code > >> * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly > >> * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole > >> * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock > >> * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes > >> > >> Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on > >> xfs/iomap-4.19-merge. That was my initial merge from > >> xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge > >> commit. I've then merged our iomap-write branch into for-next, with > >> two additional commits on top. Then comes the rest of > >> xfs/iomap-4.19-merge (that branch has moved ahead in the meantime), > >> again with two more commits on top. > >> > >> There are no rebased commits, you're looking at the exact same commits. > > > > The problem is that commits > > > > a6d639da63ae fs: factor out a __generic_write_end helper > > > > to > > > > 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support > > > > have been rebased in the xfs tree from a base of v4.18-rc1 to > > v4.18-rc4, so that those patches now appear twice in linux-next where I > > have merged the gfs2 tree and the xfs tree. > > Ah, I see now. It's xfs/for-next that contains those rebased commits > from xfs/iomap-4.19-merge. > > > This has caused a few > > conflicts today as there are more changes to the same files affected by > > those commits in the xfs tree. to iomap_readpage_actor > > > > What should have happened is that those commits should not have been > > rebased, so either the xfs tree needs rebuilding to use the old > > commits, or your tree needs to be rebuilt using the new commits from > > the xfs tree. This is why we do not like the rebasing of published > > trees (especially when a subset of the tree is shared with other > > developers). > > > > Also, if you are going to merge (part of) another tree you need to make > > sure that the other maintainer will not do a rebase of it (I assume > > that this was probably talked about). > > Indeed, the idea of setting up xfs/iomap-4.19-merge was to have a > common base that xfs/for-next and gfs2/for-next could both merge from. > Darrick, could you please fix xfs/for-next? Ok, done, I think. Sorry for the mess, I hadn't ever done 'shared development branch merging into other tree' and clearly didn't get it right. :/ --D > Thanks a lot, > Andreas > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: duplicate patches in the gfs2 and xfs trees
On Thu, Jul 12, 2018 at 07:16:18AM +0200, Andreas Gruenbacher wrote: > Hi Stephen, > > On 12 July 2018 at 06:41, Stephen Rothwell wrote: > > Hi Andreas, > > > > On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher > > wrote: > >> > >> this is what I'm seeing (git log --pretty=oneline --abbrev-commit > >> --graph ^origin/master gfs2/for-next): > >> > >> * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize > >> == PAGE_SIZE > >> * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads > >> * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next > >> |\ > >> | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support > >> to iomap_readpage_actor > >> | * ec181f6782d8 iomap: support direct I/O to inline data > >> | * 09230435dffd iomap: refactor iomap_dio_actor > >> | * c03cea42149d iomap: add initial support for writes without buffer heads > >> | * 72b4daa24129 iomap: add an iomap-based readpage and readpages > >> implementation > >> * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap > >> * | 2e2834ef1797 GFS2: Fix recovery issues for spectators > >> * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next > >> |\ \ > >> | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end} > >> | * | 967bcc91b044 gfs2: iomap direct I/O support > >> | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup > >> | * | 64bc06bb32ee gfs2: iomap buffered write support > >> | * | d505a96a3b16 gfs2: Further iomap cleanups > >> | |/ > >> | * e184fde6f3f5 iomap: add private pointer to struct iomap > >> | * 63899c6f8851 iomap: add a page_done callback > >> | * 19e0c58f6552 iomap: generic inline data handling > >> | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously > >> | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new > >> | * a6d639da63ae fs: factor out a __generic_write_end helper > >> * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t > >> * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of > >> posix_acl_to_xattr > >> * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have > >> blocks reserved > >> * d1475c07f7ce GFS2: rgrp free blocks used incorrectly > >> * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd > >> * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code > >> * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly > >> * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole > >> * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock > >> * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes > >> > >> Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on > >> xfs/iomap-4.19-merge. That was my initial merge from > >> xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge > >> commit. I've then merged our iomap-write branch into for-next, with > >> two additional commits on top. Then comes the rest of > >> xfs/iomap-4.19-merge (that branch has moved ahead in the meantime), > >> again with two more commits on top. > >> > >> There are no rebased commits, you're looking at the exact same commits. > > > > The problem is that commits > > > > a6d639da63ae fs: factor out a __generic_write_end helper > > > > to > > > > 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support > > > > have been rebased in the xfs tree from a base of v4.18-rc1 to > > v4.18-rc4, so that those patches now appear twice in linux-next where I > > have merged the gfs2 tree and the xfs tree. > > Ah, I see now. It's xfs/for-next that contains those rebased commits > from xfs/iomap-4.19-merge. > > > This has caused a few > > conflicts today as there are more changes to the same files affected by > > those commits in the xfs tree. to iomap_readpage_actor > > > > What should have happened is that those commits should not have been > > rebased, so either the xfs tree needs rebuilding to use the old > > commits, or your tree needs to be rebuilt using the new commits from > > the xfs tree. This is why we do not like the rebasing of published > > trees (especially when a subset of the tree is shared with other > > developers). > > > > Also, if you are going to merge (part of) another tree you need to make > > sure that the other maintainer will not do a rebase of it (I assume > > that this was probably talked about). > > Indeed, the idea of setting up xfs/iomap-4.19-merge was to have a > common base that xfs/for-next and gfs2/for-next could both merge from. > Darrick, could you please fix xfs/for-next? Ok, done, I think. Sorry for the mess, I hadn't ever done 'shared development branch merging into other tree' and clearly didn't get it right. :/ --D > Thanks a lot, > Andreas > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: duplicate patches in the gfs2 and xfs trees
Hi Stephen, On 12 July 2018 at 06:41, Stephen Rothwell wrote: > Hi Andreas, > > On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher > wrote: >> >> this is what I'm seeing (git log --pretty=oneline --abbrev-commit >> --graph ^origin/master gfs2/for-next): >> >> * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize >> == PAGE_SIZE >> * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads >> * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next >> |\ >> | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support >> to iomap_readpage_actor >> | * ec181f6782d8 iomap: support direct I/O to inline data >> | * 09230435dffd iomap: refactor iomap_dio_actor >> | * c03cea42149d iomap: add initial support for writes without buffer heads >> | * 72b4daa24129 iomap: add an iomap-based readpage and readpages >> implementation >> * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap >> * | 2e2834ef1797 GFS2: Fix recovery issues for spectators >> * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next >> |\ \ >> | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end} >> | * | 967bcc91b044 gfs2: iomap direct I/O support >> | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup >> | * | 64bc06bb32ee gfs2: iomap buffered write support >> | * | d505a96a3b16 gfs2: Further iomap cleanups >> | |/ >> | * e184fde6f3f5 iomap: add private pointer to struct iomap >> | * 63899c6f8851 iomap: add a page_done callback >> | * 19e0c58f6552 iomap: generic inline data handling >> | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously >> | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new >> | * a6d639da63ae fs: factor out a __generic_write_end helper >> * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t >> * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of posix_acl_to_xattr >> * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have >> blocks reserved >> * d1475c07f7ce GFS2: rgrp free blocks used incorrectly >> * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd >> * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code >> * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly >> * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole >> * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock >> * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes >> >> Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on >> xfs/iomap-4.19-merge. That was my initial merge from >> xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge >> commit. I've then merged our iomap-write branch into for-next, with >> two additional commits on top. Then comes the rest of >> xfs/iomap-4.19-merge (that branch has moved ahead in the meantime), >> again with two more commits on top. >> >> There are no rebased commits, you're looking at the exact same commits. > > The problem is that commits > > a6d639da63ae fs: factor out a __generic_write_end helper > > to > > 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support > > have been rebased in the xfs tree from a base of v4.18-rc1 to > v4.18-rc4, so that those patches now appear twice in linux-next where I > have merged the gfs2 tree and the xfs tree. Ah, I see now. It's xfs/for-next that contains those rebased commits from xfs/iomap-4.19-merge. > This has caused a few > conflicts today as there are more changes to the same files affected by > those commits in the xfs tree. to iomap_readpage_actor > > What should have happened is that those commits should not have been > rebased, so either the xfs tree needs rebuilding to use the old > commits, or your tree needs to be rebuilt using the new commits from > the xfs tree. This is why we do not like the rebasing of published > trees (especially when a subset of the tree is shared with other > developers). > > Also, if you are going to merge (part of) another tree you need to make > sure that the other maintainer will not do a rebase of it (I assume > that this was probably talked about). Indeed, the idea of setting up xfs/iomap-4.19-merge was to have a common base that xfs/for-next and gfs2/for-next could both merge from. Darrick, could you please fix xfs/for-next? Thanks a lot, Andreas
Re: linux-next: duplicate patches in the gfs2 and xfs trees
Hi Stephen, On 12 July 2018 at 06:41, Stephen Rothwell wrote: > Hi Andreas, > > On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher > wrote: >> >> this is what I'm seeing (git log --pretty=oneline --abbrev-commit >> --graph ^origin/master gfs2/for-next): >> >> * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize >> == PAGE_SIZE >> * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads >> * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next >> |\ >> | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support >> to iomap_readpage_actor >> | * ec181f6782d8 iomap: support direct I/O to inline data >> | * 09230435dffd iomap: refactor iomap_dio_actor >> | * c03cea42149d iomap: add initial support for writes without buffer heads >> | * 72b4daa24129 iomap: add an iomap-based readpage and readpages >> implementation >> * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap >> * | 2e2834ef1797 GFS2: Fix recovery issues for spectators >> * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next >> |\ \ >> | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end} >> | * | 967bcc91b044 gfs2: iomap direct I/O support >> | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup >> | * | 64bc06bb32ee gfs2: iomap buffered write support >> | * | d505a96a3b16 gfs2: Further iomap cleanups >> | |/ >> | * e184fde6f3f5 iomap: add private pointer to struct iomap >> | * 63899c6f8851 iomap: add a page_done callback >> | * 19e0c58f6552 iomap: generic inline data handling >> | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously >> | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new >> | * a6d639da63ae fs: factor out a __generic_write_end helper >> * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t >> * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of posix_acl_to_xattr >> * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have >> blocks reserved >> * d1475c07f7ce GFS2: rgrp free blocks used incorrectly >> * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd >> * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code >> * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly >> * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole >> * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock >> * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes >> >> Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on >> xfs/iomap-4.19-merge. That was my initial merge from >> xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge >> commit. I've then merged our iomap-write branch into for-next, with >> two additional commits on top. Then comes the rest of >> xfs/iomap-4.19-merge (that branch has moved ahead in the meantime), >> again with two more commits on top. >> >> There are no rebased commits, you're looking at the exact same commits. > > The problem is that commits > > a6d639da63ae fs: factor out a __generic_write_end helper > > to > > 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support > > have been rebased in the xfs tree from a base of v4.18-rc1 to > v4.18-rc4, so that those patches now appear twice in linux-next where I > have merged the gfs2 tree and the xfs tree. Ah, I see now. It's xfs/for-next that contains those rebased commits from xfs/iomap-4.19-merge. > This has caused a few > conflicts today as there are more changes to the same files affected by > those commits in the xfs tree. to iomap_readpage_actor > > What should have happened is that those commits should not have been > rebased, so either the xfs tree needs rebuilding to use the old > commits, or your tree needs to be rebuilt using the new commits from > the xfs tree. This is why we do not like the rebasing of published > trees (especially when a subset of the tree is shared with other > developers). > > Also, if you are going to merge (part of) another tree you need to make > sure that the other maintainer will not do a rebase of it (I assume > that this was probably talked about). Indeed, the idea of setting up xfs/iomap-4.19-merge was to have a common base that xfs/for-next and gfs2/for-next could both merge from. Darrick, could you please fix xfs/for-next? Thanks a lot, Andreas
Re: linux-next: duplicate patches in the gfs2 and xfs trees
Hi Andreas, On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher wrote: > > this is what I'm seeing (git log --pretty=oneline --abbrev-commit > --graph ^origin/master gfs2/for-next): > > * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize > == PAGE_SIZE > * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads > * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next > |\ > | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support > to iomap_readpage_actor > | * ec181f6782d8 iomap: support direct I/O to inline data > | * 09230435dffd iomap: refactor iomap_dio_actor > | * c03cea42149d iomap: add initial support for writes without buffer heads > | * 72b4daa24129 iomap: add an iomap-based readpage and readpages > implementation > * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap > * | 2e2834ef1797 GFS2: Fix recovery issues for spectators > * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next > |\ \ > | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end} > | * | 967bcc91b044 gfs2: iomap direct I/O support > | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup > | * | 64bc06bb32ee gfs2: iomap buffered write support > | * | d505a96a3b16 gfs2: Further iomap cleanups > | |/ > | * e184fde6f3f5 iomap: add private pointer to struct iomap > | * 63899c6f8851 iomap: add a page_done callback > | * 19e0c58f6552 iomap: generic inline data handling > | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously > | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new > | * a6d639da63ae fs: factor out a __generic_write_end helper > * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t > * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of posix_acl_to_xattr > * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have > blocks reserved > * d1475c07f7ce GFS2: rgrp free blocks used incorrectly > * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd > * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code > * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly > * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole > * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock > * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes > > Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on > xfs/iomap-4.19-merge. That was my initial merge from > xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge > commit. I've then merged our iomap-write branch into for-next, with > two additional commits on top. Then comes the rest of > xfs/iomap-4.19-merge (that branch has moved ahead in the meantime), > again with two more commits on top. > > There are no rebased commits, you're looking at the exact same commits. The problem is that commits a6d639da63ae fs: factor out a __generic_write_end helper to 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support have been rebased in the xfs tree from a base of v4.18-rc1 to v4.18-rc4, so that those patches now appear twice in linux-next where I have merged the gfs2 tree and the xfs tree. This has caused a few conflicts today as there are more changes to the same files affected by those commits in the xfs tree. to iomap_readpage_actor What should have happened is that those commits should not have been rebased, so either the xfs tree needs rebuilding to use the old commits, or your tree needs to be rebuilt using the new commits from the xfs tree. This is why we do not like the rebasing of published trees (especially when a subset of the tree is shared with other developers). Also, if you are going to merge (part of) another tree you need to make sure that the other maintainer will not do a rebase of it (I assume that this was probably talked about). -- Cheers, Stephen Rothwell pgpxh8dvdhgbh.pgp Description: OpenPGP digital signature
Re: linux-next: duplicate patches in the gfs2 and xfs trees
Hi Andreas, On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher wrote: > > this is what I'm seeing (git log --pretty=oneline --abbrev-commit > --graph ^origin/master gfs2/for-next): > > * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize > == PAGE_SIZE > * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads > * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next > |\ > | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support > to iomap_readpage_actor > | * ec181f6782d8 iomap: support direct I/O to inline data > | * 09230435dffd iomap: refactor iomap_dio_actor > | * c03cea42149d iomap: add initial support for writes without buffer heads > | * 72b4daa24129 iomap: add an iomap-based readpage and readpages > implementation > * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap > * | 2e2834ef1797 GFS2: Fix recovery issues for spectators > * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next > |\ \ > | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end} > | * | 967bcc91b044 gfs2: iomap direct I/O support > | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup > | * | 64bc06bb32ee gfs2: iomap buffered write support > | * | d505a96a3b16 gfs2: Further iomap cleanups > | |/ > | * e184fde6f3f5 iomap: add private pointer to struct iomap > | * 63899c6f8851 iomap: add a page_done callback > | * 19e0c58f6552 iomap: generic inline data handling > | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously > | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new > | * a6d639da63ae fs: factor out a __generic_write_end helper > * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t > * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of posix_acl_to_xattr > * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have > blocks reserved > * d1475c07f7ce GFS2: rgrp free blocks used incorrectly > * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd > * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code > * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly > * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole > * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock > * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes > > Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on > xfs/iomap-4.19-merge. That was my initial merge from > xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge > commit. I've then merged our iomap-write branch into for-next, with > two additional commits on top. Then comes the rest of > xfs/iomap-4.19-merge (that branch has moved ahead in the meantime), > again with two more commits on top. > > There are no rebased commits, you're looking at the exact same commits. The problem is that commits a6d639da63ae fs: factor out a __generic_write_end helper to 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support have been rebased in the xfs tree from a base of v4.18-rc1 to v4.18-rc4, so that those patches now appear twice in linux-next where I have merged the gfs2 tree and the xfs tree. This has caused a few conflicts today as there are more changes to the same files affected by those commits in the xfs tree. to iomap_readpage_actor What should have happened is that those commits should not have been rebased, so either the xfs tree needs rebuilding to use the old commits, or your tree needs to be rebuilt using the new commits from the xfs tree. This is why we do not like the rebasing of published trees (especially when a subset of the tree is shared with other developers). Also, if you are going to merge (part of) another tree you need to make sure that the other maintainer will not do a rebase of it (I assume that this was probably talked about). -- Cheers, Stephen Rothwell pgpxh8dvdhgbh.pgp Description: OpenPGP digital signature
Re: linux-next: duplicate patches in the gfs2 and xfs trees
Hi, On 12 July 2018 at 03:37, Stephen Rothwell wrote: > Hi all, > > It looks like part of the xfs tree (the iomap-4.19-merge branch) that > was merge into the gfs2 tree has been rebased and the gfs2 tree has not > been updated to cope. The rebase commits are exactly the same patches > (though I didn't check to see if any of the commit messages had changed). this is what I'm seeing (git log --pretty=oneline --abbrev-commit --graph ^origin/master gfs2/for-next): * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize == PAGE_SIZE * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next |\ | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support to iomap_readpage_actor | * ec181f6782d8 iomap: support direct I/O to inline data | * 09230435dffd iomap: refactor iomap_dio_actor | * c03cea42149d iomap: add initial support for writes without buffer heads | * 72b4daa24129 iomap: add an iomap-based readpage and readpages implementation * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap * | 2e2834ef1797 GFS2: Fix recovery issues for spectators * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next |\ \ | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end} | * | 967bcc91b044 gfs2: iomap direct I/O support | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup | * | 64bc06bb32ee gfs2: iomap buffered write support | * | d505a96a3b16 gfs2: Further iomap cleanups | |/ | * e184fde6f3f5 iomap: add private pointer to struct iomap | * 63899c6f8851 iomap: add a page_done callback | * 19e0c58f6552 iomap: generic inline data handling | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new | * a6d639da63ae fs: factor out a __generic_write_end helper * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of posix_acl_to_xattr * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have blocks reserved * d1475c07f7ce GFS2: rgrp free blocks used incorrectly * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on xfs/iomap-4.19-merge. That was my initial merge from xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge commit. I've then merged our iomap-write branch into for-next, with two additional commits on top. Then comes the rest of xfs/iomap-4.19-merge (that branch has moved ahead in the meantime), again with two more commits on top. There are no rebased commits, you're looking at the exact same commits. I could redo for-next and add an explicit merge commit with one parent instead of the fast-forward merge; would that be preferable? Thanks, Andreas
Re: linux-next: duplicate patches in the gfs2 and xfs trees
Hi, On 12 July 2018 at 03:37, Stephen Rothwell wrote: > Hi all, > > It looks like part of the xfs tree (the iomap-4.19-merge branch) that > was merge into the gfs2 tree has been rebased and the gfs2 tree has not > been updated to cope. The rebase commits are exactly the same patches > (though I didn't check to see if any of the commit messages had changed). this is what I'm seeing (git log --pretty=oneline --abbrev-commit --graph ^origin/master gfs2/for-next): * f79caf101801 (gfs2/for-next) gfs2: use iomap_readpage for blocksize == PAGE_SIZE * af58827ee500 gfs2: Use iomap for stuffed direct I/O reads * c38e838abe42 Merge branch 'iomap-4.19-merge' into linux-gfs2/for-next |\ | * 806a1477b10a (xfs/iomap-4.19-merge) iomap: add inline data support to iomap_readpage_actor | * ec181f6782d8 iomap: support direct I/O to inline data | * 09230435dffd iomap: refactor iomap_dio_actor | * c03cea42149d iomap: add initial support for writes without buffer heads | * 72b4daa24129 iomap: add an iomap-based readpage and readpages implementation * | 9ab5aa4f4e10 gfs2: fallocate_chunk: Always initialize struct iomap * | 2e2834ef1797 GFS2: Fix recovery issues for spectators * | 5db0147b887e Merge branch 'iomap-write' into linux-gfs2/for-next |\ \ | * | 025d0e7f73c6 (gfs2/iomap-write) gfs2: Remove gfs2_write_{begin,end} | * | 967bcc91b044 gfs2: iomap direct I/O support | * | bcfe94139a45 gfs2: gfs2_extent_length cleanup | * | 64bc06bb32ee gfs2: iomap buffered write support | * | d505a96a3b16 gfs2: Further iomap cleanups | |/ | * e184fde6f3f5 iomap: add private pointer to struct iomap | * 63899c6f8851 iomap: add a page_done callback | * 19e0c58f6552 iomap: generic inline data handling | * ebf00be37de3 iomap: complete partial direct I/O writes synchronously | * 3d7b6b21f6c5 iomap: mark newly allocated buffer heads as new | * a6d639da63ae fs: factor out a __generic_write_end helper * 3beacef8093b fs: gfs2: Adding new return type vm_fault_t * d80ff78468e4 gfs2: using posix_acl_xattr_size instead of posix_acl_to_xattr * e904f3d486f9 gfs2: Don't reject a supposedly full bitmap if we have blocks reserved * d1475c07f7ce GFS2: rgrp free blocks used incorrectly * b7eba890a228 gfs2: Eliminate redundant ip->i_rgd * 03f8c41c73da gfs2: Stop messing with ip->i_rgd in the rlist code * ee9c7f9ae3d4 gfs2: call ktime_get_coarse_real_ts64() directly * 00251a16d7f9 gfs2: Minor clarification to __gfs2_punch_hole * 9e1a9ecd13b9 gfs2: Don't withdraw under a spin lock * f85c10e24ab9 gfs2: eliminate rs_inum and reduce the size of gfs2 inodes Commit e184fde6f3f5 "iomap: add private pointer to struct iomap" is on xfs/iomap-4.19-merge. That was my initial merge from xfs/iomap-4.19-merge, but it was a fast-forward so there is no merge commit. I've then merged our iomap-write branch into for-next, with two additional commits on top. Then comes the rest of xfs/iomap-4.19-merge (that branch has moved ahead in the meantime), again with two more commits on top. There are no rebased commits, you're looking at the exact same commits. I could redo for-next and add an explicit merge commit with one parent instead of the fast-forward merge; would that be preferable? Thanks, Andreas
linux-next: duplicate patches in the gfs2 and xfs trees
Hi all, It looks like part of the xfs tree (the iomap-4.19-merge branch) that was merge into the gfs2 tree has been rebased and the gfs2 tree has not been updated to cope. The rebase commits are exactly the same patches (though I didn't check to see if any of the commit messages had changed). -- Cheers, Stephen Rothwell pgpJ26_DhSQQW.pgp Description: OpenPGP digital signature
linux-next: duplicate patches in the gfs2 and xfs trees
Hi all, It looks like part of the xfs tree (the iomap-4.19-merge branch) that was merge into the gfs2 tree has been rebased and the gfs2 tree has not been updated to cope. The rebase commits are exactly the same patches (though I didn't check to see if any of the commit messages had changed). -- Cheers, Stephen Rothwell pgpJ26_DhSQQW.pgp Description: OpenPGP digital signature