Re: [scikit-learn] The culture of commit squashing

Yes, I tried to work that out regarding @afouchet and @tguillemot's work, but I may have failed to. However, both are credited in what's new, etc... And commit counts really say little. On 19 June 2016 at 09:18, Raghav R V wrote: > IMHO the squash and merge should not be used when there are comm

Re: [scikit-learn] The culture of commit squashing

IMHO the squash and merge should not be used when there are commits from 2 or more different authors to avoid crediting only a single author. On Tue, Jun 14, 2016 at 6:40 PM, Tom DLT wrote: > @Andreas > It's a bit hidden: You need to click on "Merge pull-request", then do > *not* click on "Confi

Re: [scikit-learn] The culture of commit squashing

@Andreas It's a bit hidden: You need to click on "Merge pull-request", then do *not* click on "Confirm merge", but on the small arrow to the right, and select "Squash and merge". 2016-06-14 18:13 GMT+02:00 Andreas Mueller : > I'm +1 for using the button when appropriate. > I think it should be up

Re: [scikit-learn] The culture of commit squashing

I'm +1 for using the button when appropriate. I think it should be up to the merging person to make a call whether a squash is a better logical unit than all the commits. I would set like a soft limit at ~5 commits or something. If your PR has more than 5 separate big logical units, it's proba

Re: [scikit-learn] The culture of commit squashing

Oh wow, that looks like a neat feature, didn’t know about this, thanks for sharing! (And I would be in favor of this) > On Jun 14, 2016, at 5:34 AM, Tom DLT wrote: > > We could stop squashing during development, and use the new Squash-and-Merge > button on GitHub. > What do you think? > Tom >

Re: [scikit-learn] The culture of commit squashing

Sounds good to me. Thank goodness someone reads the documentation! On 14 June 2016 at 19:51, Alexandre Gramfort < alexandre.gramf...@telecom-paristech.fr> wrote: > > We could stop squashing during development, and use the new > Squash-and-Merge > > button on GitHub. > > What do you think? > > +1

Re: [scikit-learn] The culture of commit squashing

> We could stop squashing during development, and use the new Squash-and-Merge > button on GitHub. > What do you think? +1 the reason I see for squashing during dev is to avoid killing the browser when reviewing. It really rarely happens though. A ___

Re: [scikit-learn] The culture of commit squashing

We could stop squashing during development, and use the *new* Squash-and-Merge button on GitHub. What do you think? Tom 2016-06-14 8:06 GMT+02:00 Matthieu Brucher : > I don't even think that squashing them before the merge is actually sound. > Y

Re: [scikit-learn] The culture of commit squashing

I don't even think that squashing them before the merge is actually sound. You will still need the history of why something happened several years down the road (and rebasing actually has a similar issue). This bit me quite often (having just one big commit to analyze after a merge from ancient VCS

Re: [scikit-learn] The culture of commit squashing

I think the main idea behind commit squashes is to make sure that every *commit* passes testing, rather than only merge commits. This is important because there's no way to tell git bisect to only look at merge commits. So when you are doing a git bisect to hunt down a regression or bug, it is very

Re: [scikit-learn] The culture of commit squashing

My concern is that people are responding to being asked to squash on one PR by squashing during development on the next (as if merge were always imminent). I want that to stop. Is part of the solution to stop squashing, or make the person merging always perform the squash? On 14 June 2016 at 12:53

Re: [scikit-learn] The culture of commit squashing

Hi, Joel, in my opinion, it really depends on the particular case, but in general I am pro squashing — that is, when it happens at the very end. I also agree that squashing and force pushing while there’s still a review going on is clearly disruptive. Say there’s a new estimator being added. Th

Re: [scikit-learn] The culture of commit squashing

I agree that it adds some annoying overhead. For me, one of the main motivations is to make cherry picks for bugfix releases easier. It's very hard to cherry pick things that are spread out over many commits, and it's hard to find the relevant bug fixes among hundreds of minor commits. This rea

Re: [scikit-learn] The culture of commit squashing

On 06/13/2016 09:36 PM, Joel Nothman wrote: (And apologies for wasting your time on such a silly issue, but I'm sick of clicking links in emails to find the commit's disappeared.) I really see no reason why someone should squash something before it is ready to be merged. (as Jacob suggested).

Re: [scikit-learn] The culture of commit squashing

My research work involves frequently contributing small changes. I like to keep these around as a record of what I've done, until I've finished with that part of the code. However, I also hate having large numbers of commits (frequently can commit 50+ times a day without much substantitve progress)

[scikit-learn] The culture of commit squashing

For the last few years, there's been a notion that we should squash PRs down to a single commit before merging. Squashing can give a cleaner commit history, and avoid overrepresentation of minor work given silly commit count metrics used by Github and others. I'm not sure if there are other motivat