Subject: [Fenics] Deadline for merge of development branches

From: Anders Logg <[email-masked]>
Date: Mon, 25 Mar 2013 23:45:27 +0100

In reference to previous discussions on the FEniCS mailing list, are
there any objections to the proposal posted earlier today regarding a
freeze for branch merging before the pending git conversion?

In detail, the suggestion is to

- Set a window for Friday this week to merge in development branches

- Freeze all repositories during the weekend

- Convert everything to git including file stripping

- New branches will need to be created on the git side starting Monday

- Old branches on Launchpad will need be be abandoned

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 26 Mar 2013 09:31:57 +0800

> - New branches will need to be created on the git side starting Monday

Do you mean start using the git repositories on Monday, i.e. convert
over the weekend?

Garth

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

---

From: "Marie E. Rognes" <[email-masked]>
Date: Tue, 26 Mar 2013 06:39:25 +0100

This week and coming weekend (including Monday) is Easter holiday in 
Norway in general and at Simula in particular. Please postpone deadlines 
by (at least) a week. No other objections.

--
Marie

---

From: Anders Logg <[email-masked]>
Date: Tue, 26 Mar 2013 08:03:55 +0100

> Do you mean start using the git repositories on Monday, i.e. convert

Yes.

--
Anders

---

From: Anders Logg <[email-masked]>
Date: Tue, 26 Mar 2013 08:05:15 +0100

On Tue, Mar 26, 2013 at 06:39:25AM +0100, Marie E. Rognes wrote:
> Norway in general and at Simula in particular. Please postpone
> deadlines by (at least) a week. No other objections.

ok: freeze 5 April, new repos 8 April.

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 26 Mar 2013 19:01:42 +0800

On 26 March 2013 13:39, Marie E. Rognes <[email-masked]> wrote:
>
> This week and coming weekend (including Monday) is Easter holiday in Norway
> in general and at Simula in particular. Please postpone deadlines by (at
> least) a week. No other objections.
>

Does that mean that you have branches that you want to merge? Unless
there are branches to be merged, I don't see the benefit of a delay.

Garth

---

From: David Ham <[email-masked]>
Date: Tue, 26 Mar 2013 15:34:16 +0000

Hi All,

I imagine that Florian will have something to say about this, but the
ffc pyop2 branch may be an issue here.
lp:~mapdes/ffc/pyop2

I would imagine that merging this will, at least, require discussion.
The relevant people are likely to be less around for the next couple
of weeks due to Easter.

The preferred option would be to carry the branch on on github rather
than a shotgun merge to trunk. However as the lighthouse said to the
aircraft carrier...

David

-- 
Dr David Ham
Department of Computing
Imperial College London

http://www.imperial.ac.uk/people/david.ham

---

From: Anders Logg <[email-masked]>
Date: Tue, 26 Mar 2013 16:52:21 +0100

If I understood Florian correctly, he didn't mind starting the branch
over from scratch. If you merge it with trunk just before the
conversion to hg, you could easily recreate your branch on the git
side. The only downside is that you will have to drop your history.
Is it important to keep it? Perhaps for credit and blame?

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 26 Mar 2013 23:55:43 +0800

> ffc pyop2 branch may be an issue here.

