Hey, After having received another round of acks on the idmapped mounts series and other fses about to move forward with porting I moved forward with merging [1] into my for-next branch which is tracked by sfr in linux-next. Given the nature of the series I expected there to be a good chunk of merge conflicts including some non-trivial ones. But there proved to be too many conflicts or at least a few ones that sfr couldn't handle without more insight into the series. So after talking to sfr this morning we decided to drop the tree for today.
Obviously we would like to see this in linux-next and we will likely run into similar problems should you decide to want to pull this. I could try and choose a common base with at least one tree (e.g. Al's) but this will only get rid of some merge conflicts. I'm sure I could also do an extremely fine-grained split of each patch in the series though I don't think that's very helpful in this case either. I could do a daily rebase onto linux-next which is similar to what Andrew does for such patch series which get included into linux-next as a rebased post-next patchbomb (as sfr pointed out to me). The series has a large xfstest series associated with it so it's at least easily detectable when the rebase breaks things. I would prefer to not have to burden someone else with this and rather deal with the merge conflict resolution myself to make sure that no wider context is missed. It would also allow me to point out where the painpoints are if this gets sent for inclusion/is accepted. So completely independent of whether or not you ultimately decide to accept or reject the series it might be pretty helpful to know what your preferred way of dealing with similar series is to make it easier for you later on. Christian [1]: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=idmapped_mounts I know that we have https://www.kernel.org/doc/html/latest/maintainer/rebasing-and-merging.html and it touches on stuff like this to some extent in "Merging from sibling or upstream" trees but it's not clear that this would be beneficial here or whether it wouldn't just make the changeset harder to follow.