search for: cherrypicking

Rafael Ávila de Espíndola <rafael.espindola at gmail.com> writes: > 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

...n 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 toCommit git rebase -i HEAD~30 > Remove all the unneeded commits in the upcoming window git svn -n dcommit // Check what would be committed git svn dcommit // Commit Cheers Tobi

...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 branch at the point just before the first commit to go to upstream. Are merges in the history before that point going to be a problem? > I would do the cherrypicking like this: > > git checkout -b toCommit > git rebase -i HEAD~30 Ok, I'll try something like that. >> Remove all the unneeded commits in the upcoming window > > git svn -n dcommit // Check what would be committed > git svn dcommit // Commit Ok, thanks. git-svn is a bi...

...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 submit...

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

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

I've added a straw-man of some extra optimization passes that help specific benchmarks here or there by either preparing code better on the way into the vectorizer or cleaning up afterward. These are off by default until there is some consensus on the right path forward, but this way we can all test out the same set of flags, and collaborate on any tweaks to them. The primary principle here

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

https://bugzilla.mindrot.org/show_bug.cgi?id=3739 Bug ID: 3739 Summary: Match parsing requires space before '=' Product: Portable OpenSSH Version: 9.9p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh Assignee: unassigned-bugs at

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

> 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 ker...

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 to...

Hello, I'm one of the maintainers of samba packages in Debian. As of now, Debian squeeze provides samba 3.5.6. As per Debian policy wrt updates in the "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

Synology ( https://www.synology.com/en-global ) is one of best selling brands of consumer/prosumer/SMB NASes, with revenue estimated to be in the $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

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

On Thu, Oct 10, 2019 at 1:14 PM Jordan Rupprecht <rupprecht at google.com> wrote: > > > On Thu, Oct 10, 2019 at 12:29 PM Tom Stellard via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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 >>