On Wed, 1 Oct 2014, Barry Smith wrote: > > On Oct 1, 2014, at 9:55 PM, Satish Balay <[email protected]> wrote: > > > On Wed, 1 Oct 2014, Barry Smith wrote: > > > >> > >> On Oct 1, 2014, at 9:34 PM, Satish Balay <[email protected]> wrote: > >> > >>> On Wed, 1 Oct 2014, Barry Smith wrote: > >>> > >>>> > >>>> For large changes that I especially expect to break portability issues I > >>>> make a set of changes, merge into next to check on all machines and then > >>>> fix the issues that come up in tests the next day. This can happen a few > >>>> times. > >>>> > >>>> Now if I only did testing on my own machine during these several days, > >>>> since my branch never touches another branch I can rebase it, I can > >>>> reset some changes if I realize they are really stupid, then I could put > >>>> a very nice commit into master with a great history. > >>>> > >>>> How can I do this after I have put all the trash into next along the > >>>> way? Is there a modification of the next model we can use that would > >>>> allow me to have clearer histories? How do other groups handle this, we > >>>> know Linus doesn’t allow ugly histories so how can the model work for > >>>> them? > >>>> > >>> > >>> I think its valid to 'git revert trash-branch' from next - and then > >>> 'git merge clean/rebased-branch' [per current workflow] > >>> > >>> http://git-scm.com/blog/2010/03/02/undoing-merges.html > >>> git revert -m 1 [sha_of_C8] > >>> > >>> I'm not sure what happens if there are multiple merges from the > >>> 'trash-branch' to next. Perhaps we would have to revert each of the > >>> merge points [in the reverse order] - and then merge in the rebased > >>> branch. > >>> > >>> In this case - I think its ok to have the trashy history in the > >>> feature-branch - until its complete - and then do the 'rebase/cleanup’ > >> > >> Yes but then after it is put rebased/cleaned up and put into master won’t > >> that cause grief because what in next is very different and merging master > >> into next will be be problematic? Or is it not a problem? > > > > No - because we reverted the messy stuff from next [before merging the > > cleaned stuff to next]. i.e > > But going over and doing all the reverts in next is busy work that I really > don’t want to do (and as you say in your next email I may mess up). Better > yet to toss next and get it clean from master
All 'integrator' operations need extra care [hence the restricted access control.] And deleting/recreating next is a worse option [and more work] in my opinion then just doing the reverts as needed. We are supporsed to be verifing stuff during general workflow steps [but sometimes we skimp]. All I meant to say is:for any revert - its more important to verify. BTW: we revert only the 'merges' to next - not individual commits in next. You might have 10-20 commits in the feature branch - but you might have merged to next only 2 or 3 times. [so It should be only 2-3 reverts of the merges in next] And then rebase/cleanup the featurebranch [and merge to next the final time] Satish > > > > > master contains: old-master + clean-feature > > > > next contains : old-next + messy-feature - messy-feature + clean-feature > > > > [and we don't care about the messy history in next as its discarded at next > > release] > > > > Satish > >