This may be fine because I don't believe that we're planning to
prune/rewrite the FFC history at this stage (I think that it's required,
but it's easier to delay until later compared to the DOLFIN repo). We need
Florian to tell us if this will work.

Garth

> On 26 March 2013 11:01, Garth N. Wells <[email-masked] <javascript:;>>
> wrote:
> > On 26 March 2013 13:39, Marie E. Rognes <[email-masked] <javascript:;>>
> wrote:
> >>
> Norway
> >>> Post to     : [email-masked] <javascript:;>
> >> Post to     : [email-masked] <javascript:;>
> > Post to     : [email-masked] <javascript:;>

-- 
Garth N. Wells
Department of Engineering, University of Cambridge
http://www.eng.cam.ac.uk/~gnw20

---

From: Florian Rathgeber <[email-masked]>
Date: Tue, 26 Mar 2013 16:04:27 +0000

On 26/03/13 15:55, Garth N. Wells wrote:
> I imagine that Florian will have something to say about this, but
> the ffc pyop2 branch may be an issue here. lp:~mapdes/ffc/pyop2
> 
> 
> prune/rewrite the FFC history at this stage (I think that it's
> required, but it's easier to delay until later compared to the
> DOLFIN repo). We need Florian to tell us if this will work.

As I mentioned earlier there is also the route of importing the
feature branch into the non-filtered repository (where the marks files
are "intact") and then transplanting the branch (with all its history
etc.) to the rewritten repository via a git rebase. It's a bit more
laborious and you should know what you're doing, but I've done it
before. We've rewritten both the OP2 and the PyOP2 repositories
halfway through the project. It's just not something I would want to
ask a git novice to do by themselves.

Florian

> Garth
> 
> 
> I would imagine that merging this will, at least, require
> discussion. The relevant people are likely to be less around for
> the next couple of weeks due to Easter.
> 
> The preferred option would be to carry the branch on on github
> rather than a shotgun merge to trunk. However as the lighthouse
> said to the aircraft carrier...
> 
> David
> 
> On 26 March 2013 11:01, Garth N. Wells <[email-masked] 
> <javascript:;>> wrote:
>> On 26 March 2013 13:39, Marie E. Rognes <[email-masked]
> <javascript:;>> wrote:
>>> 
>>> This week and coming weekend (including Monday) is Easter
>>> holiday
> in Norway
>>> in general and at Simula in particular. Please postpone
>>> deadlines
> by (at
>> Does that mean that you have branches that you want to merge?
>> Unless there are branches to be merged, I don't see the benefit
>> of a delay.
>> 
>> Garth
>> 
>>> -- Marie
>>> 
>>> 
>>> 
>>>> In reference to previous discussions on the FEniCS mailing
>>>> list, are there any objections to the proposal posted earlier
>>>> today
> regarding a
>>>> - New branches will need to be created on the git side
>>>> starting
> Monday
>>>> 
>>>> -- Anders

---

From: Anders Logg <[email-masked]>
Date: Tue, 26 Mar 2013 17:11:32 +0100

> ask a git novice to do by themselves.

I would say it's up to you. I don't care much about the history of
feature branches and no one else has indicated that it is important to
provide a route for converting feature branches. So if it is important
to the ffc/pyop2 branch, I can follow your instructions.

But I would assume that requires merging the ffc/pyop2 branch *now*,
before the conversion, and it might not be ready?

For the FFC branch, I would like to strip out all the old .h reference
files. Then add them back again right after the conversion.

--
Anders

---

From: Florian Rathgeber <[email-masked]>
Date: Tue, 26 Mar 2013 16:23:30 +0000

On 26/03/13 16:11, Anders Logg wrote:
>>> I imagine that Florian will have something to say about this,
>>> but the ffc pyop2 branch may be an issue here.
>>> lp:~mapdes/ffc/pyop2
>>> 
>>> 
>>> This may be fine because I don't believe that we're planning
>>> to prune/rewrite the FFC history at this stage (I think that
>>> it's required, but it's easier to delay until later compared to
>>> the DOLFIN repo). We need Florian to tell us if this will
>>> work.
>> 
>> feature branch into the non-filtered repository (where the marks
>> files are "intact") and then transplanting the branch (with all
>> its history etc.) to the rewritten repository via a git rebase.
>> It's a bit more laborious and you should know what you're doing,
>> but I've done it before. We've rewritten both the OP2 and the
>> PyOP2 repositories halfway through the project. It's just not
>> something I would want to ask a git novice to do by themselves.
> 
> feature branches and no one else has indicated that it is important
> to provide a route for converting feature branches. So if it is
> important to the ffc/pyop2 branch, I can follow your instructions.
> 
> But I would assume that requires merging the ffc/pyop2 branch
> *now*, before the conversion, and it might not be ready?

No, I can do that later. The reason the branch isn't quite ready is
that we don't (yet) have tests for the features we're adding so it
would be hard for the FFC developers to notice if they break anything
for us post merge. We're passing the existing FFC test suite though.

But there is another option to get round the entire problem: simply
importing *all* feature branches before doing the filtering. That
should (unproven claim, I'll need to read the docs) be scriptable
through the launchpad API and the branch import script that I've
already written. But I was assuming you didn't want to necessarily
migrate all the branches, so I didn't focus on this option in prior
discussions.

> For the FFC branch, I would like to strip out all the old .h
> reference files. Then add them back again right after the
> conversion.

That is certainly doable, but so far my impression was that Martin
objected to this plan?

Florian

>>> discussion. The relevant people are likely to be less around
>>> for the next couple of weeks due to Easter.
>>> 
>>> rather than a shotgun merge to trunk. However as the
>>> lighthouse said to the aircraft carrier...
>>> 
>>> David
>>> 
>>>> Does that mean that you have branches that you want to
>>>> merge? Unless there are branches to be merged, I don't see
>>>> the benefit of a delay.
>>>> 
>>>> Garth
>>>> 
>>>>> -- Marie
>>>>> 
>>>>> 
>>>>> 
>>>>>> In reference to previous discussions on the FEniCS
>>>>>> mailing list, are there any objections to the proposal
>>>>>> posted earlier today
>>> regarding a

---

From: Anders Logg <[email-masked]>
Date: Tue, 26 Mar 2013 18:02:54 +0100

> for us post merge. We're passing the existing FFC test suite though.

ok. So is it ok for your branch if we just do the conversion without
the marks files?

> migrate all the branches, so I didn't focus on this option in prior

That sounds like a very bad idea. I assume at least half of those
branches will never get merged.

> That is certainly doable, but so far my impression was that Martin

We just made a release so I think we are quite comfortable that things
are working at the moment. If we pass all our regression tests
now. Then convert the repository, copy back the references, we should
not need to step back and look for errors introduced previous to the
conversion. I think what Martin objected to was moving the references
outside of the repository and I agree on that. So we strip the
repository from the references and do the conversion, then add back
the references.

Another option would be to wait with stripping data from the FFC
repository until a new a better test suite is in place, but that
requires going through this process again at a later time. I'd rather
have it done now and just move on.

--
Anders

---

From: Florian Rathgeber <[email-masked]>
Date: Tue, 26 Mar 2013 21:57:00 +0000

> ok. So is it ok for your branch if we just do the conversion without

Having the marks file will definitely speed things up in case we're not
rewriting FFC. But if we're deciding to filter FFC and therefore
invalidate the marks files I can do without, yes.

> branches will never get merged.

I assumed you would say that, hence I didn't suggest it earlier. However
there is another option: not pushing the repo with *all* the branches to
Bitbucket, but keeping it (read-only) on the FEniCS web server, so
anyone who would like to import and continue working on their feature
branch can pull it from there instead of migrating themselves.

> repository from the references and do the conversion, then add back

That's doable. We could even define a cut-off point (like 60 days) for
which to keep the references and remove everything prior to this point.

> have it done now and just move on.

I'd advise against doing the rewrite at a later point. We could only do
it for OP2 because we were in a much more "controlled environment" where
we knew all the contributors.

Would it then make sense to use the 1.2 release as the base for the
conversion for all FEniCS components?

Florian

---

From: Anders Logg <[email-masked]>
Date: Tue, 26 Mar 2013 23:32:13 +0100

> invalidate the marks files I can do without, yes.

ok. So from what I've heard so far, it seems there are really no
strong objections to converting to git in combination with stripping,
and forcing all branches to start from scratch on the git side.

I wouldn't mind making it easier to transition feature branches, but
it seems very difficult to do so.

> branch can pull it from there instead of migrating themselves.

Yes, the plan is to store all possible data there. The bzr and git
branches for all the repos at the time of conversion, including all
the scripting that went into it.

> which to keep the references and remove everything prior to this point.

ok. I think we can just strip without the cut-off point.

> conversion for all FEniCS components?

No, there have been fixes made to trunk since, like removal of meshes,
generated code, downloading scripts etc.

--
Anders

---

From: Florian Rathgeber <[email-masked]>
Date: Wed, 27 Mar 2013 15:23:53 +0000

On 26/03/13 22:32, Anders Logg wrote:
>>>>>>> I imagine that Florian will have something to say about
>>>>>>> this, but the ffc pyop2 branch may be an issue here. 
>>>>>>> lp:~mapdes/ffc/pyop2
>>>>>>> 
>>>>>>> 
>>>>>>> This may be fine because I don't believe that we're
>>>>>>> planning to prune/rewrite the FFC history at this stage
>>>>>>> (I think that it's required, but it's easier to delay
>>>>>>> until later compared to the DOLFIN repo). We need
>>>>>> As I mentioned earlier there is also the route of
>>>>>> importing the feature branch into the non-filtered
>>>>>> repository (where the marks files are "intact") and then
>>>>>> transplanting the branch (with all its history etc.) to
>>>>>> the rewritten repository via a git rebase. It's a bit
>>>>>> more laborious and you should know what you're doing, but
>>>>>> I've done it before. We've rewritten both the OP2 and
>>>>>> the PyOP2 repositories halfway through the project. It's
>>>>>> just not something I would want to ask a git novice to do
>>>>>> by themselves.
>>>>> 
>>>>> I would say it's up to you. I don't care much about the
>>>>> history of feature branches and no one else has indicated
>>>>> that it is important to provide a route for converting
>>>>> feature branches. So if it is important to the ffc/pyop2
>>>>> branch, I can follow your instructions.
>>>>> 
>>>>> But I would assume that requires merging the ffc/pyop2
>>>>> branch *now*, before the conversion, and it might not be
>>>>> ready?
>>>> 
>>>> No, I can do that later. The reason the branch isn't quite
>>>> ready is that we don't (yet) have tests for the features
>>>> we're adding so it would be hard for the FFC developers to
>>>> notice if they break anything for us post merge. We're
>>>> passing the existing FFC test suite though.
>>> 
>>> ok. So is it ok for your branch if we just do the conversion
>>> without the marks files?
>> 
>> Having the marks file will definitely speed things up in case
>> we're not rewriting FFC. But if we're deciding to filter FFC and
>> therefore invalidate the marks files I can do without, yes.
> 
> strong objections to converting to git in combination with
> stripping, and forcing all branches to start from scratch on the
> git side.
> 
> I wouldn't mind making it easier to transition feature branches,
> but it seems very difficult to do so.

Yes, I still haven't found a satisfactory solution that is safe in all
cases. The only safe solution I can think of at the moment is:
1) bzr -> git convert trunk with export of marks files
2) import *all* feature branches
3) filter the entire history, removing files we don't want
4) archive the new git repo with *all* branches on the fenics
webserver with public read-only access
5) push only the master branch (bzr trunk) to bitbucket
6) instruct people how they can fetch their feature branches into
their own (local) clones and then push to their own forks

