On Oct 1, 2014, at 10:08 PM, Satish Balay <[email protected]> wrote:
> 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] 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. Barry > > 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
