fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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

--
Anders