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 [email protected]: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 [email protected]: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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : [email protected] Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
