Better to use "git pull --rebase", which is cleaner than "git merge". If you can squash your changes into small commits before push, that will be even better:)
> -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Wednesday, January 16, 2013 3:57 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [MERGE] resizeVolume > > Changed subject line since we've been discussing merge. > > Guys, what's the accepted or standard way to merge? Should I do a "git > merge --squash", "git pull --rebase", or do we want all of the commits? I'm > just a little gunshy about making sure it's done exactly as expected. > > On Wed, Jan 16, 2013 at 4:29 AM, Wido den Hollander <w...@widodh.nl> > wrote: > > > Hi, > > > > Update from my side as well. I've re-submitted my patches as the first > > series got refused (with good feedback though!) > > > > On my Github[0] the patches can be found which I sent last weekend. > > > > I've those make it into 0.5.0 I can also implement the resizing for > > RBD images in CloudStack. > > > > Wido > > > > [0]: https://github.com/wido/**libvirt-java/commits/snapshot-** > > resize-migrate<https://github.com/wido/libvirt-java/commits/snapshot-r > > esize-migrate> > > > > > > On 01/16/2013 04:34 AM, Marcus Sorensen wrote: > > > >> Just an update (will post this on the feature request as well). With > >> the tests patch Ryan provided today, I think we're ready to merge this in. > >> That > >> is unless it's going to cause problems for the license issues > >> currently being worked out, but this is pretty much all new stuff so > >> I don't expect it to cause conflicts. > >> On Jan 9, 2013 11:16 AM, "Alex Huang" <alex.hu...@citrix.com> wrote: > >> > >> > >>> > >>> -----Original Message----- > >>>> From: Marcus Sorensen [mailto:shadow...@gmail.com] > >>>> Sent: Tuesday, January 08, 2013 10:56 AM > >>>> To: > >>>> cloudstack-dev@incubator.**apache.org<cloudstack- > d...@incubator.apac > >>>> he.org> > >>>> Subject: [DISCUSS] resizeVolume > >>>> > >>>> Guys, > >>>> I've pushed this as a new branch called 'resizevolume', in > >>>> order to collaborate with a few of you on it. I have several > >>>> questions on how to proceed, due to refactoring efforts. I'm hoping > >>>> that the experts in those efforts can collaborate. > >>>> > >>>> 1) Wido, would you be interested in looking at adding RBD resize to > >>>> LibvirtComputingResource? The resize for CLVM and QCOW2 is done > via > >>>> scripts/storage/qcow2/**resizevolume.sh at the moment, since the > >>>> libvirt bindings won't support volBlockResize until you get 0.5.0 > >>>> out (and even then I'm not sure if it will support anything more > >>>> than just informing > >>>> > >>> the > >>> > >>>> hypervisor/guest of the change, which is also in the script). > >>>> > >>>> 2) I'm not sure exactly how this will be affected by the storage > >>>> > >>> refactor, > >>> > >>>> but I'm sure it will be. I looked for examples in the createVolume > >>>> on javelin, but it seems that the storage refactor is still early > >>>> on, and > >>>> > >>> per > >>> > >>>> Edison's update only works for a few template commands at the > >>>> moment. I thought it best to get this in as a fully fleged member > >>>> of the storage > >>>> > >>> API > >>> > >>>> so that when the work is done on the storage commands, this will > >>>> get > >>>> > >>> looked > >>> > >>>> at as well. So if everything looks good otherwise, I'd like to not > >>>> block > >>>> > >>> on > >>> > >>>> the storage refactor unless this is just going to be scrapped when > >>>> that comes along. > >>>> > >>> > >>> I'm sure it will be impacted but check it in and we'll fix it on > >>> this end as we merge storage refactor into cloudstack code. > >>> > >>> > >>>> 3) I've implemented resize for Xen, but only tested with local > >>>> storage > >>>> > >>> SR. > >>> > >>>> The SR in devcloud doesn't seem to support online resize, and I'm > >>>> not familiar enough with the Xen setup to really figure out if > >>>> that's just a byproduct of how the SR was created, whether it's a > >>>> Xen limitation in DevCloud, or what. If someone more familiar with > >>>> Xen wants to take a peek it would be appreciated, however I'm not > >>>> really considering it a blocker > >>>> > >>> if > >>> > >>>> nobody does. For now resize works offline (or with data disk > >>>> detached) > >>>> > >>> and > >>> > >>>> fails with warning that VM needs to be stopped or data disk detached. > >>>> > >>> > >>> I'm not sure xen actually supports online resize. It didn't when we > >>> started. I'll see if I can get some answers for you. > >>> > >>> > >>>> 4) Can someone who is working with the api refactoring take this > >>>> into account? I think I'd prefer it go in before the refactor, or > >>>> if it > >>>> > >>> doesn't > >>> > >>>> that someone help me make any modifications necessary, so that it's > >>>> not broken at any point in master. > >>>> > >>> > >>> > >>
