[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
2009/4/22 Alex Blewitt <alex.blewitt@xxxxxxxxx>:
> I think git would be a good way to go in the future at a time when it is
> good enough. But the current state of the plugin is alpha level and not
> suited for project migration yet; though it is gaining steam.
I agree, this is the big weak spot.
> Because Git preserves history on your local side, it folds each (local)
> commit into it's own patch. I've ended up with 8 patches for a simple file
> because I was committing as I was going. I don't think this scales with
> bugzilla attachments yet. It may even be something mylyn can help with.
Well these patches are useful for people using git at both ends. When
you're just submitting a patch for bugzilla, one will do, just:
git diff --no-prefix cdt_head_branch > bug-nnn.patch
will produce a normal patch that can be applied by committers (the
--no-prefix strips the a/ b/ prefix git puts on source / destination
files).
You can also use git-rebase to reorder / collapse / remove
intermediate patches you don't want others to see in your history.
Obviously don't do this on branches which you've share with others :)
I can imagine you'll benefit hugely from using git to manage your cdt
branch while it's still in flux. It certainly helped me when I was
working on re-factoring the project model storage mechanism. Git kept
my repo in line with CDT mainline and I could regenerate the main
patch without much difficulty:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=252966
I've also used it with great success to un-fork e4 & eclipse platform head.
With very few commands, git was generating merge patches used to bring
the dated e4 repos back into line with HEAD:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=268107
These patches were then applied to e4 -- it turns out to be 'hard' to
do this with CVS (especially when the repos are forked)!
This sort of thing is a real pain with CVS where it's semi-manual, you
have to remember merge points, and likelihood of human error is huge.
In the past I've wasted a lot of time manually merging, correcting
errors, iterating... Automating this really has helped improve my
workflow and is highly recommended for anyone else doing this
semi-professionally ;)
I know you've said before that it's difficult to proceed with
objective-eclipse when you require users to patch cdt.core, and it is
a pain. I'd encourage you to (at least in the short-term) maintain an
up-to-date fork. It'd certainly lower the barrier to entry for me to
give it a whirl -- and perhaps others too :)!
Cheers,
James
>
> Still, it can only get better and the more people that play with it and
> report bugs etc the better.
>
> Alex
>
> Sent from my (new) iPhone
>
> On 22 Apr 2009, at 18:04, "Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>
> wrote:
>
>> :)
>>
>> CVS has served us well too. The CVS plug-in still has the best merge
>> experience relative to the SVN plug-ins. But anyway, indepenedent of
>> that...
>>
>> I'm starting to get into git with qemu (which is in the middle of moving
>> from svn to git), the linux kernel, clutter, etc. As such I'm going to
>> start using the egit plug-in with CDT to get a sense of how close (or
>> far) away it is from being usable. That would be a key criterea before
>> making the move.
>>
>> And since so many git user projects are C/C++, we need to get involved
>> to grow the CDT into that community. Has anyone else tried it?
>>
>> Doug.
>>
>> -----Original Message-----
>> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
>> On Behalf Of Elena Laskavaia
>> Sent: Wednesday, April 22, 2009 12:36 PM
>> To: CDT General developers list.
>> Subject: Re: [cdt-dev] git
>>
>> What is wrong with bugzilla?
>>
>> Mike Kucera wrote:
>>>
>>> I've always found it ironic how we are building modern
>>> state-of-the-art development tools, but we use archaic tools like CVS
>>> and bugzilla to do it. I feel that CVS has become completely obsolete.
>>
>>> I've never used git but from what I hear its very good. If the rest of
>>
>>> the community is willing to take the lead in making the switch then I
>>
>> am all for it.
>>>
>>> +1 for git
>>>
>>> Mike Kucera
>>> Software Developer
>>> IBM Eclipse CDT Team
>>> mkucera@xxxxxxxxxx
>>>
>>> Inactive hide details for "Schaefer, Doug" ---04/22/2009 11:46:31
>>> AM---BTW, I'm closely tracking the git situation. It is my
>>> se"Schaefer, Doug" ---04/22/2009 11:46:31 AM---BTW, I'm closely
>>> tracking the git situation. It is my sense that git will help us
>>> immensely, even dealing with API changes afte
>>>
>>>
>>> From:
>>> "Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>
>>>
>>> To:
>>> "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
>>>
>>> Date:
>>> 04/22/2009 11:46 AM
>>>
>>> Subject:
>>> RE: [cdt-dev] git (was:The Great Managed Build API Tooling Fiasco of
>>> 2009)
>>>
>>> ----------------------------------------------------------------------
>>> --
>>>
>>>
>>>
>>> BTW, I'm closely tracking the git situation. It is my sense that git
>>> will help us immensely, even dealing with API changes after the
>>> release as Elena mentions (i.e., do it in your git repo and contribute
>>
>>> it to the master later).
>>>
>>> So, Chris, I will get you started ;). I'd like to know the CDT
>>> community's opinion on this. One thing that Mike challenged us at the
>>> council meetings at EclipseCon was for a high profile project to step
>>> up and say they would like to move to git before the Foundation would
>>> seriously invest in it. Personally, I'd like the CDT to be one of the
>>> first. What do you think?
>>>
>>> Doug.
>>>
>>> ----------------------------------------------------------------------
>>> --
>>> *From:* cdt-dev-bounces@xxxxxxxxxxx
>>> [mailto:cdt-dev-bounces@xxxxxxxxxxx]
>>> *On Behalf Of *Chris Recoskie*
>>> Sent:* Wednesday, April 22, 2009 7:57 AM*
>>> To:* CDT General developers list.*
>>> Subject:* Re: [cdt-dev] The Great Managed Build API Tooling Fiasco of
>>> 2009
>>>
>>> I agree, but don't get me started :-P
>>>
>>> ===========================
>>> Chris Recoskie
>>> Team Lead, IBM CDT and RDT
>>> IBM Toronto
>>> Inactive hide details for Jesper Eskilson
>>> <jesper.eskilson@xxxxxx>Jesper Eskilson <jesper.eskilson@xxxxxx>
>>>
>>> *Jesper Eskilson
>>>
>> <jesper.eskilson@xxxxxx>*
>>>
>>> Sent by:
>>>
>>> cdt-dev-bounces@xxxxxxxxxxx
>>>
>>> 04/22/2009 03:40 AM
>>>
>>> Please respond to
>>> "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
>>>
>>>
>>> To
>>>
>>> "CDT General developers list." <cdt-dev@xxxxxxxxxxx> cc
>>>
>>> Subject
>>>
>>> Re: [cdt-dev] The Great Managed Build API Tooling Fiasco of 2009
>>>
>>>
>>>
>>>
>>> Chris Recoskie wrote:
>>>
>>>> My first instinct was to perhaps refactor these packages to use the
>>
>>> right > naming convention, but then we lose the CVS history on them
>>> all, and this > affects a lot of classes :-(
>>>
>>> You are using an antiquated version-control tool, you know that,
>>
>> right?
>>>
>>> The rest of the (open source) world abandoned CVS a long time ago.
>>>
>>> --
>>> /Jesper
>>>
>>> _______________________________________________
>>> cdt-dev mailing list
>>> cdt-dev@eclipse.org_
>>> __https://dev.eclipse.org/mailman/listinfo/cdt-dev_
>>> _______________________________________________
>>> cdt-dev mailing list
>>> cdt-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> --
>>>
>>> _______________________________________________
>>> cdt-dev mailing list
>>> cdt-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
