search for: rebase

...Kashyap Chamarthy: thank you very much for answer my question: 一： lead to VM filesystem becoming read-only 1： test case it lead to VM filesystem becoming read-only test case as follows: we want to snapshot for VM , to obtain VM incremental data，and use virsh blockcommit，qemu-img commit，qemu-img rebase to shorten snapshot chain. Details are as follows（when VM running state， we perform the following operations）: (1) the host machine control VM test virsh snapshot-create-as mix snap1 --diskspec vda,file=/tmp/mul/loop-mix-commit-rebase/snap1-mix.img --disk-only --atomic --quiesce virsh snapshot...

greened at obbligato.org (David A. Greene) writes: > Actually git pull can sometimes get you into trouble. Probably git > fetch / git rebase is the better combination for LLVM. I don't get it. Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? -- Matthieu Moy http://www-verimag.imag.fr/~moy/

...reate snapshot of the cycle，and by virsh blockcommit merge snapshot chain，but when VM offline， the virsh blockcommit will fail， someone suggest me：when VM offline，may use qemu-img commit to submit snapshot turn，but qemu-img can't modify snapshot chain backing relation，it need we use qemu-img rebase amend snapshot‘s backingfile， the main question is when we use qemu-img rebase modify snapshot's backingfile, if someone start the VM, it will may lead to VM filesystem readonly。 we should how to solve the question? thanks! justlibvirt@gmail.com

Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes: > greened at obbligato.org (David A. Greene) writes: > >> Actually git pull can sometimes get you into trouble. Probably git >> fetch / git rebase is the better combination for LLVM. > > I don't get it. > > Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? No. It does a fetch and merge at the same time. git fetch lets you examine what will change before you actually merge/rebase. Then if yo...

> I'd also recommand "git pull --rebase" if the goal is to keep history > linear. Note that this has to go with a big, fat, warning, telling the > user that rebasing published history is bad. Rebase is a very good tool > to work with private history, but as soon as you've pushed it to some > place visible by other pe...

Hi. I am using openstack, ceph and libvirt now. The live volume migration will call the libvirt rebase function in openstack nova project. https://github.com/openstack/nova/blob/stable/rocky/nova/virt/libvirt/driver.py#L1497 https://github.com/openstack/nova/blob/stable/rocky/nova/virt/libvirt/guest.py#L802 But I use the ceph as the openstack block backend. And the type of disk is netw...

Hi Pino, $subject -- do we intend to rebase libguestfs, virt-v2v and virt-p2v in RHEL 7.4? If yes, we should file the rebase bug soon. Pros: - The RHEL 7.3 package has 151 patches on top of 1.32.6. Rebasing would get almost all those patches. Not rebasing would mean (at predicted growth rate) shipping ~300-400 patches. - Backpo...

On Aug 23, 2011, at 12:35 AM, FlyLanguage wrote: >> I'd also recommand "git pull --rebase" if the goal is to keep history >> linear. Note that this has to go with a big, fat, warning, telling the >> user that rebasing published history is bad. Rebase is a very good tool >> to work with private history, but as soon as you've pushed it to some >> place vis...

Greg Fitzgerald <garious at gmail.com> writes: > In my humble opinion, there is a one biggest problem with git-svn and > svn. It requires the maintainer to rebase before committing, and in > git, this changes the the patch's unique ID. I didn't totally follow your argument so I'm sure I missed something. However, I don't think rebase is really the issue here. Linux kernel developers rebase all the time. It's required before merging...

...ly gets > merged. > >>> You review, build and test exactly the change that gets merged > afterwards. > >>> > >> > >> How would that be true? Given that upstream keep changing during the > >> period of review? The commit is going to have to be rebased to head and > >> that may involve making changes. > >> > > > > Yes, github tells you, that your PR has a merge conflict, that you need > to > > resolve manually. Once you've pushed the conflict resolution to the same > > PR, it triggers another roun...

...patch, and the (warranted) reviewer comment is that > it should be split.  I push a couple new PRs, they get approved, and > landed.  (All as new branches off master.)  Then, I have a stale branch > (say it contains 2 commits) which needs rewritten.  I can of course do > an interactive rebase, and a force push, but a) I've found interactive > rebases to be very error prone, and b) I *strongly* prefer to never be > in the habit of doing a force push.  The alternative is to close the > original PR, and simply post a new one - which looses history of review.  I would say that...

