IMO, sometimes squashing helps, sometimes not. I've not used squashing, but probably should sometimes. The main goal is a useful log of changes. If the work was done in separate logical steps they may better not being squashed, especially if one of the commits might need to be reverted. But if the sequence of commits was a series of minor fixes, then sure, squashing might help. Maybe we should build a list of scenarios where squashing helps. It might help me remember to use it more often.
My 2 cents, -Alex On 6/20/20, 3:52 AM, "Piotr Zarzycki" <[email protected]> wrote: I'm not in favor of squashed commits. Each of your commit should be well described and we as a code inspectors should see what those means. If I loose ability to look in each of that with description - that is not very helpful. Of course if not description - code itself should be enough describe yourself. pt., 19 cze 2020 o 23:39 Greg Dove <[email protected]> napisał(a): > I don't think PRs are practical for routine use either. > > > One suggestion I'd like to make about merges in general: > I'd like to suggest that for any merge from a branch or PR with multiple > commits, that we always try to do that as a single squashed commit. This > makes it easier to understand all the changes IMO when looking at > the commit logs. Should help with Harbs concern "More like being able to > see at a glance what has been done without wading through commit messages." > > > > > > > > On Sat, Jun 20, 2020 at 12:14 AM Yishay Weiss <[email protected]> > wrote: > > > I think PRs can be useful, but should be voluntary. I prefer to create a > > PR if I’m unsure of my changes, e.g. in the compiler code. > > > > From: Piotr Zarzycki<mailto:[email protected]> > > Sent: Friday, June 19, 2020 3:09 PM > > To: Apache Royale Development<mailto:[email protected]> > > Subject: Re: Using PRs for commits > > > > Hi Guys, > > > > In my opinion Royale is not the type of project which can handle PR way > of > > work. I've been working like that in one company and it has great > benefits, > > but only if: > > - You are working every day on repository - payable job > > - Your active Team is bigger than 2-3 people - if one person won't be > able > > to take a look into your PR - someone else can. It doesn't make sense to > > have PR way of work if there is no people who can look into your code. > > > > Disadvantage is that - creating PR is slower than pushing commit to > > repository - no matter how got you are in that. You may also experience > > during merge of PR conflicts - which is not the case if you commit > > straightforward into the main branch. > > > > Thanks, > > Piotr > > > > pt., 19 cze 2020 o 12:34 Carlos Rovira <[email protected]> > > napisał(a): > > > > > Yeah, sometimes is difficult to remember. I end going through all > changes > > > in repo to add release notes when we release. > > > Also I think is important to add some working example for two reasons: > > > > > > 1.- To ensure code is compiling (then we need some it-tests too) > > > 2.- As a way to see how to use something. > > > > > > For Jewel, I use to add it to TDJ > > > > > > > > > > > > El vie., 19 jun. 2020 a las 12:00, Harbs (<[email protected]>) > > > escribió: > > > > > > > > > > > > For example yesterday I added Jewel SimpleLoader. Don't think that > > kind > > > > of > > > > > change will need to be a PR. > > > > > > > > Agree, but we should have some way to quickly see additions. Maybe > > > > immediate update of release notes? A quick note to a wiki page? > > > > > > > > > On Jun 19, 2020, at 12:56 PM, Carlos Rovira < > [email protected] > > > > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > I'm for what Alex suggests. Just email with some kind of "[Breaking > > > > > Change]" or "[API change]" warning, so we can discuss. > > > > > I think that would be more easy and will continue to make all flow > > and > > > > > avoid freezing. I think the problem is things like my > > > > > change of "BrowserResizeHandler". > > > > > > > > > > For example yesterday I added Jewel SimpleLoader. Don't think that > > kind > > > > of > > > > > change will need to be a PR. > > > > > > > > > > I must say that, in my mind the 1.0 version is what makes us to be > > even > > > > > more careful since it's what a major version dictates. > > > > > But it's real that we are currently in something that many of us > > > consider > > > > > 1.0, so we should be more careful since now. > > > > > > > > > > thanks > > > > > > > > > > > > > > > > > > > > > > > > > El vie., 19 jun. 2020 a las 9:05, Harbs (<[email protected]>) > > > > escribió: > > > > > > > > > >> Seems like a reasonable approach. I already try to do this. > > > > >> > > > > >>> On Jun 19, 2020, at 8:24 AM, Alex Harui <[email protected] > > > > > > >> wrote: > > > > >>> > > > > >>> The cheapest solution, IMO, is just to get everyone to agree not > to > > > > >> change APIs in Basic without prior discussion. Probably major > > > code-path > > > > >> changes too. > > > > >> > > > > >> > > > > > > > > > > -- > > > > > Carlos Rovira > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5171040ec6b47f9134808d81507f546%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637282471211152255&sdata=6UVKJKiSerYce%2BNchxThfTzmRN5nA0ZYQz5FRKsyPkw%3D&reserved=0 > > > > > > > > > > > > > > -- > > > Carlos Rovira > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5171040ec6b47f9134808d81507f546%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637282471211152255&sdata=6UVKJKiSerYce%2BNchxThfTzmRN5nA0ZYQz5FRKsyPkw%3D&reserved=0 > > > > > > > > > -- > > > > Piotr Zarzycki > > > > Patreon: *https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5171040ec6b47f9134808d81507f546%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637282471211152255&sdata=B92fA0w8jk%2F0p7BLBPXfpoutODfwYgKHYeUcHoey%2Boo%3D&reserved=0 > > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5171040ec6b47f9134808d81507f546%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637282471211152255&sdata=B92fA0w8jk%2F0p7BLBPXfpoutODfwYgKHYeUcHoey%2Boo%3D&reserved=0>* > > > > > -- Piotr Zarzycki Patreon: *https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5171040ec6b47f9134808d81507f546%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637282471211162253&sdata=J0Pjky0j8%2Bd1VhdhauGIL3iUuVy0IdhwSBdQ8C1EK7M%3D&reserved=0 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5171040ec6b47f9134808d81507f546%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637282471211162253&sdata=J0Pjky0j8%2Bd1VhdhauGIL3iUuVy0IdhwSBdQ8C1EK7M%3D&reserved=0>*
