> I like this idea of avoiding force pushing, but I'm not git expert to know > exactly if this gives exactly the intended result = start clean and not > have noise when doing bisects or git blame
It's clean for our own repo but might probably screw up cloned repos as they cannot just git-pull anymore. LieGrue, strub > Am 08.01.2017 um 11:41 schrieb Hervé BOUTEMY <herve.bout...@free.fr>: > > I like this idea of avoiding force pushing, but I'm not git expert to know > exactly if this gives exactly the intended result = start clean and not have > noise when doing bisects or git blame > > this technical discussion should probably on a separate email thread, to not > pollute the vote thread > > Any git experts to evaluate this implementation strategy? > > Regards, > > Hervé > > Le jeudi 5 janvier 2017, 10:12:10 CET Mark Derricutt a écrit : >> 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
