fenics team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

On 08/04/13 11:48, Garth N. Wells wrote:
> On 8 April 2013 15:46, Anders Logg <logg@xxxxxxxxx> wrote:
>> The conversion to git is now complete. (Thanks again to Florian for
>> helping us out with the scripting!) Here are some initial instructions
>> for how to access the new code.
>>
>> - The new repositories can be found here:
>>
>>   https://bitbucket.org/fenics-project
>>
>> - The repositories (here DOLFIN) can be cloned by:
>>
>>   git clone https://bitbucket.org/fenics-project/dolfin.git
>>
>> - Developers with write access should use:
>>
>>   git clone git@xxxxxxxxxxxxx:fenics-project/dolfin.git
>>
>> - A full 1.2 GB archive of all the repositories, before and after
>>   conversion, before and after filtering, including all feature
>>   branches hosted on Launchpad can be downloaded from here:
>>
>>   http://fenicsproject.org/pub/archive/
>>
>>   Developers of feature branches should be able to clone their feature
>>   branches in git from the above address, push to bitbucket, and make
>>   pull requests.
>>
>> - A very good resource for how to use git can be found here:
>>
>>   http://git-scm.com/book
>>
>>   I suggest everyone reads it carefully, at least the first three
>>   chapters, but here's a very quick git introduction:
>>
>>   1. Same as hg/bzr with: git add, rm, commit, clone, push, pull, status
>>
>>   2. Files need to be staged before commit: git add foo, or use commit -a.
>>
>>   3. The whole bzr mess of needing to merge in a separate directory is
>>      gone. Just pull (or fetch + merge), commit, push as with hg.
>>
>>   4. Branches are very light-weight and in-directory, as opposed to
>>      bzr with one-directory-per-branch.
>>
> 
> A branch in a directory still works and is superfast (by copying files):
> 
>     git clone foo bar
> 
> To replicate the process used for cloning from a a remote server
> (which is slower)
> 
>     git clone foo file://bar

The difference is that the 1st will use hardlinks and the 2nd will
create copies of the objects in the repository. Note that in both cases
the repository is *not* shared i.e. it's *not* the same as using
multiple bzr branches with a shared repository. If you make changes to
one you have to sync them back to the other and vice versa. There is a
--shared option when cloning, but beware of unintended side effect of
git's automatic garbage collection (carefully read `git help clone`).

But even when using that, the 2 repositories do *not* share state. If
you real want them to, you can use a setup as described in this blog
post: http://www.devslashzero.com/node/20

Florian

> Garth
> 
>> - Work in progress: new mailing list, moving questions to
>>   stackexchange, closing down Launchpad pages, moving issues,
>>   downloading copies of tarballs from Launchpad and archive on web
>>   page. Please comment and contribute.
>>
>> --
>> Anders

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature