On Wed, 1 Oct 2014, Barry Smith wrote: > > 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.
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. Another option: [when the feature branch is ready for rebase/cleanup] delegate the revert of the messy-feature branch to git guru :) Satish > > 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 > >
