This would be better on the discuss thread, but here is my answer anyway: Well we want to bring most of that history back in for 3.5.1+ so, no that wouldn't work AIUI.
Part of the issue is the to and fro with things like the bump of modelVersion to 4.1.0 and then the revert, etc. Plus if the commits are in history how can mortal git users determine what is included. On Wed 4 Jan 2017 at 21:12, Mark Derricutt <m...@talios.com> wrote: > > > On 5 Jan 2017, at 1:16, Stephen Connolly wrote: > > > > > > > As this involves a --force push on the `master` branch, we want to get the > > > approval of the committers before continuing. > > > > > > > > > > > You *could* branch at the point you want to reset to, then use an > ours/theirs merge strategy which creates a merge commit that ONLY takes one > side. Effectively resetting, keeping the fact we did this reversal, and > doesn't force everyone to re-clone. > > > > > From https://git-scm.com/docs/merge-strategies: > > > > > *ours:* This resolves any number of heads, but the resulting tree of the > merge is always that of the current branch head, effectively ignoring all > changes from all other branches. It is meant to be used to supersede old > development history of side branches. Note that this is different from the > -Xours option to the 'recursive' merge strategy. > > > > > Would something like this be better than force pushing? > > > > > -- > > > Mark Derricutt > > > http://www.theoryinpractice.net > > > http://www.chaliceofblood.net > > > http://plus.google.com/+MarkDerricutt > > > http://twitter.com/talios > > > http://facebook.com/mderricutt > > > -- Sent from my phone