I've asked a question on SO, maybe someone has an idea:
http://stackoverflow.com/q/15660467/396967

I'm currently discussing with Jelmer on #bzr: There's yet another
conversion route using bzr dpush and/or bzr serve --git. That doesn't
seems very promising either though: it's mostly designed to allow
contributing to git projects using bzr (and we want the opposite).

>>>> But there is another option to get round the entire problem:
>>>> simply importing *all* feature branches before doing the
>>>> filtering. That should (unproven claim, I'll need to read the
>>>> docs) be scriptable through the launchpad API and the branch
>>>> import script that I've already written. But I was assuming
>>>> you didn't want to necessarily migrate all the branches, so I
>>>> didn't focus on this option in prior discussions.
>>> 
>>> That sounds like a very bad idea. I assume at least half of
>>> those branches will never get merged.
>> 
>> I assumed you would say that, hence I didn't suggest it earlier.
>> However there is another option: not pushing the repo with *all*
>> the branches to Bitbucket, but keeping it (read-only) on the
>> FEniCS web server, so anyone who would like to import and
>> continue working on their feature branch can pull it from there
>> instead of migrating themselves.
> 
> branches for all the repos at the time of conversion, including
> all the scripting that went into it.
> 
>>>>> For the FFC branch, I would like to strip out all the old
>>>>> .h reference files. Then add them back again right after
>>>>> the conversion.
>>>> 
>>>> That is certainly doable, but so far my impression was that
>>>> Martin objected to this plan?
>>> 
>>> We just made a release so I think we are quite comfortable that
>>> things are working at the moment. If we pass all our regression
>>> tests now. Then convert the repository, copy back the
>>> references, we should not need to step back and look for errors
>>> introduced previous to the conversion. I think what Martin
>>> objected to was moving the references outside of the repository
>>> and I agree on that. So we strip the repository from the
>>> references and do the conversion, then add back the
>>> references.
>> 
>> That's doable. We could even define a cut-off point (like 60
>> days) for which to keep the references and remove everything
>> prior to this point.
> 

