I'm not sure a tag would add a whole lot of value, and would add a little bit of clutter. I don't think splitting a rebase into two will help very much (and if it is, the commit of interest just a few commits before the soon to be created 2.1.0-rc1 tag). The hard part is knowing how to deal with conflicts. Two rebases wont' minimize those all that much.
I've rebased this Apache patchset onto master many times and have gotten really good with dealing with the conflicts. If anyone has any branches that are pre-Apache switch, I'd be happy to help rebase those changes onto master and deal with conflicts. - Steve On 02/08/2018 09:18 AM, Mike Beckerle wrote: > I believe this: > > 945a1c1ab363485003ebf14fef3463055d4fab37 > > Is the last commit using the old file structure, old packages, etc. > > > I suspect it would be prudent to make a tag for this. This would be in case > some developer has lots of outstanding changes based on earlier commits. They > could first rebase to here, get everything working again, and then do the > rebase that changes all the names and such. > > > Naming convention? I suspect a somewhat verbose tag name would be better than > just a numbering convention, as the key concept here is that this is still > edu.illinois.ncsa daffodil packages. So something with the words "final" and > "edu.illinois.ncsa" as well as capturing that it is pre-2.1.0 release. > >
