On 9 April 2013 19:30, Florian Rathgeber <florian.rathge...@gmail.com> 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 g...@bitbucket.org: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 g...@bitbucket.org: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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~fenics > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : fenics@lists.launchpad.net Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