OK

>>> Another option would be to wait with stripping data from the
>>> FFC repository until a new a better test suite is in place, but
>>> that requires going through this process again at a later time.
>>> I'd rather have it done now and just move on.
>> 
>> I'd advise against doing the rewrite at a later point. We could
>> only do it for OP2 because we were in a much more "controlled
>> environment" where we knew all the contributors.
>> 
>> Would it then make sense to use the 1.2 release as the base for
>> the conversion for all FEniCS components?
> 
> No, there have been fixes made to trunk since, like removal of
> meshes, generated code, downloading scripts etc.

OK

Florian

---

From: Anders Logg <[email-masked]>
Date: Wed, 27 Mar 2013 22:40:52 +0100

> their own (local) clones and then push to their own forks

What exactly does it mean to import all branches? Will it somehow
affect repository that we put on bitbucket?

> contributing to git projects using bzr (and we want the opposite).

ok. My main take on this right now is that I haven't heard anyone
saying that it's important to convert the feature branches, so I'm not
going to spend a lot of time thinking about it. :-) But as before, if
you come up with a good solution, I wouldn't mind.

I've moved the conversion script from the old gist to bitbucket. The
plan is to use this script to do the conversion:

https://bitbucket.org/fenics-project/fenics-bzr-to-git-conversion-2013

