search for: cherrypick

...h what I want? > > Create a cmt branch from master and add just the patches you want to > commit to it. Ok, that's what I thought I should do. I just needed to confirm that. So git-svn dcommit only commits things on the current branch. Cool, I think I can make this work. Will git-cherrypick work or is the merging process going to confuse git-svn? -Dave

...mt branch from master and add just the patches you want to >> commit to it. > > Ok, that's what I thought I should do. I just needed to confirm that. > > So git-svn dcommit only commits things on the current branch. Cool, I > think I can make this work. > > Will git-cherrypick work or is the merging process going to confuse > git-svn? To use git-svn you should always have a history without any git merges. Just commit after commit after commit. I do not know what kind of history git-cherrypick produces. I would do the cherrypicking like this: git checkout -b toCom...

Tobias Grosser <tobias at grosser.es> writes: >> Will git-cherrypick work or is the merging process going to confuse >> git-svn? > > To use git-svn you should always have a history without any git > merges. Just commit after commit after commit. I do not know what kind > of history git-cherrypick produces. To clarify, I just need to create the bra...

...r using the kernel's UAPI headers wherever possible. > > But for example, I did not check how far back UAPI loop.h was > provided, and whether users have it available at klibc build time. And > kind of wanted to show the bug with current loop.h, such that it's > available for cherrypicking & backports. I checked as far back as 3.2 (does anyone other than RHEL care about kernels older than that and, frankly, do we care to support them?), and linux/loop.h is exported there and is certainly more correct than the version shipped in klibc. While I originally encouraged you to sub...

On Mon, Oct 27, 2014 at 9:41 AM, Philip Reames <listmail at philipreames.com> wrote: > > +1 on this. I use Clang on the release schedule, but our LLVM work tracks > TOT. IMHO, trying to do anything else for an embedded compiler in a VM is > pure folly and will lead to worlds of pain. > Nick Lewycky is currently doing Google's internal Clang releases, and we actually tag

On 07/06/2011 07:53 AM, David A. Greene wrote: > Tobias Grosser<tobias at grosser.es> writes: > >>> Will git-cherrypick work or is the merging process going to confuse >>> git-svn? >> >> To use git-svn you should always have a history without any git >> merges. Just commit after commit after commit. I do not know what kind >> of history git-cherrypick produces. > > To clarify,...

On Thu, 2019-10-31 at 22:59 +0000, Dimitri John Ledkov wrote: > linux/loop.h header is exported by linux, for userspace to > consume. This would prevent issues with struct sizes > incompatibilities. [...] The structure definitions can't change in future, so I don't think that's a real issue after the previous patch. But I agree that we should prefer using the kernel's

...+ licm + loop-unswitch + simplifycfg + instcombine slp-vectorize + early-cse The rationale I have for this: 1) Zinovy pointed out that the loop vectorizer really needs the input loops to still be rotated. One counter point is that perhaps we should prevent any pass from un-rotating loops? 2) I cherrypicked the core of the scalar optimization pipeline that seems like it would be relevant to code which looks like runtime checks. Things like correlated values for overlap predicates, loop invariant code, or predicates that can be unswitched out of loops. Then I added the canonicalizing passes that migh...

Hello, my name is Jarek I am new here. I need some clarifications on how to distribute an app developed with devtoolset-4 enabled. I am developing a distributed app in c++ I wanted to upgrade toolchain to use new standard. Is it true that when I compile on centos 6.x with devtoolset enabled then I will be able to run this app on centos 7.x as well? Do I have to install devtoolset on all my

FWIW, I don't have really strong objections, but I'm honestly not a fan. The reason is mostly that I think it is very late to make the change and likely to mean most people are on holiday when the branch occurs. I somewhat anticipate significantly more cherrypicks as a consequence. I'd love for Apple's releases to by sync'd with the open source ones, but I don't understand why one week earlier is so critical. That said, I generally defer to those who are working more heavily on the open source releases. The one thing I have a stronger opini...

