Ralf's Remove CVS Id Commits

Fri May 4 23:48:31 UTC 2012

I don't care on the head if a revert patch shows up. Sebastian and I both committed afterwards so nuking them would be back.

On 4.10 nuking them is desirable if not too risky.

--joel

Gedare Bloom <gedare at rtems.org> wrote:

>On Fri, May 4, 2012 at 7:06 PM, Gedare Bloom <gedare at rtems.org> wrote:
>> This CVS Id business is a mess. I'd prefer that Ralf clean-up / revert
>> what he did with a single change to both the head and the 4.10 branch.
>> Then we can proceed in a more friendly way.
>>
>> The following commands will revert all the various patches for the git
>> head in a single patch.
>>
>> git checkout -b revert-ids 27272db3363cce157e83e484f9f89cc41fc0752c
>> git revert HEAD~61 -n
>> git commit -m "Ids: revert"
>> git push upstream revert-ids:master
>>
>It might be necessary to create  patch and then apply it to a
>checked-out head. I'm not sure about pushing from a checked-out
>previous commit.
>
>> See http://git.rtems.org/gedare/rtems.git/commit/?h=revert-ids
>>
>> A similar formula can be made for 4.10 if we like, or we could reset
>> the repository to get rid of them entirely... For the 4.10 branch I
>> think we can 'reset' the repository since (likely) no one has checked
>> it out and started to work from where the removals took place.
>> git checkout upstream/4.10 -b 4.10
>> git pull
>> git reset --hard f29ab47c93619c705c82d096c6d2cb85e95247ba
>> git push -f
>>
>> That's not very nice to do but as long as no one has based any work
>> off the 4.10 head since these Remove Id commits occurred then
>> everything should be fine and the history will be cleaner.
>>
>> -Gedare
>>
>> On Fri, May 4, 2012 at 1:55 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>>> On 05/04/2012 11:34 AM, Ralf Corsepius wrote:
>>>>
>>>> On 05/04/2012 05:07 PM, Thomas Doerfler wrote:
>>>>>
>>>>> Ralf,
>>>>>
>>>>> Am 04.05.2012 16:44, schrieb Ralf Corsepius:
>>>>>>
>>>>>> On 05/04/2012 04:10 PM, Thomas Doerfler wrote:
>>>>>>>
>>>>>>> These changes belong together. Nobody wants this change to be done in
>>>>>>> one BSP and NOT done in a different one.
>>>>>>
>>>>>> Did you actually have a look into the patches?
>>>>>
>>>>> Yes and no. I read some at the beginning, some in the middle and some at
>>>>> the end of your two patch sequences. I saw that each patch performs
>>>>> similar modifications for different directories or dir trees. I saw that
>>>>> you have committed separate patches with similar changes for each BSP or
>>>>> group of BSPs.
>>>>
>>>> Correct ...
>>>>
>>>>> I am sure you don't want the community to inspect each patch separately?
>>>>
>>>> Pardon, I am the original author of all the files and probably nobody
>>>> knows these better than me. I had applied many much more intrusive
>>>> patches in similar ways many times before.
>>>
>>> I'm the author of a lot of the source in the tree and I don't trust
>>> anyone's script enough to commit the result without a review.
>>>
>>> I don't care who edits the damned files. The issue is that I
>>> posted (1) complete patches for most of the tree and
>>> (2) I asked for review.
>>>
>>> You ignored (1) and by "nibbling" are making my work
>>> "hard". You didn't want anyone to do that to you but it
>>> was OK to do that to me.
>>>
>>> When I ask for review on something, I think it is something
>>> that needs review. I don't care who wrote it or how it
>>> was generated. Why is your script any less suspect than mine?
>>>
>>>
>>>
>>>> I am surely not perfect and surely do not want exclude something might
>>>> have gone wrong somewhere, but this request of yours makes me sad.
>>>
>>> This isn't about how you feel. This is about cooperating.
>>>
>>> You ignored my near work which eliminated ALL CVS Ids
>>> in most of the tree. It was available for review and
>>> I had specifically asked for review. If anyone has
>>> reason to have their feelings hurt, it is me.  You obviously
>>> think my changes were not worthy of your review time
>>> and it didn't matter if you "nibbled" and caused me
>>> extra work.
>>>
>>> Somehow your changes were above needing to be
>>> reviewed while mine were unworthy of your review.
>>>
>>>
>>>>> I assume that the goal/intention of each patch is quite silimar. Am I
>>>>> right here? Or do they have different goals/intentions?
>>>>
>>>> ... these changes were script-generated ,. the spots changed were
>>>> trivial to parse comment blocks.
>>>
>>> So were mine. What makes your "nibbling" so superior that
>>> it could conflict with my complete work which was available
>>> for review?
>>>
>>>>>>> Maybe you should get familiar with the idea that git does apply patches
>>>>>>> in an atomic way and not in a uncorrelated file-by-file basis as CVS
>>>>>>> does.
>>>>>>
>>>>>> The mashing up of the commit messages wasn't done by CVS. It was the
>>>>>> tool being used to produce the commit messages, which was polling at 1
>>>>>> hour intervals and glueing together independent commits.
>>>>>
>>>>> Why did you let it glue independent commits?
>>>>
>>>> I did not do anything - This was the tool somebody (I think it was
>>>> Chris) had installed on rtems.org to send CVS commit logs.
>>>
>>> That is an operator error on your part.  That's why I did the
>>> work on a git branch on my personal repo. It could be reviewed,
>>> the patches squashed into a single "automatic" and a
>>> single "manual" if that was what the community wanted.
>>>
>>> The review was for both "correctness" and to ensure
>>> that the community was happy with the edits.
>>>
>>>> Ralf
>>>> _______________________________________________
>>>> rtems-devel mailing list
>>>> rtems-devel at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>>
>>>
>>>
>>> --
>>> Joel Sherrill, Ph.D.             Director of Research&   Development
>>> joel.sherrill at OARcorp.com        On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>>    Support Available             (256) 722-9985
>>>
>>>
>>> _______________________________________________
>>> rtems-devel mailing list
>>> rtems-devel at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-devel