This should happen next weekend.

--
Anders

---

From: Roland Siegbert <[email-masked]>
Date: Thu, 28 Mar 2013 02:46:49 +0100

> affect repository that we put on bitbucket?
It will include all branches directly instead of splitting it in a two
step procedure with the filtering in between the two steps. As far, as I
understood the discussion, that's a better solution than filtering the
trunk/master branch - to get rid of the obsolete files - and attach the
branches afterwards using some kind of yet unknown git voodoo.

>> http://stackoverflow.com/q/15660467/396967

I suggest like the following as a first draft for the conversion script:

<code>
mkdir dolfin.git
cd dolfin.git
git init --bare

bzr fast-export --export-marks=../marks.bzr ~/src/dolfin/master \
   | git fast-import --export-marks=../marks.git

<repeat n-branches-times:>
bzr fast-export --marks=../marks.bzr --git-branch=<branchname> \
   ~/src/dolfin/<branchname> | git fast-import \
   --import-marks=../marks.git --export-marks=../marks.git
<endrepeat>

#As soon as this is done: Filter the history as planned, test it and
then upload it to the new location:

git remote add <bitbucket repolocation>
git push --all # push all branches
</code>

Hope, I could help.

Best,

Roland

---

From: Anders Logg <[email-masked]>
Date: Thu, 28 Mar 2013 07:35:56 +0100

> branches afterwards using some kind of yet unknown git voodoo.

It still seems very strange to import all branches, considering most
of them will likely never be merged and perhaps only a couple of them
are ready for merge.

> git push --all # push all branches

That would create a repository on bitbucket containing all the
branches. I don't see why we should push anything but trunk.

And still no one with a feature branch has claimed that it would be a
problem to start with a fresh clone. The only thing we would lose
would be the history of the feature branches.

--
Anders

---

From: Roland Siegbert <[email-masked]>
Date: Thu, 28 Mar 2013 09:03:50 +0100

> would be the history of the feature branches.
That's strange indeed. I would scream out loud, if a repository
migrates and my feature branch and all the work buried in there would
be dropped in the process, except the distance is a commit of five
lines or less...

Roland

---

From: Anders Logg <[email-masked]>
Date: Thu, 28 Mar 2013 09:11:36 +0100

> be dropped in the process, except the distance is a commit of five

The changes can easily be patched and then committed on the git side.
The only thing we lose is the internal history of how the patch came
about, which seems like a small issue to me.

--
Anders

---

From: Florian Rathgeber <[email-masked]>
Date: Thu, 28 Mar 2013 09:28:13 +0000

> of them will likely never be merged and perhaps only a couple of them

I wasn't suggesting that: see 4) and 5) above: the repo with all
branches is only for archiving on the FEniCS web server. Only master
(formerly trunk) will be pushed to BitBucket. And if someone comes back
in 2 years and wants to continue working on their feature branch, we
point them to 6).

>> I suggest like the following as a first draft for the conversion script:

That is pretty much exactly what my import-branch script does :)

> branches. I don't see why we should push anything but trunk.

Yes, I agree, only trunk should go to BitBucket. Replace the final 2
lines by:

rsync -a . fenicsproject.org:/path/to/archive/dolfin.git
git remote add origin [email-masked]:fenics-project/dolfin.git
git push origin master

And repeat the process for all the other FEniCS components...

> would be the history of the feature branches.

That might be because they're not reading this list and aren't even
aware of the migration plans.

Florian

---

From: Anders Logg <[email-masked]>
Date: Thu, 28 Mar 2013 11:05:00 +0100

> in 2 years and wants to continue working on their feature branch, we

I think if they come back in 2 years, we should instruct them to start
from scratch.

> And repeat the process for all the other FEniCS components...

ok.

> aware of the migration plans.

Perhaps...

--
Anders

---

From: "Marie E. Rognes" <[email-masked]>
Date: Thu, 28 Mar 2013 22:12:44 +0100

> ok: freeze 5 April, new repos 8 April.

