On Fri, Apr 17, 2020 at 9:02 AM Manuel Bouyer <bou...@antioche.eu.org> wrote:
> On Fri, Apr 17, 2020 at 07:52:53AM -0700, Jason Thorpe wrote: > > > > > On Apr 17, 2020, at 7:46 AM, Robert Elz <k...@munnari.oz.au> wrote: > > > > > > Date: Fri, 17 Apr 2020 15:37:33 +0200 > > > From: Manuel Bouyer <bou...@antioche.eu.org> > > > Message-ID: <20200417133733.ga5...@antioche.eu.org> > > > > > > | And that would be a problem for me. I regulary update a single file > to a > > > | specific revision in a source tree. > > > > > > Me too - I pull the current sh into NetBSD 8 (and I guess 9 now too, > > > though I haven't done that yet) and build it there for some people who > > > like to test and report bugs. > > > > The New Hotness (which isn't particularly new, at this point) is to > create branches and merge what you want into that branch. > > Yes, but it's much more work than 'cvs up' in a single directory or against > a few files. > The real new hotness is to use a git mirror to create a branch and then rebase it. It's no more steps to rebase a branch forward than it is to update twice... OK, don't know if it's really the right new hotness, or coldness, or lukewarm seething, but it's a strategy I've started to use to keep FreeBSD-specific changes for software that doesn't support it (yet) before I upstream (or if I upstream, sometimes the upstreams don't want to know). With NetBSD and updating /bin/sh to the latest on an old branch, I'd think that would just be creating a branch from netbsd-8, cherry picking the /bin/sh changes to that branch and then rebasing it forward as the netbsd-8 branch evolves, possibly with cherry-picking new changes as /bin/sh does in -current. It's more controlled that way, and also allows tweaks to /bin/sh if it were to become uncompilable as-is for some reason (more likely with other programs than /bin/sh). It's a little more work, but it's a lot more flexible. Warner
