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. >> >> 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
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
