On Fri, Jul 21, 2017 at 7:52 PM, Dan Williams <dan.j.willi...@intel.com> wrote: > [ adding Chris ] > > On Fri, Jul 21, 2017 at 4:44 PM, Dan Williams <dan.j.willi...@intel.com> > wrote: >> On Fri, Jul 21, 2017 at 3:58 PM, Ingo Molnar <mi...@kernel.org> wrote: >>> >>> * Dan Williams <dan.j.willi...@intel.com> wrote: >>> >>>> [...] >>>> >>>> * Like perf, ndctl borrows the sub-command architecture and option >>>> parsing from git. So, this code could be refactored into something >>>> shared / generic, i.e. the bits in tools/perf/util/. >>> >>> Just as a side note, stacktool (tools/stacktool/) is using the Git >>> sub-command and >>> options parsing code as well, and it's already sharing it with perf, via the >>> tools/lib/subcmd/ library. >>> >>> ndctl could use that as well. >> >> Ah, nice, that refactoring happened about a year after ndctl was born. >> Which brings up the next question about what to do with the git >> history, but I'd want to know if ndctl is even welcome upstream before >> digging any deeper. > > I suspect this would be similar to what Chris did to merge btrfs while > retaining the standalone history. Chris, any pointers on what worked > well and what if anything you would do differently? I.e. I'm looking > to use git filter-branch to rewrite ndctl history as if if had always > been in tools/ndctl in the kernel tree. I found this old thread > https://lkml.org/lkml/2008/10/30/523 and it seems to also recommend > using an older kernel as the branch base.
So it wasn't as painful as I thought it would be, I just used the script Linus recommended in that thread. Here is what I came up with merging the last ndctl release on top of v4.9, and then applying the pending development patches re-filtered to tools/ndctl: https://git.kernel.org/pub/scm/linux/kernel/git/djbw/nvdimm.git/log/?h=for-4.14/ndctl ...the next thing would be to rework the versioning to use the kernel version and switch to using tools/lib/subcmd/.