[U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14

[Tom Rini]

On Wed, Jun 18, 2014 at 04:24:39PM -0500, Scott Wood wrote:
> On Wed, 2014-06-18 at 09:55 +0200, Heiko Schocher wrote:
> > Hello Scott,
[snip]
> > > history to see what Linux version corresponded to the last mtd sync, and
> > > generate a diff relative to that.
> > 
> > I think, we should have the linux code as the reference, and on top
> > of this, we should add our U-Boot changes ... Thats the reason
> > for the git tree [1].
> 
> One of the strengths of version control is the ability to do three-way
> merges, rather than throw away the downstream code and reassemble it
> from scratch.

Indeed.

[snip]
> 
> What does #ifndef __UBOOT__ tell you that a diff between the U-Boot and
> Linux files, as of the SHA1 that was last merged into U-Boot, doesn't
> tell you?
> 
> > There we have the "simple copy from linux patch" [2]. It overwrites
> > the U-Boot specific changes, yes, but only in an intermediate step
> > in this git tree ... (Maybe I should add in the commit message, that
> > this is a simple copy from linux sources)
> > 
> > Then a U-Boot specifc patch [3], which introduces again hopefully
> > all U-Boot specific changes... so *all* U-Boot specific changs are
> > documented. At last a seperate licencse file patch [4] added which
> > changes the license text.
> > 
> > My hope was, that future linux mtd syncs could look like:
> > 
> > a) copy new linux source files to u-boot tree [1] (make a new branch
> >     go back to commit [2] ... and copy new files from linux)
> >     (commit this, to have all linux changes since last sync
> >      with linux documented)
> > b) apply [3] and fix problems
> >     All U-Boot changes documented
> > c) apply [4] and fix problems
> > d) add newly added U-Boot specific patches
> >     (mark them with _UBOOT_ define if they are not yet marked with it)
> >     (maybe squash them to step b ?)
> > 
> >     -> new git tree ready
> > 
> > e) squash all patches into one patch and send it to mainline ...
> >     so the mainline patch has only new changes with all U-Boot
> >     specific changes.
> 
> If you take over as NAND custodian, you can of course do the updates as
> you please (unless Tom or Wolfgang disagree), but until then I insist on
> doing a proper merge, and not littering the code with #ifndef __UBOOT__.
> 
> > Thats sounds easy ... and you have all linux and all U-Boot
> > changes visible and documented ... I must admit, I did not
> > tried your proposal to look into the linux changes since
> > the last mtd sync ... but that sounds the more tricky way
> > to get this sync, as the history can be long ... and shouldn;t
> > be the result the same?
> 
> Why does the length of the history matter?  I'm not asking you to go
> patch by patch.  Just take a diff between the SHA1 of last merge and the
> SHA1 you want to merge now, and apply that patch.

But it's not even that hard to do so!  git format-patch -o mtd-resync
v3.7..v3.14 drivers/mtd/nand will give you only the relevant patches,
and they should mostly apply, and then you can squash them after the
fact.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140618/24736ad1/attachment.pgp>