search for: squashed

On 6/2/2016 1:48 PM, via llvm-dev wrote: > Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Github has an automatic "squashed" mode for pull requests now, I >> haven't tested in practice but it may help. > IMHO squashed commits are a bad idea from a bisect perspective. One of > the great benefits of git is the easy of creating small, > logically-independent commits that can be bisected. Squashing...

...ossible... > > The only issue in this area that I'm aware of is that you can't easily see what changed between two revisions of a pull request if you both a) rebase onto master and b) amend commits at the *same* time. For review purposes it is most useful if additional changes are not squashed into existing commits, but pushed on top. The squash is best performed when landing the changes. Disagree. I usually want to be able to review the actual commits that will be landed, not some imagined combination that may or may not line up with what the author will end up squashing things to. Re...

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

On Mon, Jan 19, 2015 at 12:56:28PM +1030, Rusty Russell wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > Hi Rusty, all > > > > I parked outstanding virtio patches here: > > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-next > > this way they are merged in linux-next as well. > > > > Rusty if you'll be

On Mon, Jan 19, 2015 at 12:56:28PM +1030, Rusty Russell wrote: > "Michael S. Tsirkin" <mst at redhat.com> writes: > > Hi Rusty, all > > > > I parked outstanding virtio patches here: > > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-next > > this way they are merged in linux-next as well. > > > > Rusty if you'll be

On Fri, 11 Sep 2020 at 19:32, Hubert Tong via llvm-dev < llvm-dev at lists.llvm.org> wrote: > There seems to be a split between those who prefer to curate commits >> locally and present them in the PR (i.e. Method 3) as they are to be >> committed (i.e. squash/amend/etc from my workstation and push the result), >> and those who seem to feel that it is better to avoid

On Fri, Sep 11, 2020 at 6:53 PM David Blaikie <dblaikie at gmail.com> wrote: > Is there any observable difference between "Squash and Merge" or "Rebase > and Merge" when "enforce linear history" is enabled, then? > "Squash and Merge" will only generate one commit. > > On Fri, Sep 11, 2020 at 3:45 PM Stephen Neuendorffer via llvm-dev

...iven time. > There are multiple ways to linearize the history. > > You can simply disallow merges I guess but that seems not much better > than just sticking with SVN. GitHub's pull request model kind of breaks > down if you can't do merges. Github has an automatic "squashed" mode for pull requests now, I haven't tested in practice but it may help. -- Mehdi

...whether they're in multiple commits though? > > > > I think you misunderstood. > > > > Our policy [1] is that independent NFC fixups on existing code should > > be separate from new changes. > > > > The point here is that fixups *to the patch* should be squashed into > > their original commits *before* merging. > > Okay, this intention wasn't clear to me from what was written. It > looks like we agree, then. > > > > > Once the patches are in master, and problems have been found, then > > adding a fixup to master is t...

On Tuesday, 26. June, an LLVM Meetup will take place in Paris. We invite everybody interested in LLVM to join. o What is LLVM? LLVM is a collection of modular and reusable compiler and toolchain technologies. It is used as the base of many modern compilers such as clang (C/C++/Objective-C), GHC (Haskell), dragonegg (Ada, Fortran, ...), several commercial OpenCL compilers or RenderScript.

On Tue, 28 Jan 2020 at 16:09, David Greene <dag at cray.com> wrote: > The question is if everything is approved and the author does a final > cleanup as alluded to above, does that final cleanup also need to go > through review? We don't enforce that now, so I see no reason to start doing it. Phab reviews, once approved, can have last-minute modifications and direct commits.

Looks like we are better off sticking with the misaligned stat struct, to reduce the amount of virtio 1 specific code in balloon. So let's do it. Add a detailed comment to reduce the chance people copy this bad example. This also fixes a bug on BE architectures: tag should use cpu_to_le16, not cpu_to_le32. Acked-by: Cornelia Huck <cornelia.huck at de.ibm.com> Signed-off-by: Michael

So, I am starting to code this CAS block squashing test and I am wondering if this is something that would more likely extend open Solaris (it does require additional info in zfs metadata that is currently reserved space for future, ie zfs revision++) or if I should code against the FUSE tree where it would could be imported. What type of contribution style is open Solaris? Is zfs

Looks like we are better off sticking with the misaligned stat struct, to reduce the amount of virtio 1 specific code in balloon. So let's do it. Add a detailed comment to reduce the chance people copy this bad example. This also fixes a bug on BE architectures: tag should use cpu_to_le16, not cpu_to_le32. Acked-by: Cornelia Huck <cornelia.huck at de.ibm.com> Signed-off-by: Michael

Leading up to the upcoming orphan removal in EPEL, the EPEL Steering Committee is organizing a Bug Squashing Day. There are 3 main purposes to this day: 1. Identifying owners willing to take over orphaned packages 2. Bug triage, feedback, or fixing various bugs through patch submission, etc. 3. Last but not least, we'll be covering the testing of various packages which need feedback.

...gt; > > > Acked-by: Michael S. Tsirkin <mst at redhat.com> > > > > > > > > The affected patch is not upstream yet, right? > > > > I don't know if the tree in question allows rebases - linux-next > > > > does. So ideally it would be squashed to avoid issues during bisect. > > > > Still it's error path so I guess not a tragedy even without squashing. > > > > > > I tend to not rebase once stuff has been in linux-next but I make > > > exceptions as long as it's before -rc4. For now I've...

Hello just learned HowTo but R, reminded me with the way Perl does it but with much less on-line commands, R "AFAIK" has n, c, Q and where and cann't debug outside the {}. 1) is there a more versatile/flexable debugging method for R? I have saved 2 functions in an ASCII file "digfun". "getdata" function calls "squash" function and both use loops. In

...gt; > >> > I think you misunderstood. > >> > > >> > Our policy [1] is that independent NFC fixups on existing code should > >> > be separate from new changes. > >> > > >> > The point here is that fixups *to the patch* should be squashed into > >> > their original commits *before* merging. > >> > >> Okay, this intention wasn't clear to me from what was written. It > >> looks like we agree, then. > >> > >> > >> > >> > Once the patches are in master, an...

...fault n > > > ---help--- > > > @@ -56,6 +62,7 @@ config VHOST_VSOCK > > > config VHOST_VDPA > > > tristate "Vhost driver for vDPA-based backend" > > > depends on EVENTFD > > > + select VHOST > > > This part is not squashed. > > > > > select VDPA > > > help > > > This kernel module can be loaded in host kernel to accelerate > > OK so I squashed this into the original buggy patch. > > Could you please play with vhost branch of my tree on various > > arches...

...fault n > > > ---help--- > > > @@ -56,6 +62,7 @@ config VHOST_VSOCK > > > config VHOST_VDPA > > > tristate "Vhost driver for vDPA-based backend" > > > depends on EVENTFD > > > + select VHOST > > > This part is not squashed. > > > > > select VDPA > > > help > > > This kernel module can be loaded in host kernel to accelerate > > OK so I squashed this into the original buggy patch. > > Could you please play with vhost branch of my tree on various > > arches...