On Mon, Feb 22, 2016 at 06:10:25PM -0600, Tyler Hicks wrote: > On 2016-02-22 09:53:50, Steve Beattie wrote: > > I've created a test git repo of the apparmor-profiles tree at > > > > https://code.launchpad.net/~sbeattie/+git/apparmor-profiles-test > > > > based on a simple conversion of the bzr tree. The origin tree is pretty > > simple, we don't have any long term branches and it doesn't look like > > any used the --fixes bzr argument to annotate commits as fixing any > > specific bugs. Please poke at this tree (particularly those of you > > who have a clue what they're doing with git, unlike myself) to see > > if there's anything odd or messed up with the conversion or history. > > While I haven't dealt with the apparmor-profiles tree much, this git > tree looks good.
Thanks for the feedback. I note that Kshtij didn't raise any issues with the history on IRC. I'd like other people's positive or negative feedback before promoting it as the official repo. > It is also worth noting that there were no bzr tags used in > lp:apparmor-profiles so, obviously, there are no git tags in the test > tree. Yep. That's another wrinkle when dealing with converting the main apparmor tree; git doesn't support tags with '~' in them, while bzr supports them. We used '~' in a version/tag [0] once, for apparmor_2.6.0~rc1, which git complains about on fast-import. We stopped using them precisely because it broke John's git view of the bzr tree. > > Converting the main apparmor tree will be more difficult in that we > > have multiple long term branches and we have made more use of the bug > > fixed annotations. It's also unclear to me if launchpad's translation > > service understands git repos. In any event, I'll try to get a test > > git repo up soon. > > By "long term branches" of lp:apparmor, are you talking about > lp:apparmor/2.9 and lp:apparmor/2.10? If so, I think that'll be somewhat > easy to handle in a single git repo (with v2.9 and v2.10 branches). > We'll just want to make sure that we share as many objects as possible > with those branches and master. That'll probably mean getting the master > branch all fixed up and then branching off of master at the appropriate > points in master's history to create v2.9 and v2.10 and then pulling in > the newer commits to those branches. Yes, that's what I was referring to, and that's how I'm hoping to organize things. I don't know how well the available conversion tools handle doing that, though reading through various blogs (e.g. http://blog.timmattison.com/archives/2011/06/13/how-to-convert-from-bzr-to-git-on-debianubuntu/ ) makes me hope that it'll just work. Test attempts seem to indicate that this is the case. > As for the bug fixed annotations, I think the best that we can do is to > identify the commits that have a bug fixed annotation but do not include > a link to the bug in the commit message body. Those commit messages > should be modified to include a proper bug report link. (Note that since > this will require rebasing, this commit message fixup needs to happen > before the v2.9 and v2.10 branches are created.) Ugh. I'm hoping to avoid rebasing by doing something like https://www.fusonic.net/en/blog/migrating-from-bazaar-to-git/ during the import process. But we'll see. > > Any feedback or advice is welcome. Thanks! > > Nice job! What conversion tool did you end up using? For this tree, I used bzr fast-export | git fast-import. Sadly, I had to do it on an Ubuntu 14.04 host, as bzr-fastexport has been dropped from both debian and 16.04, due to RC bugs and a lack of support. :( So I'm not sure how much I want to rely on it for more complex things. (I poked a bit at reposurgeon, too, but it sure looked like it was trying to treat the bzr tree as a subversion tree, despite my efforts to inform it otherwise.) [0] in debian versioning, ~ indicates before, so e.g. 2.10 > 2.10~rc1 -- Steve Beattie <[email protected]> http://NxNW.org/~steve/
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
