You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Owen Nichols <on...@pivotal.io> on 2020/04/09 18:45:00 UTC
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 save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> 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 fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Aaron Lindsey <al...@vmware.com>.
+1 to keep only "Squash and merge" and "Rebase and merge".
Aaron Lindsey
________________________________________
From: Robert Houghton <rh...@vmware.com>
Sent: Monday, June 28, 2021 2:31 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
I for one do not like revisionist history (rebase) but understand that linear history is easier for bisect.
From: Blake Bender <bb...@vmware.com>
Date: Monday, June 28, 2021 at 2:24 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: RE: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1, only because I only get one vote. Merge commits in develop are a scourge, IMO, and should be avoided in almost all instances.
Blake
-----Original Message-----
From: Donal Evans <do...@vmware.com>
Sent: Monday, June 28, 2021 2:22 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
I definitely approve of this proposal. I accidentally merged (rather than squashed and merged) a PR a while back because my GitHub session had expired and refreshing the page after trying to squash and merge resulted in the default merge option being used, much to my frustration. I've yet to see any explanation of why we would need to merge PRs rather than squash and merge/rebase and merge, so removing it as an option just seems like a good idea.
________________________________
From: Nabarun Nag <nn...@vmware.com>
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols <on...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can't find any example of an intentional merge commit on develop...but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don't like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Calindsey%40vmware.com%7C4e593a623f154464739208d93a7c1a06%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605126957444163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8hqSLfd%2BkE3YWB%2FVzmC1zUFIloQVOKun%2BRjxGpU%2BSx0%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: 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 save the last method you used in a cookie, which helps, but then it's easy to miss when it resets itself back to the default of "Merge" some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> 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 fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Robert Houghton <rh...@vmware.com>.
I for one do not like revisionist history (rebase) but understand that linear history is easier for bisect.
From: Blake Bender <bb...@vmware.com>
Date: Monday, June 28, 2021 at 2:24 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: RE: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1, only because I only get one vote. Merge commits in develop are a scourge, IMO, and should be avoided in almost all instances.
Blake
-----Original Message-----
From: Donal Evans <do...@vmware.com>
Sent: Monday, June 28, 2021 2:22 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
I definitely approve of this proposal. I accidentally merged (rather than squashed and merged) a PR a while back because my GitHub session had expired and refreshing the page after trying to squash and merge resulted in the default merge option being used, much to my frustration. I've yet to see any explanation of why we would need to merge PRs rather than squash and merge/rebase and merge, so removing it as an option just seems like a good idea.
________________________________
From: Nabarun Nag <nn...@vmware.com>
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols <on...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can't find any example of an intentional merge commit on develop...but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don't like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Crhoughton%40vmware.com%7C28d3ef66dcbd4a012c2708d93a7b1fae%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605122768804796%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B7O6XEhmT%2B%2BYUvSWB1Oo8x7EWeR0QXQJbmX%2FXi5yAjQ%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: 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 save the last method you used in a cookie, which helps, but then it's easy to miss when it resets itself back to the default of "Merge" some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> 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 fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
RE: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Blake Bender <bb...@vmware.com>.
+1, only because I only get one vote. Merge commits in develop are a scourge, IMO, and should be avoided in almost all instances.
Blake
-----Original Message-----
From: Donal Evans <do...@vmware.com>
Sent: Monday, June 28, 2021 2:22 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
I definitely approve of this proposal. I accidentally merged (rather than squashed and merged) a PR a while back because my GitHub session had expired and refreshing the page after trying to squash and merge resulted in the default merge option being used, much to my frustration. I've yet to see any explanation of why we would need to merge PRs rather than squash and merge/rebase and merge, so removing it as an option just seems like a good idea.
________________________________
From: Nabarun Nag <nn...@vmware.com>
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols <on...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can't find any example of an intentional merge commit on develop...but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don't like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cbblake%40vmware.com%7C066ef87d04274938120e08d93a7aca8c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605121332992373%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=py04h%2Bho30POoZjPcBeuVtp%2FeeSYylGtSTGbN9%2FLylM%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: 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 save the last method you used in a cookie, which helps, but then it's easy to miss when it resets itself back to the default of "Merge" some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> 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 fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Donal Evans <do...@vmware.com>.
I definitely approve of this proposal. I accidentally merged (rather than squashed and merged) a PR a while back because my GitHub session had expired and refreshing the page after trying to squash and merge resulted in the default merge option being used, much to my frustration. I've yet to see any explanation of why we would need to merge PRs rather than squash and merge/rebase and merge, so removing it as an option just seems like a good idea.
________________________________
From: Nabarun Nag <nn...@vmware.com>
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols <on...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cdoevans%40vmware.com%7Cef26879ce10c4d1723aa08d93a703283%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605075839553972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sv2SivfEegOYY3p3NnJT85On%2FqT8l8X5%2BwXySPNEKFo%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: 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 save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> 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 fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Nabarun Nag <nn...@vmware.com>.
Looking at the positive feedback, to this, I am skipping the red tape of creating a separate vote thread. The PR has been created and reviewed.[1]
Regards,
Nabarun
[1] https://github.com/apache/geode/pull/6661
________________________________
From: Darrel Schneider <da...@vmware.com>
Sent: Tuesday, June 29, 2021 9:13 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1
________________________________
From: Jens Deppe <jd...@vmware.com>
Sent: Tuesday, June 29, 2021 7:44 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 For Naba’s proposal
From: Joris Melchior <jm...@vmware.com>
Date: Tuesday, June 29, 2021 at 7:40 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 for Naburan’s proposed options.
From: Nabarun Nag <nn...@vmware.com>
Date: Monday, June 28, 2021 at 4:06 PM
To: Owen Nichols <on...@vmware.com>, dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cnnag%40vmware.com%7C7bf2d2f76d0b4178ced608d93b18d831%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605800176784198%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gm1WMtsbaSzCffY84dCjCEgNSSezeROj24bVWupCQoo%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: 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 save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> 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 fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Darrel Schneider <da...@vmware.com>.
+1
________________________________
From: Jens Deppe <jd...@vmware.com>
Sent: Tuesday, June 29, 2021 7:44 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 For Naba’s proposal
From: Joris Melchior <jm...@vmware.com>
Date: Tuesday, June 29, 2021 at 7:40 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 for Naburan’s proposed options.
From: Nabarun Nag <nn...@vmware.com>
Date: Monday, June 28, 2021 at 4:06 PM
To: Owen Nichols <on...@vmware.com>, dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cdarrel%40vmware.com%7Cb606c0b76cde45a6544b08d93b0c784e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605747017170771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fN3%2FKtamPVe6HVQqn%2BREi2n%2BP1iQPRtadol6w3xl%2F3I%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: 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 save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> 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 fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Jens Deppe <jd...@vmware.com>.
+1 For Naba’s proposal
From: Joris Melchior <jm...@vmware.com>
Date: Tuesday, June 29, 2021 at 7:40 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
+1 for Naburan’s proposed options.
From: Nabarun Nag <nn...@vmware.com>
Date: Monday, June 28, 2021 at 4:06 PM
To: Owen Nichols <on...@vmware.com>, dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cjdeppe%40vmware.com%7C6fa6793b726442ef3a0808d93b0be198%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637605744486487010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=u2ACIO9HM1BRNpKUpALLp0UtW2vJnioIPqjEvD79f1c%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: 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 save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> 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 fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Joris Melchior <jm...@vmware.com>.
+1 for Naburan’s proposed options.
From: Nabarun Nag <nn...@vmware.com>
Date: Monday, June 28, 2021 at 4:06 PM
To: Owen Nichols <on...@vmware.com>, dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwhatisworkspaceone.com%2Fboxer&data=04%7C01%7Cjmelchior%40vmware.com%7C9d91cbfd72dd431f164a08d93a703563%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637605075886246400%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ECvN2VaHpuI3XPq6C2pjue8rHmJetmrOzMPqhgKxfPI%3D&reserved=0>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: 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 save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> 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 fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Nabarun Nag <nn...@vmware.com>.
Just a clarification.
The options I am proposing to be kept in the PRs are:
* Squash and merge
* Rebase and merge
Regards,
Nabarun
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag <nn...@vmware.com>; dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: 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 save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> 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 fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Owen Nichols <on...@vmware.com>.
Sounds like a good idea. I can’t find any example of an intentional merge commit on develop…but plenty of accidental ones.
Upon releases we do a command line merge commit to the main trunk, which should still be fine as this proposal only applies to PRs.
I agree with still allowing rebase commits. I have seen several PRs use them to good effect.
You can disable merge commits through .asf.yaml, so changing the setting is as easy as opening a PR (and, if we don’t like it, reverting is just as easy)
---
Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer>
On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag <nn...@vmware.com> wrote:
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: 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 save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> 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 fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>
Re: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Jacob Barrett <ja...@vmware.com>.
> On Jun 28, 2021, at 12:38 PM, Nabarun Nag <nn...@vmware.com> wrote:
>
>
> I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Does this proposal remove the option to “Rebase and Merge?
Fw: [DISCUSS] Rebase and Squash Options on Github develop
Posted by Nabarun Nag <nn...@vmware.com>.
Hi all,
Last year, we had a discussion on rebase and squash merge PRs to the develop branch,
* to have linear git history
* help with bisecting
* easier root cause analysis of failures
* easier to backport changes
However, many developers have reached out mentioning that sometimes they have clicked the merge button in hurry when they meant to rebase/squash. Once clicked there is no going back. All of them suggested that to have the GitHub setting on develop branch to rebase and squash merge option and hence there is no room for mistakes to occur.
I would like to propose to that we set the GitHub setting on develop PR to rebase and squash buttons.
Please do note that this is reversible and can be changed back, hence there is no harm in trying it out.
Regards
Nabarun Nag
________________________________
From: Owen Nichols (Pivotal) <on...@pivotal.io>
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: 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 save the last method you used in a cookie, which helps, but then it’s easy to miss when it resets itself back to the default of “Merge” some months later because you cleared cookies, changed browsers, etc.
> On Oct 22, 2019, at 5:12 PM, Nabarun Nag <nn...@pivotal.io> 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 fewer commits faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what is the history)
> GEODE-xxxx: <brief intro >
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>