linux-next: duplicate patches in the gfs2 and xfs trees

linux-next: duplicate patches in the gfs2 and xfs trees

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: duplicate patches in the gfs2 and xfs trees

[Andreas Gruenbacher]

Hi,

On 12 July 2018 at 03:37, Stephen Rothwell <sfr@canb.auug.org.au> 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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4010 bytes --]

Hi Andreas,

On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher <agruenba@redhat.com> 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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: duplicate patches in the gfs2 and xfs trees

[Andreas Gruenbacher]

Hi Stephen,

On 12 July 2018 at 06:41, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Andreas,
>
> On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher <agruenba@redhat.com> 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

[Darrick J. Wong]

On Thu, Jul 12, 2018 at 07:16:18AM +0200, Andreas Gruenbacher wrote:
> Hi Stephen,
> 
> On 12 July 2018 at 06:41, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Andreas,
> >
> > On Thu, 12 Jul 2018 04:30:07 +0200 Andreas Gruenbacher <agruenba@redhat.com> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html