fenics team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

On 08/04/13 22:13, Anders Logg wrote:
> On Mon, Apr 08, 2013 at 07:14:51PM +0100, Florian Rathgeber wrote:
>> 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.

The imho most important step before people can start actually working
with git is pointing the buildbots to the new repositories and getting
them green. I just tried merging the git master into our FFC branch but
realised it's completely pointless right now since master is
comprehensively broken.

>>>> 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].
> 
> I read [1] again. I really like this development model. I don't view
> it as heavyweight at all. It seems to make the development process
> easy and smooth, for example being able to quickly fix bugs in
> development releases without stalling development in the 'develop'
> branch or in feature branches.
> 
> Another good thing is that someone obviously thought this through and
> others are using it (to the point that special tools, documentation
> and graphics have been created to support it, which means we don't
> need to invent our own).
> 
> I think we should adopt this model.

Agreed, I think it's a proven and well documented model. However (as any
other workflow) it requires a level of discipline among the core
developers and everyone needs to adopt it.

For external contributions it's easy to enforce: only allow pull
requests against the dev branch (or a realease or hotfix branch if
applicable).

Florian

> --
> Anders

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