That is a problem with linear history while its not actually linear. If you look at the DAG, its reflects the actual
$ git log --graph --pretty=short * commit 256e227cd5be63186a989e2c99ded0da5e7dea71 | Author: Rohit Yadav <rohit.ya...@shapeblue.com> | | schema: fix foreign key checks for 3.0.7 to 4.1.0 upgrade path | * commit b1f2e598e83e8ec018ae993f918accb0199b9237 | Author: Gaurav Aradhye <gaurav.arad...@clogeny.com> | | CLOUDSTACK-8468: Correct test case in test_bugs.py | * commit c7d2e444d2981464dd115d1030371cde2fdaeb68 | Author: wilderrodrigues <wrodrig...@schubergphilis.com> | | Fixing license header in a file added during the LibVirt refactor | - New class is MigrateKVMAsync | * commit 45c0fa2faa7b5f0b2b2f2863cde7ad5e786115fa |\ Merge: 60b6dc1 f575206 | | Author: wilderrodrigues <wrodrig...@schubergphilis.com> | | | | Merge branch 'refactor/libvirt_resource' of https://github.com/schubergphilis/cloudstack | | | * commit f575206ad4348fb7fc0fe312a1e797bac23d011b | | Author: wilderrodrigues <wrodrig...@schubergphilis.com> | | | | Fixing testModifySshKeysCommand in the LibvirtComputingResourceTest class | | - The test was okay, but when running in an environment where a /root/.ssh/id_rsa existed, it would return true then fail | | - We now mock the calls to methods that return the key paths, instead of relying in the static variables | | | * commit b284b841929c74a8e5273f8a31a26ed9bba5d139 | | Author: wilderrodrigues <wrodrig...@schubergphilis.com> | | | | Fixing method call on KVMGuru to reach StorageSubSystemCommand | | | * commit 74ad48db55d141f697b6e8235e7ac472d844dd57 | | Author: wilderrodrigues <wrodrig...@schubergphilis.com> | | | | Refactoring the LibvirtComputingResource | | - Adding LibvirtStartCommandWrapper | | - 8 unit tests added | | - KVM hypervisor plugin with 23.2% coverage | | ~Rajani On Sat, May 16, 2015 at 1:41 PM, Sebastien Goasguen <run...@gmail.com> wrote: > So I was looking at the libvirt commit from wilder: > > https://github.com/apache/cloudstack/commits/master?page=2 > > is that what we want ? > > > > On May 16, 2015, at 4:37 AM, Rajani Karuturi <raj...@apache.org> wrote: > > > > -1 for squashed commits. I agree to what Daan said. Feature branch merge > is > > more convenient than squashed single commit. > > If it was a small feature which involved single dev squashing is still > ok. > > But, a big no when it comes to big feature/refactoring involving effort > > from multiple people and multiple reviews. > > > > > > On Sat, May 16, 2015 at 3:21 AM, Mike Tutkowski < > > mike.tutkow...@solidfire.com> wrote: > > > > Those comments may or may not be useful anymore. What they describe may > > have been superseded by a subsequent commit. > > > > On Fri, May 15, 2015 at 3:12 PM, Daan Hoogland <daan.hoogl...@gmail.com > > <javascript:;>> > > wrote: > > > >> those comments will then have to be squashed s well, to this i put a -1. > > If > >> those comments where usefull at review-time they will be usefull in the > >> future as well. > >> > >> Op vr 15 mei 2015 om 19:29 schreef Marcus <shadow...@gmail.com > > <javascript:;>>: > >> > >>> I'm not sure it is any different. Either you have a giant block of code > >>> that represents a bunch of little commits, or a giant block that is one > >>> commit. We don't want to merge little chunks to master that don't fully > >>> implement the feature. > >>> > >>> To the extent that features and goals can be split up, yes, we don't > > want > >>> those features squashed together, or even submitted together, squashed > > or > >>> not. An example of this is in combining formatting/syntax fixes with > >>> functional changes, I have tried to review such pull requests and it is > >>> very difficult to see what is going on in a 1k line request when 2/3 of > >> the > >>> changes are just reformatting noise. > >>> > >>> Ideally the code is reviewed at the commit level as each small commit > >> goes > >>> from the developer's workstation to the dev branch, but I don't see a > > way > >>> around reviewing the same amount of code in a pull request that > >> represents > >>> multiple small commits vs one squashed commit. You do get more > > visibility > >>> into the comments, though. > >>> > >>> I suppose a way to get both would be to branch master, do a pull > request > >>> from your dev branch to that branch, at which point it is reviewed, > then > >>> squash merge that back into master. > >>> On May 15, 2015 8:55 AM, "Daan Hoogland" <daan.hoogl...@gmail.com > > <javascript:;>> > >> wrote: > >>> > >>>> Sebastien, I don't think commits in a big feature should be squashed. > >> It > >>>> hinders review if to big chunks are submitted at once. > >>>> > >>>> Op vr 15 mei 2015 om 11:27 schreef Sebastien Goasguen < > >> run...@gmail.com <javascript:;> > >>>> : > >>>> > >>>>> Folks, > >>>>> > >>>>> As we prepare to try a new process for 4.6 release it would be nice > >> to > >>>>> start paying attention to master. > >>>>> > >>>>> - Good commit messages > >>>>> - Reference to a JIRA bug > >>>>> - Squashing commits ( cc/ wilder :)) > >>>>> > >>>>> While you can apply patches directly, good practice is to apply the > >>> patch > >>>>> to a branch and then merge that branch into master. > >>>>> > >>>>> Before we start enforcing some of these things more strongly, please > >>> keep > >>>>> it in mind. > >>>>> > >>>>> thanks, > >>>>> > >>>>> -sebastien > >>>> > >>> > >> > > > > > > > > -- > > *Mike Tutkowski* > > *Senior CloudStack Developer, SolidFire Inc.* > > e: mike.tutkow...@solidfire.com <javascript:;> > > o: 303.746.7302 > > Advancing the way the world uses the cloud > > <http://solidfire.com/solution/overview/?video=play>*™* > > > > > > > > -- > > ~Rajani > > Sent from my Windows Phone > >
