On 27/03/13 16:12, Roland Siegbert wrote: > On Tue, Mar 26, 2013 at 10:40 PM, Florian Rathgeber > <[email protected]> wrote: >> On 26/03/13 11:20, Roland Siegbert wrote: >>> On Mon, Mar 25, 2013 at 3:18 PM, Anders Logg <[email protected]> >>> 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : [email protected] Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
