Subject: [Fenics] Git repositories

From: Anders Logg <[email-masked]>
Date: Mon, 8 Apr 2013 09:46:17 +0200

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-masked]:fenics-project/dolfin.git

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

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

--
Anders

---

From: Florian Rathgeber <[email-masked]>
Date: Mon, 08 Apr 2013 11:40:00 +0100

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

There's no harm always cloning via SSH.

> 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-masked]: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

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

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 8 Apr 2013 18:48:47 +0800

>      bzr with one-directory-per-branch.

A branch in a directory still works and is superfast (by copying files):

    git clone foo bar

To replicate the process used for cloning from a a remote server
(which is slower)

    git clone foo file://bar

Garth

> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp

---

From: Florian Rathgeber <[email-masked]>
Date: Mon, 08 Apr 2013 17:10:04 +0100

> To replicate the process used for cloning from a a remote server

The difference is that the 1st will use hardlinks and the 2nd will
create copies of the objects in the repository. Note that in both cases
the repository is *not* shared i.e. it's *not* the same as using
multiple bzr branches with a shared repository. If you make changes to
one you have to sync them back to the other and vice versa. There is a
--shared option when cloning, but beware of unintended side effect of
git's automatic garbage collection (carefully read `git help clone`).

But even when using that, the 2 repositories do *not* share state. If
you real want them to, you can use a setup as described in this blog
post: http://www.devslashzero.com/node/20

Florian

---

From: Florian Rathgeber <[email-masked]>
Date: Mon, 08 Apr 2013 17:44:19 +0100

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

Florian

---

From: Anders Logg <[email-masked]>
Date: Mon, 8 Apr 2013 19:14:54 +0200

> [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]?

--
Anders

---

From: Florian Rathgeber <[email-masked]>
Date: Mon, 08 Apr 2013 19:14:51 +0100

> canonical repository looks like an attractive model.

Yes, [2] is only a set of git extensions to simplify working with [1].

Florian

---

From: Anders Logg <[email-masked]>
Date: Mon, 8 Apr 2013 23:13:51 +0200

> 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

---

From: Florian Rathgeber <[email-masked]>
Date: Tue, 09 Apr 2013 12:30:49 +0100

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

> 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

---

From: Anders Logg <[email-masked]>
Date: Tue, 9 Apr 2013 13:35:48 +0200

> realised it's completely pointless right now since master is

In what way? The references are missing but otherwise it seems to work
fine.

> developers and everyone needs to adopt it.

Yes.

> requests against the dev branch (or a realease or hotfix branch if

ok.

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Thu, 11 Apr 2013 12:15:41 +0800

> requests against the dev branch (or a realease or hotfix branch if

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