fenics team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

On 08/04/13 18:14, Anders Logg wrote:
> On Mon, Apr 08, 2013 at 05:44:19PM +0100, Florian Rathgeber wrote:
>> 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
> 
> The model described in [1] with 'dev' and 'master' branches in the
> canonical repository looks like an attractive model.
> 
> Is [1] the same as [2]?

Yes, [2] is only a set of git extensions to simplify working with [1].

Florian

> --
> Anders

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