fenics team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

On 08/04/13 11:40, Florian Rathgeber wrote:
> On 08/04/13 08:46, Anders Logg 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
> 
> There's no harm always cloning via SSH.
> 
>> - 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.
> 
> To be clear: We have migrated all feature branches for all FEniCS
> projects as they were on launchpad on Friday afternoon. So if your
> branch was up-to-date on launchpad you don't need to do any conversion
> yourself (in fact you shouldn't).
> 
> A DOLFIN branch lp:~user/dolfin/mybranch has been converted to the git
> branch user/mybranch (similar for the other projects i.e. the project
> name has been left out).
> 
> To get your branch (again assuming DOLFIN), do the following:
> 
> # clone DOLFIN (only contains the master branch, formerly trunk)
> $ git clone git@xxxxxxxxxxxxx:fenics-project/dolfin.git
> $ cd dolfin
> 
> # Add a git remote called archive and select only your specific branch
> $ git remote add -t user/mybranch archive
> http://fenicsproject.org/pub/archive/fenics-bzr-to-git-conversion-2013/repositories/git/dolfin.filtered.git
> $ git fetch archive
> 
> # List local and remote branches
> $ git branch -av
> 
> # Look at the history graph and check your branch's ancestry is correct
> $ git log --graph --oneline --annotate --decorate --all
> 
> # If everything is fine, check out your branch and profit!
> $ git checkout user/mybranch
> 
> If you want to pull down multiple branches or don't remember your
> branch names you can also fetch all branches by omitting the -t
> argument when adding the git remote. You can then list all branch
> names and pick the ones you want to continue working on.
> 
> For other projects, replace dolfin by the project name (but see the
> notice below). All repositories are archived at
> http://fenicsproject.org/pub/archive/fenics-bzr-to-git-conversion-2013/repositories/git/
> 
> IMPORTANT: We rewrote the history and stripped files for DOLFIN, FFC
> and UFC, which is why you *have to* use {dolfin,ffc,ufc}.filtered.git
> but {dorsal,ferari,fiat,instant,ufl}.git. Please be very careful not
> to accidentally import the non-filtered history of those 3 projects!
> 
> Florian
> 
>> - 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.
>>
>> - 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.

Now is the time to discuss worflows to use with the new repositories.
There is the opportunity to keep more than the master branch active in
the "canonical" repository. A popular workflow is called gitflow [1] and
there is a command line tool extending git for working with it [2].

Everyone without push access to the canonical repositories will have to
work in their own forks and make pull requests upstream. The core
developers can decide on a policy on which branches are to be kept in
the canonical repositories vs. personal forks.

[1]: http://nvie.com/posts/a-successful-git-branching-model/
[2]: https://github.com/nvie/gitflow

Florian

>> -- Anders

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