Ralf's Remove CVS Id Commits
gedare at rtems.org
Fri May 4 23:06:27 UTC 2012
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
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 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.
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:
>>> 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
>>>> 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.
>> rtems-devel mailing list
>> rtems-devel at rtems.org
> 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
More information about the devel