On Thu, 2 Oct 2014, Satish Balay wrote: > On Thu, 2 Oct 2014, Jed Brown wrote: > > > Satish Balay <[email protected]> writes: > > >> Ok, if this can be documented and made as simple as possible? A > > >> tool to do it? If it requires remember several arcane git commands > > >> to do and remember the numbers of 5 merges you made, then forget > > >> it. > > > > > > Perhaps Jed will reply with a simpler 'single' command to do the > > > revert all the merges from the feature branch - and an easy way to > > > verify. > > > > Nope, but I don't recommend these reverts because it makes it more > > confusing to follow 'next' and to find which commit introduced a change > > (when debugging something in 'next'). My preference is that in normal > > workflow, you don't rebase/modify that which has been merged to 'next'. > > If it's catastrophically wrong, then revert on 'next' and start over, > > but if it just needs a tweak, do that on top of your branch. > > I think is ok to be a bit more messy in next. Sure there is a tradeoff > - but you get better debugging in master :) > > We shouldn't be doing rebase for every feature branch (thats merged to > next) - but for the very few that might need it - we should ok to do > it. > > And it should be done only when the feature is deemed *complete* [say > 1-2 weeks of cooking in next - without a need for updates]
I guess another alternative for these veryfew feature branches that need to iterate over nightlytest suites is: - never merge feature branch to next untile its complete - switch master or next nightlytest to feature branch [for a few days] - fix rebase feature branch as needed. [would perhaps require test infrastructure improvements - and an apriori knowledge that this feature branch could go through major back and forth changes requiring multiple rebases] Satish
