fenics team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 9 April 2013 19:30, Florian Rathgeber <florian.rathgeber@xxxxxxxxx> wrote:
> 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).
>

I'm happy to adopt this model, and to make it easy for all involved I
suggest that we start by following the PETSc instructions for this
model, which are very clear and are for

(a) Users - https://bitbucket.org/petsc/petsc/wiki/Home

(b) Contributors -
https://bitbucket.org/petsc/petsc/wiki/pull-request-instructions-git

(c) Developers - https://bitbucket.org/petsc/petsc/wiki/quick-dev-git
(quick), https://bitbucket.org/petsc/petsc/wiki/developer-instructions-git
(detailed)

We can evolve over time if necessary.

Garth

> Florian
>
>> --
>> Anders
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp
>