On Sun, Nov 25, 2018 at 10:41:32PM -0500, Theodore Y. Ts'o wrote:
> On Mon, Nov 19, 2018 at 01:23:32PM -0800, Jaegeuk Kim wrote:
> > Hi Chandan,
> >
> > Let me try to queue and test this patch separately from the patch-set in order
> > to avoid merge conflicts. So, I think IS_ENCRYPTED should be merged in f2fs/ext4
> > branches, and the others can be applied to fscrypt and fsverity into each trees.
>
> Hi Jaeguk,
>
> What conflicts are you anticipating? I can't apply the rest of
> Chandan's patches without unless we apply them in order, and I'd
> prefer to avoid cross-merging, or spreading out this series across two
> kernel releases.
Oh, I see the problem. It's commit 79c66e7572 ("f2fs: clean up
f2fs_sb_has_##feature_name") on the f2fs dev branch. It changes the
function signature of the f2fs_sb_has_<feature>() functions.
This is going to be a problem for merging the fsverity patch series as
well. How stable are these patches on the f2fs dev branch?
79c66e75720c f2fs: clean up f2fs_sb_has_##feature_name
6a917e69d3b8 f2fs: remove codes of unused wio_mutex
67bdd2a68f0a f2fs: fix count of seg_freed to make sec_freed correct
a5c7029ba357 f2fs: fix to account preflush command for noflush_merge mode
83effa8865cc f2fs: avoid GC causing encrypted file corrupted
It might be that the simplest way to solve things is to merge the f2fs
dev branch up to 79c66e75720c. This will have the net effect of
including the five patches listed above onto the fscrypt git tree. So
long you don't plan to rebase or otherwise change these five patches,
it should avoid any merge conflicts.
- Ted
