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' Satish
