Subject: Re: [Fenics] Cleanup of repositories

From: Jan Blechta <[email-masked]>
Date: Mon, 25 Mar 2013 15:15:32 +0100

I proposed two tiny changes to DOLFIN. The one in
lp:~blechta/dolfin/harmonic_smoothing is ready. But the second in
lp:~blechta/dolfin/keep_diagonal needs running newly introduced test in 
test/unit/la/python/Matrix.py with PETScCusp and Epetra backends. Is
somebody able to try it?

Regarding cleanup of repo do I understand it correctly that procedure
for keeping feature branch up to date is 

1. merge trunk on launchpad into feature branch
2. make it working and commit
3. convert to git

It this is the way why this could not be performed arbitrarily later?

Jan

---

From: Anders Logg <[email-masked]>
Date: Mon, 25 Mar 2013 15:18:57 +0100

> test/unit/la/python/Matrix.py with PETScCusp and Epetra backends. Is

Thanks. We will look at it.

> It this is the way why this could not be performed arbitrarily later?

The problem is that we want to do two things: convert to git and at
the same time remove certain files from the history, and we don't know
how to do those two in combination (assuming I understand correctly
the latest message from our git master Florian).

Therefore, we will give everyone a chance to merge things that can be
merged now, then do the conversion and file stripping, and after that
the old branches on Launchpad must all be abandonded and opened again
on Bitbucket as fresh new clones.

--
Anders

---

From: Jan Blechta <[email-masked]>
Date: Mon, 25 Mar 2013 23:05:16 +0100

On Mon, 25 Mar 2013 15:18:57 +0100
Anders Logg <[email-masked]> wrote:
> > lp:~blechta/dolfin/keep_diagonal needs running newly introduced
> > test in test/unit/la/python/Matrix.py with PETScCusp and Epetra
> > backends. Is somebody able to try it?
> 
> > Regarding cleanup of repo do I understand it correctly that
> > procedure for keeping feature branch up to date is
> >

It seems that you're talking about branches to be merged into trunk.
But I would rather like to know what to do with experimental branch
(which it not suitable for merging into trunk) to keep it alive,
synchronizable with trunk. Do I need to take some special actions to
prepare it to file stripping?

And what about plans to join UFC+UFL+FFC+Fiat into single repo? Will
they proceed after the conversion?

Jan

---

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

> prepare it to file stripping?

As far I understand, it is not possible to move experimental branches
from bzr to git in combination with file-stripping (unless you have
more than 1st degree black belt skills in git above Florian's).

So you will need to abandon your experimental branches and start them
over from scratch in git (and copy your changes over manually to the
new git branch).

> they proceed after the conversion?

Yes, we will work with the git repositories for a little while before
attempting any such merge (likely using subtrees).

--
Anders

---

From: Roland Siegbert <[email-masked]>
Date: Tue, 26 Mar 2013 12:20:18 +0100

> on Bitbucket as fresh new clones.
I don't know, if it was discussed already. But, it is possible to
"attach" existing (independent) branches to a previous
history/ancestor:

https://git.wiki.kernel.org/index.php/GraftPoint

However, I did that just once and had direct access to a local
gitolite server. Florian, do you have an opinion on this or another
idea? I remember there floating around 70+ branches.

Best,

Roland

---

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

On 26/03/13 11:20, Roland Siegbert wrote:
>> Therefore, we will give everyone a chance to merge things that
>> can be merged now, then do the conversion and file stripping, and
>> after that the old branches on Launchpad must all be abandonded
>> and opened again on Bitbucket as fresh new clones.
> gitolite server. Florian, do you have an opinion on this or
> another idea? I remember there floating around 70+ branches.

I have to admit grafts is one of the git features I've shied away from
so far, so please correct me if I get this wrong: In my understanding
grafts were created to allow you to "prepend" history to an
"artifical" root commit creating by squashing the entire history up to
that point.

In other words, you instruct git to *replace* this artificial root
commit by the tip of the history you're grafting. So *you are
promising these snapshots are identical* and if they're not, anything
can happen.

However, I don't think that's what we planned on doing: we want to
import and keep the entire history (minus stripping out some files).
In principle we could, instead of filtering out the files by rewriting
the entire history, remove the files we don't want to keep and create
a new squashed root commit and start from there and use grafts (or
better the new replace mechanism) to access history if needed. But I
would really rather avoid that.

Using grafts for importing feature branches is not generally safe I
think (all safeguards disabled) and imho harder to handle than doing a
"proper" rebase. Also I don't quite see how it would help us with the
bzr -> git import, unless I'm missing something?

Florian

---

From: Roland Siegbert <[email-masked]>
Date: Wed, 27 Mar 2013 17:12:47 +0100

> "artifical" root commit creating by squashing the entire history up to
Basically one grafts a branch to an existing tree (history/master).
Like in gardening. git replace sounds more reasonable though and less
hacky, I admit.

> bzr -> git import, unless I'm missing something?
It's more likely, that I miss something, as I don't have the time to
follow all threads currently.

However, as far as I understand: There exist problems converting all
the bzr branches. So instead of merging all of them into
trunk(master), which appears quite risky to me, I basically suggested
to graft/replace them later to some earlier old commit with a minimal
lines-of-code-delta in master(trunk) in git on bitbucket if the
conversion can't handle branches - but I am not a bzr expert. I did
that because a side-project was created in a 23y old codebase simply
by copying the codebase 8 years ago and using a seperate version
control system. Last year it was then grafted to the old codebase -
meanwhile being in git - by attaching the branch to a point somewhere
at the age of 15y of the old codebase.

Best,

Roland

---

From: Florian Rathgeber <[email-masked]>
Date: Wed, 27 Mar 2013 17:26:51 +0000

On 27/03/13 16:12, Roland Siegbert wrote:
>>>> after that the old branches on Launchpad must all be
>>>> abandonded and opened again on Bitbucket as fresh new
>>>> clones.
>>> I don't know, if it was discussed already. But, it is possible
>>> to "attach" existing (independent) branches to a previous 
>>> history/ancestor:
>>> 
>> I have to admit grafts is one of the git features I've shied away
>> from so far, so please correct me if I get this wrong: In my
>> understanding grafts were created to allow you to "prepend"
>> history to an "artifical" root commit creating by squashing the
>> entire history up to that point.
> Basically one grafts a branch to an existing tree
> (history/master). Like in gardening. git replace sounds more
> reasonable though and less hacky, I admit.

The problem with grafts is that they're inherently local. git replace
fixes that by making them push/pullable. But the caveats remain.

>> "proper" rebase. Also I don't quite see how it would help us with
>> the bzr -> git import, unless I'm missing something?
> It's more likely, that I miss something, as I don't have the time
> to follow all threads currently.
> 
> However, as far as I understand: There exist problems converting
> all the bzr branches. So instead of merging all of them into 
> trunk(master), which appears quite risky to me, I basically
> suggested to graft/replace them later to some earlier old commit
> with a minimal lines-of-code-delta in master(trunk) in git on
> bitbucket if the conversion can't handle branches - but I am not a
> bzr expert. I did that because a side-project was created in a 23y
> old codebase simply by copying the codebase 8 years ago and using a
> seperate version control system. Last year it was then grafted to
> the old codebase - meanwhile being in git - by attaching the branch
> to a point somewhere at the age of 15y of the old codebase.

Yes, I can see that use case (and I think that's exactly what grafts
were intended for!), but I still think our use case is different and
thus I'm not convinced grafts are the right tool for us.

The problem is not *converting* the branches, the problem is getting
them into the *filtered* git repo (again, all is fine without the
rewrite necessary for filtering) "at the right place".

Florian