[petsc-dev] does next model mess up our histories

[Barry Smith]

On Oct 1, 2014, at 10:19 PM, Satish Balay <balay at mcs.anl.gov> wrote:

> On Wed, 1 Oct 2014, Barry Smith wrote:
> 
>> 
>> On Oct 1, 2014, at 10:08 PM, Satish Balay <balay at mcs.anl.gov> wrote:
>> 
>>> On Wed, 1 Oct 2014, Barry Smith wrote:
>>> 
>>>> 
>>>> On Oct 1, 2014, at 9:55 PM, Satish Balay <balay at mcs.anl.gov> wrote:
>>>> 
>>>>> On Wed, 1 Oct 2014, Barry Smith wrote:
>>>>> 
>>>>>> 
>>>>>> On Oct 1, 2014, at 9:34 PM, Satish Balay <balay at mcs.anl.gov> 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