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? Barry > > Satish
