fenics team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

On 27/03/13 16:12, Roland Siegbert wrote:
> On Tue, Mar 26, 2013 at 10:40 PM, Florian Rathgeber 
> <florian.rathgeber@xxxxxxxxx> wrote:
>> On 26/03/13 11:20, Roland Siegbert wrote:
>>> On Mon, Mar 25, 2013 at 3:18 PM, Anders Logg <logg@xxxxxxxxx> 
>>> 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:
>>> 
>>> 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.
>> 
>> 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

> Best,
> 
> Roland

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature