Re: [REQUEST] Squash merge please

I’ve noticed quite a few PRs in the last week that were merged with “Merge” rather than “Squash and Merge”. While the community consensus was to continue to allow all merge options, please try to default to “Squash and Merge” whenever you can to keep history as linear as possible. GitHub will s

Re: [REQUEST] Squash merge please

I think it's already resolved Udo ;) Here's the problem, if I fixup a dunit test by removing all uses of "this." and I rename the dunit test, then git doesn't remember that the file is a rename -- it forever afterwards interprets it as a new file that I created if I touch more than 50% of the line

Re: [REQUEST] Squash merge please

In addition to pointing this out.. I've found this... https://help.github.com/en/github/administering-a-repository/requiring-a-linear-commit-history I'm not sure that we need to enable this featur

Re: [REQUEST] Squash merge please

I'm not sure what this discussion is about... WE, as a community, have agreed in common practices, in two place no less... 1) Quoting our PR template For all changes: * Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? * Has your PR bee

Re: [REQUEST] Squash merge please

Once a PR is reviewed and merged, the remainder of its lifecycle could include a revert, a cherry-pick to another branch, or just browsing the git history. In general it’s most convenient for all of the above cases if 1 JIRA == 1 commit on develop. As a set-it-and-forget-it default, Squash and

Re: [REQUEST] Squash merge please

Hi Mark, I would like to limit the scope of the discussion to pushing PRs to develop as a squash and merge operation and not just merge. This is to keep the history linear and clean like other projects which will help with regression and cherry-pick (reference: first screenshot in the email chain)

Re: [REQUEST] Squash merge please

I would strongly prefer smaller as small a commit as possible. And as large as necessary. I am less partial when it comes to PRs sizes. Sometimes depending on what is done in a PR, I don’t think it makes sense to issue a blanket statement that all PRs are one commit. I think there is a strong re

Re: [REQUEST] Squash merge please

Kirk, I believe that creating a Pull Request with multiple commits is ok. It's just in the end that when it's being pushed to develop branch, it needs to be squash merged. I believe that is what you have mentioned in the first paragraph, and I am more than happy with that. If you can see in the fir

Re: [REQUEST] Squash merge please

Whenever I submit a PR with multiple commits that I intend to rebase to develop, I always try to ensure that each commit stands alone as is (compiles and passes tests). Separating file renames and refactoring from behavior changes into different commits seems very valuable to me, and I've had troub

Re: [REQUEST] Squash merge please

I wonder if Kirk's and Naba's statements are necessarily at odds. Make the change easy (warning: this may be hard), then make the easy > change." -Kent Beck Following Kent Beck's advise might reasonably split into two commits. One refactor commit and a separate commit that introduces the actual

Re: [REQUEST] Squash merge please

It is to help with bisect operations when things start failing ... helps us it revert and build faster. also with cherry picking features / fixes to previous versions . And keeping the git history clean with no unnecessary “merge commits”. Regards Naba On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund

Re: [REQUEST] Squash merge please

-1 I really like to sometimes have more than 1 commit in a PR and keep them separate when they merge to develop On Tue, Oct 22, 2019 at 5:12 PM Nabarun Nag wrote: > Hi Geode Committers, > > A kind request for using squash commit instead of using merge. > This will really help us in our bisect op

Re: [REQUEST] Squash merge please

+1 > On Oct 28, 2019, at 12:47 PM, Jacob Barrett wrote: > > +1 > > >> On Oct 22, 2019, at 5:12 PM, Nabarun Nag wrote: >> >> Hi Geode Committers, >> >> A kind request for using squash commit instead of using merge. >> This will really help us in our bisect operations when a >> regression/f

Re: [REQUEST] Squash merge please

Yup. I am a little annoyed at myself about that.. Thanks for the reminder though. Mark > On Nov 5, 2019, at 11:48 AM, Owen Nichols wrote: > > +1 > > When merging a PR from GitHub, if the green button does not already say > “Squash and merge”, click the little triangle and select “Squash and

Re: [REQUEST] Squash merge please

+1 When merging a PR from GitHub, if the green button does not already say “Squash and merge”, click the little triangle and select “Squash and merge”. In addition to all the reasons already listed in this thread, it make reverts a lot cleaner too. > On Oct 28, 2019, at 12:47 PM, Jacob Barrett

Re: [REQUEST] Squash merge please

+1 > On Oct 22, 2019, at 5:12 PM, Nabarun Nag wrote: > > Hi Geode Committers, > > A kind request for using squash commit instead of using merge. > This will really help us in our bisect operations when a regression/flakiness > in the product is introduced. We can automate and go through fewe