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] 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