> On Sun, Mar 26, 2017 at 09:50:17AM +0000, Ady Ady via Syslinux wrote: > > > i wrote: > > > > > I think it still has good reason to exist. > > > > > > Ady wrote: > > > > Would you please clarify what do you mean with "it"? > > > > > > "It" was the code part about > > > > > >

On 07/05/2011 03:27 PM, David Greene wrote: > My git-svn fu is not very strong. > > In the course of preparing a set of AVX patches, I've committed several > changes to my local LLVM git clone. I don't want to send all of those > changes upstream right away. What's the best way to send just the first > of those changes us using git-svn? dcommit appears to send all

...kernel's UAPI headers wherever possible. Correct, this was my thinking too. But for example, I did not check how far back UAPI loop.h was provided, and whether users have it available at klibc build time. And kind of wanted to show the bug with current loop.h, such that it's available for cherrypicking & backports. But indeed, either of the two patches fixes the identified problem. One is minimal, and this one is slightly more invasive. -- Regards, Dimitri.

...API headers wherever possible. > > > > But for example, I did not check how far back UAPI loop.h was > > provided, and whether users have it available at klibc build time. And > > kind of wanted to show the bug with current loop.h, such that it's > > available for cherrypicking & backports. > > I checked as far back as 3.2 (does anyone other than RHEL care about > kernels older than that and, frankly, do we care to support them?), klibc generally doessn't attempt to provide any kernel backward compatibility. So whatever works with the latest stable...

On May 19, 2016, at 3:30 AM, Jaros?aw Bober <jaroslaw.bober at gmail.com> wrote: > > Do I have to install devtoolset on all my machines that I want to run this > app? Probably, yes. That, or redistribute parts of it with your app, either by cherrypicking files from the devtoolset RPM or statically linking to it. > Or would it use built-in libstdc++ library, linking statically only > the missing parts? Are you asking if the new libstdc++ is statically linked into your app only for the new functions but your app remains dynamically linked...

...uot;stable" releases of the distribution, providing 3.5.8 (and later) is not an option we'll be considering for future updates. The policy of our release team is indeed more conservative than the policy of the Samba Team (no offense intended, of course). *Still, we have the opportunity to cherrypick some fixes when they deal with "important"issues. So, I would like to give you, users of Debian packages, an opportunity to voice your needs.* Please mention what you would like to see fixed in further updates. Please focus on the following: - the bug is fixed in 3.5.8 - a clear upstre...

...e $100M+ range. Several of their NAS backup options use rsync either explicitly or under the hood (NAS-to-Remote-NAS backup, Shared-Folder-Sync), and they run the rsync daemon (under File Services). rsync is an integral part of their solution. They use a modified build of rsync (seemingly 3.0.9 + cherrypicked CVE fixes) for which they do provide some sources (see https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/24922branch/x64-source/ and search for "rsync"), and if you spend your afternoon tracking down all the needed packages/downloads and reconcile the missing he...

On 10/10/2019 11:40 AM, Mehdi AMINI wrote: > > > On Thu, Oct 10, 2019 at 10:59 AM Tom Stellard <tstellar at redhat.com <mailto:tstellar at redhat.com>> wrote: > > On 10/09/2019 11:05 PM, Mehdi AMINI wrote: > > > > > > On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at

...the support for branch creation to `git-llvm` we could print a disclaimer about it or something? > >> -Tom >> > > FWIW, we're interested in periodically (weekly) tagging well-tested/stable > revisions, but via a branch instead of just a tag so we can include which > cherrypicks (e.g. reverts or fixes) are needed. We do this with the current > svn repo so we'd just be porting existing functionality to github. > I would likely include this in the general category of "project maintainer" created branch? The main difference with SVN, is that on GitHub a...

As Asterisk has inner problems and channels very often locks we have such script to restart Asterisk each midnight. We (our clients) mostly use v1.4.18.1. We can't upgrade to newer versions because there are too much changes which would brake our system (realtime/sip/iax2/cdr/etc/etc). Script soft hangups all alive channels in dirty way then kills Asterisk and starts it up. Hope