Mail Archives: geda-user/2014/04/16/21:06:50
DJ Delorie wrote:
> > It's even simpler than that, thanks to git.
> >
> > > git://git.geda-project.org/pcb.git
> >
> > Just clone this, write the code, and then publish it somewhere.
>
> How is creating and publishing a new repo elsewhere simplier than
> using an existing repo? Especially since Bert already has write
> privs in geda-project's repo?
The original question was not from Bert, asking what a process might
look like. Bert replied with steps that work great for him, but I
wanted to clarify that requesting write access to the main repo is
absolutely not a neccessity for doing pcb development.
> I understand that git (or any SCM) lets you make copies of repos all
> over the internet, but just because you CAN do it doesn't always mean
> you SHOULD do it.
Funny you should write that. :) It is in fact impossible NOT to make
a copy of a git repository if you want to actually work with it.
git clone is very accurately named; every clone is indeed a complete
clone of the cloned repo, and that is definitely how it should be.
This is a key feature of distributed version control, and many who
are used to centralized version control struggle with wrapping head
around it.
The big difference is that DVCS repos are *intended* to be cloned,
for purely technical reasons, and without implying anything
whatsoever about the intent of those clones.
This is a significant difference to a centralized VCS, where having a
copy of the repo implies a competing centralized point of version
control; ie. what is traditionally called a project fork.
DVCS repo clones/copies do not carry any such implied intent, because
all of those repos are equal.
> It would be much easier to find all gEDA-related
> development, for example, if it happened in the gEDA repository.
A DVCS such as git allows powerful workflows where development is
very conveniently structured. Especially a project such as
integrating freerouter into pcb would do well living in its own
branch somewhere, and that somewhere shouldn't neccessarily be the
main pcb repository as long as the work is ongoing and the direction,
requirements or side effects are still not fully known.
It's a good thing to publish ongoing work as early as possible, it
translates to a more efficient development effort, but on the other
hand, early work doesn't neccessarily belong in the primary project
repository, even if it has a branch of its own.
Publishing commits for a DVCS repo is always distinct from any intent
to manifest a competing project. The latter does imply the former,
but never the other way around.
Publishing ongoing work on top of pcb.git master either using some
hosting or by patches to the mailing list in the general case means
that someone is proposing changes to the current pcb.git state.
Publishing the commits on one hand solicits review, but at the same
time it is also already enough for project maintainers to include the
proposed commits into the project - and trivially so using git fetch,
cherry-pick and am, if the commits are published using git's own
tools.
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.
//Peter
- Raw text -