Sounds good.

--
Marie

---

From: "Marie E. Rognes" <[email-masked]>
Date: Thu, 28 Mar 2013 22:13:22 +0100

> Does that mean that you have branches that you want to merge?

Potentially, yes.

--
Marie

> Unless

---

From: Florian Rathgeber <[email-masked]>
Date: Thu, 28 Mar 2013 22:06:11 +0000

On 27/03/13 21:40, Anders Logg wrote:
>>> On Tue, Mar 26, 2013 at 09:57:00PM +0000, Florian Rathgeber
>>> wrote: ok. So from what I've heard so far, it seems there are
>>> really no strong objections to converting to git in combination
>>> with stripping, and forcing all branches to start from scratch
>>> on the git side.
>>> 
>>> I wouldn't mind making it easier to transition feature
>>> branches, but it seems very difficult to do so.
>> 
>> Yes, I still haven't found a satisfactory solution that is safe
>> in all cases. The only safe solution I can think of at the moment
>> is: 1) bzr -> git convert trunk with export of marks files 2)
>> import *all* feature branches 3) filter the entire history,
>> removing files we don't want 4) archive the new git repo with
>> *all* branches on the fenics webserver with public read-only
>> access 5) push only the master branch (bzr trunk) to bitbucket 6)
>> instruct people how they can fetch their feature branches into 
>> I'm currently discussing with Jelmer on #bzr: There's yet
>> another conversion route using bzr dpush and/or bzr serve --git.
>> That doesn't seems very promising either though: it's mostly
>> designed to allow contributing to git projects using bzr (and we
>> want the opposite).
> 
> saying that it's important to convert the feature branches, so I'm
> not going to spend a lot of time thinking about it. :-) But as
> before, if you come up with a good solution, I wouldn't mind.
> 
> I've moved the conversion script from the old gist to bitbucket.
> The plan is to use this script to do the conversion:
> 

I've updated the conversion script and have it call another script to
import all branches registered on launchpad for the given project. So
when running the script you end up with a git repository for the
project which contains *all* bzr branches from launchpad migrated to
git with the correct ancestry relationships etc. An additional
advantage is that obsolete branches fully "contained" within other
branches are skipped.

Now we need to decide the final list of files to strip for DOLFIN and
FFC. Presumably there's no other projects we want to filter history?
Then it's relatively straightforward to add a script to strip those
files from history.

Florian

---

From: Anders Logg <[email-masked]>
Date: Sat, 30 Mar 2013 08:55:01 +0100

> advantage is that obsolete branches fully "contained" within other

Great thanks. I haven't tried it yet but it looks good. So if I
understand correctly, this will result in:

1. A repository on bitbucket which is only a stripped version of the
   master (not containing any relationship to the other branches).

2. Git branches for all the Launchpad branches which can be used as
   starting points for those who wish to migrate their branches to
   git now.

3. Developers who want to migrate branches will have to immediately
   get their new git branches and continue work in those. Continued
   work on the Launchpad side after the conversion will break stuff.

> Then it's relatively straightforward to add a script to strip those

Yes. Let's try to finalize the strip lists for DOLFIN and FFC before
next weekend.

--
Anders

---

From: Florian Rathgeber <[email-masked]>
Date: Sat, 30 Mar 2013 10:10:47 +0000

>    master (not containing any relationship to the other branches).

The script doesn't do any filtering/history rewriting. I'll write a
separate script doing the filtering for DOLFIN and FFC. For these I
think we should keep archives of both the filtered and non-filtered
repositories on the FEniCS webserver.

But only the master branch will be pushed to BitBucket.

>    starting points for those who wish to migrate their branches to

Yes, everyone who wants to fetch the git branch converted from their
former launchpad bzr branch can do so by adding the archive repository
as a git remote:

$ git remote add -t branch-name archive
http://fenicsproject.org/path/to/dolfin.git
$ git fetch archive
$ git checkout branch-name

>    work on the Launchpad side after the conversion will break stuff.

They will need to migrate any further changes they make to their
launchpad branches after the cut-off point for the conversion by hand.
So yes, they should immediately start working on the git branches.

> Yes. Let's try to finalize the strip lists for DOLFIN and FFC before

OK.

Florian

---

From: Anders Logg <[email-masked]>
Date: Sat, 30 Mar 2013 19:09:27 +0100

> repositories on the FEniCS webserver.

So how will that subsequent filtering affect the converted branches?
Won't that make those branches impossible to merge?

ok.

ok.

--
Anders