Mail Archives: geda-user/2014/04/17/01:24:27
Peter Stuge wrote:
> DJ Delorie wrote:
>
>>> wanted to clarify that requesting write access to the main repo is
>>> absolutely not a neccessity for doing pcb development.
>>>
>> Sure, but saying "you don't have to ask for write access" is different
>> than promoting a "don't use in the main repo" strategy.
>>
> Not so different to me.
>
>
>
>> I have to use git a lot, and I hate it, because it makes it very
>> difficult for me to do my daily job. Please use the word "powerful"
>> more carefully ;-)
>>
> I would love to learn about how it is difficult for you. I'll chat
> you up on IRC some day.
>
>
>
>>> Especially a project such as integrating freerouter into pcb would
>>> do well living in its own branch somewhere,
>>>
>> I see no reason why this is the case, nor have you offered any such
>> reason.
>>
> The reason is that it's a neat work package which is likely nicely
> isolated from most other concurrent work.
>
> It's a great example of a feature branch, and maintaining it in a
> branch somewhere outside of the primary repo allows more freedom in
> the development.
>
> It becomes unneccessary to constantly synchronize with whatever else
> is going on, and development of the new feature can include wild
> experiments across the codebase which aren't neccessarily desirable
> in the primary repo just because they are part of the process for
> creating the new feature.
>
> And once the feature work has moved along further git makes it easy
> to rework (rebase) the branch so that it's ready to be proposed for
> inclusion into master, or maybe just moving into the primary repo.
>
>
>
>> If more than one person is working on a project, there needs
>> to be coordination and centralization *somehow*
>>
> Of course, just not neccessarily in the primary project repo. I think
> it's very nice if the primary repo doesn't see the craziest parts of
> new feature development.
>
>
>
>>> early work doesn't neccessarily belong in the primary project repository
>>>
>> This does not follow. We have plenty of temporary branches in the
>> main git repo.
>>
> I'm not saying that it's always wrong. I'm saying it's not always right.
> Sometimes it is right, sometimes wrong. When? That's up to developer
> judgement.
>
>
>
>>> trivially so using git fetch, cherry-pick and am, if the commits
>>> are published using git's own tools.
>>>
>> Please use the word "trivially" more carefully. Another sore spot
>> between me and git.
>>
> I hope you'll tell me more, maybe I can help in some way.
>
>
>
>>> Of course you are right that it's nice to make ongoing work easily
>>> available, but the point with a DVCS is that it does not dictate
>>> *how* that happens, and using the primary repo is only one of several
>>> useful ways.
>>>
>> Of course. I just don't want to have people think they *can't* use
>> the repo because so many people are promoting "just fork a clone and
>> publish it elsewhere!". It sends the wrong message. We want people
>> to join the project, not be sent away from it.
>>
> Using a DVCS means that the project is greater than the primary repo.
>
> Publishing pcb work outside the primary repo is just publishing
> elsewhere, but it's still work within the project.
>
> Personally I'm fond of the approach to have individual repositories
> for active developers, hosted next to the primary repo. github does
> sortof that, the (maybe only? I prefer self-hosting) nice thing about
> github is that it's easy to see relationships between repos.
>
>
> //Peter
>
>
Hi Peter,
I am aware how git works, it has quirks, it's not comfortable for everyone.
I do not like CVS, Hg, Bazaar and Subversion, they are no match for git,
and therefor gedasymbols is not for me, my stuff lives in github.
Better use your energy by opening a bug report in Lanchpad as to have a
dumping ground for patches.
Better use you energy in writing code, manuals, documentation, etc.
Life is to short for lengthy non constructive e-mail conversations
spiraling down, one reaction leads to another etc, etc, (ad nausea).
Kind regards,
Bert Timmerman.
- Raw text -