On Oct 1, 2014, at 10:19 PM, Satish Balay <[email protected]> wrote:
> 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 :) And then not have it happen for how long? gurus unfortunately tend work work at their own schedule. > > 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
