Mail Archives: geda-user/2014/04/16/22:52:18
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
- Raw text -