...directly: git remote rename origin llvm-upstream > Updating LLVM - no local changes > -------------------------------- > > Splitting this into "no local changes" / "with local changes" seems unnecessarily complicated. Why not just recommend doing 'git pull --rebase' all of the time? I have to ask as well - is a linear history really desired? That seems to be the intent of your instructions. I ask because for something like a reasonably sized feature that might have multiple commits, having the merge history in place can be useful, if only to separate th...

Thanks for your reply. The nova project uses the virDomainBlockRebase API to finish the rebase operation from the old disk to the new disk not using the virDomainBlockCopy API. I am confused of the difference of virDomainBlockRebase and virDomainBlockCopy. Cheers, Boxiang On 11/5/2018 22:07，Peter Krempa<pkrempa@redhat.com> wrote： On Fri, Nov 02, 2018 at 13:4...

Hi ALL, Short description of my problem: I am not able to make wireless network working on the IBM ThinkPad T43p. System: T43p OS: CentOS 4.4 kernel: 2.6.9-34.EL firmware: ipw2200-firmware-3.0-3.nodist.rf.noarch.rpm What did I do ? - installed firmware from RPM package - removed kernel driver (/sbin/rmmod ipw2200) - installed kernel module (/sbin/modprobe ipw2200) dmesg output:

Just to clarify: All the LLVM incubator repositories have "enforce linear history" enabled. Neither "Squash and Merge" or "Rebase and Merge" results in a Merge commit in the git history. Steve On Fri, Sep 11, 2020 at 3:32 PM Hubert Tong < hubert.reinterpretcast at gmail.com> wrote: > On Fri, Sep 11, 2020 at 6:12 PM Renato Golin <rengolin at gmail.com> wrote: > >> On Fri, 11 Sep 2020 at 19:32, H...

...easonable to make git the central repo and have SVN mirror git. * A linear history is highly valued by Chris and many members of the community. My input (or from my perspective, my output): In my humble opinion, there is a one biggest problem with git-svn and svn. It requires the maintainer to rebase before committing, and in git, this changes the the patch's unique ID. Changing the ID creates a serious problem, one which forces the private fork to make an early decision about contributing back to the community. The private fork must decide, "do we want this patch today or would we r...

...from clone A to/from clone B without > going through the parent git-svn repository.  Is that right?  I recall > having read something about that somewhere. Maybe sure on git-svn's branch (eg. master). "master" should never be pushed to "git-svn", but "git pull --rebase" should be done. Each clonee should do "git-svn dcommit" individually. (and it would be happier if you did "git pull --rebase llvm.org) Of course, other branches may be push/pull-ed among repos. It is git! > If this is a problem, it might be counterproductive to provide a...

...ith instructions about how to interact with the new git repository. There are a lot of different topics we will need to discuss, but I would like to start by initiating a discussion about our merge commit policy. Should we: 1. Disallow merge commits and enforce a linear history by requiring a rebase before push. 2. Allow merge commits. 3. Require merge commits and disallow rebase before push. I'm going to propose that if we cannot reach a consensus that we adopt policy #1, because this is essentially what we have now with SVN. What does everyone think? Thanks, Tom

...clone B without >> going through the parent git-svn repository.  Is that right?  I recall >> having read something about that somewhere. > > Maybe sure on git-svn's branch (eg. master). > "master" should never be pushed to "git-svn", but "git pull --rebase" > should be done. Right. > Each clonee should do "git-svn dcommit" individually. > (and it would be happier if you did "git pull --rebase llvm.org) Yep. > Of course, other branches may be push/pull-ed among repos. It is git! Does this mean that clone B can pull...

On Fri, Nov 02, 2018 at 13:42:56 +0800, Boxiang Zhu wrote: > > > Hi. > I am using openstack, ceph and libvirt now. > > > The live volume migration will call the libvirt rebase function in openstack nova project. > https://github.com/openstack/nova/blob/stable/rocky/nova/virt/libvirt/driver.py#L1497 > https://github.com/openstack/nova/blob/stable/rocky/nova/virt/libvirt/guest.py#L802 > > > But I use the ceph as the openstack block backend. And...