[petsc-dev] does next model mess up our histories
Satish Balay
balay at mcs.anl.gov
Thu Oct 2 00:33:24 CDT 2014
On Thu, 2 Oct 2014, Satish Balay wrote:
> On Thu, 2 Oct 2014, Jed Brown wrote:
>
> > Satish Balay <balay at mcs.anl.gov> 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
More information about the petsc-dev
mailing list