And when using git-blame to see why I line was changed, I think multiple commits allow a lot more fine-gained level of information.
Chris Am 20.06.20, 12:52 schrieb "Piotr Zarzycki" <[email protected]>: 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 > > > > > http://about.me/carlosrovira > > > > > > > > > > > > > > -- > > > Carlos Rovira > > > http://about.me/carlosrovira > > > > > > > > > -- > > > > Piotr Zarzycki > > > > Patreon: *https://www.patreon.com/piotrzarzycki > > <https://www.patreon.com/piotrzarzycki>* > > > > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
