Re: [DISCUSS] Proposal to require linear commit history on develop

I'm also using Blake's approach when dealing with refactoring + code changes, it's clear and it never caused me any troubles so far. +1 to to require linear commit history on develop. Cheers. On Thu, Jan 2, 2020 at 6:03 PM Mark Hanson wrote: > This is the approach I am using as well Blake. > > T

Re: [DISCUSS] Proposal to require linear commit history on develop

This is the approach I am using as well Blake. Thanks, Mark > On Jan 2, 2020, at 7:16 AM, Blake Bender wrote: > > That's not how I approach this sort of a change, and to my mind it feels > sort of like that approach is asking for trouble. When I have a refactor > plus a code change, I do the r

Re: [DISCUSS] Proposal to require linear commit history on develop

@onichols Correction: The 'git-flow' workflow that Geode follows is to merge a release commit to master and to develop. On Thu, Dec 19, 2019 at 4:51 PM Owen Nichols wrote: > Dan, to address some of your concerns: > > This proposal is to block merge commit on develop only. The release > process

Re: [DISCUSS] Proposal to require linear commit history on develop

That's not how I approach this sort of a change, and to my mind it feels sort of like that approach is asking for trouble. When I have a refactor plus a code change, I do the refactor on a branch, submit the PR, then branch off of *that* branch to do the feature work. This forces an ordering of t

Re: [DISCUSS] Proposal to require linear commit history on develop

> > Is it not the case currently? If I am working on a feature modifying class > X and another developer makes some refactoring changes on class X and > pushes it to develop, won't I have to resolve the merge commits anyway. Yes, you will always have to deal with resolving conflicts with other pe

Re: [DISCUSS] Proposal to require linear commit history on develop

It sounds like there is value in being able to deliver un-squashed PRs, and we believe the richer commit message history outweighs any potential inconvenience to bisect operations (as Aaron pointed out, finer-grained commits should generally be to the benefit of bisect operations). We will leave a

Re: [DISCUSS] Proposal to require linear commit history on develop

I also tend to do the same workflow Aaron described - make a refactoring change to support a feature followed by the actual change I want to make. It makes the history a lot clearer because refactoring tends to touch a lot of files, so it's nice to have those changes clearly marked as a refactoring

Re: [DISCUSS] Proposal to require linear commit history on develop

-1 on removing rebase option. I use it frequently to void squashing properly independent commits, like a cleanup or refactor and then a fix commit. -Jake > On Dec 31, 2019, at 3:10 PM, Owen Nichols wrote: > > To recap, this proposal is now revised to remove 2 of the 3 merge options > from Gi

Re: [DISCUSS] Proposal to require linear commit history on develop

Aaron , Is it not the case currently? If I am working on a feature modifying class X and another developer makes some refactoring changes on class X and pushes it to develop, won't I have to resolve the merge commits anyway. Regards Naba On Tue, Dec 31, 2019 at 6:01 PM Aaron Lindsey wrote: >

Re: [DISCUSS] Proposal to require linear commit history on develop

Suppose I’m refactoring the same classes I’m touching for the feature. I do the refactoring on one branch and submit a PR for that. Then I implement the feature on another branch which is based on develop and does not have the refactoring changes since those are not merged yet. I’ll have to reso

Re: [DISCUSS] Proposal to require linear commit history on develop

Can you elaborate on why you would have to deal with conflicts if the refactoring work was kept as a separate PR from the fix? As with many git workflows, there’s an easy way and a hard way to manage interdependent PRs (tl;dr only merge, never rebase!). I wonder if this points out an opportunity f

Re: [DISCUSS] Proposal to require linear commit history on develop

-0.9 I’m not in favor of the revised proposal that disallows rebase-and-merge. Say I am working on a PR and I have a refactor commit and another commit which implements a new feature. I don’t want those commits to get squashed because that makes it hard to understand the diff. However, if I mak

Re: [DISCUSS] Proposal to require linear commit history on develop

To recap, this proposal is now revised to remove 2 of the 3 merge options from GitHub, leaving only Squash and Merge. PR #4513 serves as an exhibit of what is proposed (it is not to be merged unless discussion leads to consensus and a successful vote).

Re: [DISCUSS] Proposal to require linear commit history on develop

I'm happy to file multiple PRs when I need to merge multiple commits to develop. On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson wrote: > This change to disable all but squash-merge would be really easy to > revert. How about we try it for a while and see? If people decide it is > really limiting th

Re: [DISCUSS] Proposal to require linear commit history on develop

This change to disable all but squash-merge would be really easy to revert. How about we try it for a while and see? If people decide it is really limiting them, we can change it back. Let’s do it for 1 month and see how it goes. Does that sound reasonable? Thanks, Mark > On Dec 30, 2019, at 5

Re: [DISCUSS] Proposal to require linear commit history on develop

Given that we adopted and still wish to continue

Re: [DISCUSS] Proposal to require linear commit history on develop

Bruce, you’re right, there doesn’t seem to be consensus, and a PR was premature. I was reminded this week that voting is a “last resort”, not the way to build consensus. I have withdrawn the PR. On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt wrote: > I'm a proponent of using squash-and-merge

Re: [DISCUSS] Proposal to require linear commit history on develop

Just FWIW, the situation described of having multiple commits in a single PR with separate associated JIRA tickets is still kind of problematic. It could well be the case that the commits are interdependent, thus when bisecting etc it's still not possible to revert the fix for a single bug/feature

Re: [DISCUSS] Proposal to require linear commit history on develop

Hi Dan, When we do squash merge all the commit messages are preserved and also the co-authored tag works when we do squash merge. So the authorship and history are preserved. In my own personal experience and reverts and pinpointing regression failures are tough when the commits are spread out. A

Re: [DISCUSS] Proposal to require linear commit history on develop

This was the part I was referring to, from the existing PR template: > Update the PR template to change the text "Is your initial contribution > a single, squashed commit” to “Is your initial contribution squashed for > ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a > ‘fix’

Re: [DISCUSS] Proposal to require linear commit history on develop

I'll change to -0. I think merge commits are a nice way to record history in some cases, and can also be a way to avoid messy conflicts that come with rebase. Merge commits also preserve authorship of commits (compared to squash-merge), which I think is valuable as an open source community that is

Re: [DISCUSS] Proposal to require linear commit history on develop

We are not trying to force devs to squash prior to committing a PR. There was old language in the PR template that stated this, which we are relaxing to emphasize submitting your PR in a way that is most amenable to review. The geode-native repo does not appear to have a .github/PULL_REQUEST_

Re: [DISCUSS] Proposal to require linear commit history on develop

Just to reiterate. Nothing changes in the workflow of a developer. It's just in the end, when all the reviews are done and all the tests are passing, then the button to click in the Github web UI is "Squash and Merge". That's all. Regards Naba On Fri, Dec 20, 2019 at 11:55 AM Blake Bender wrot

Re: [DISCUSS] Proposal to require linear commit history on develop

Very well, then, I'll abide by the group consensus but am on the record as: * strongly opposed to multi-commit PRs, because I believe it clutters history, and * also not a big fan of forcing devs to rebase and squash prior to submitting a PR. IMO this is busy work, and *may* in some small minority

Re: [DISCUSS] Proposal to require linear commit history on develop

Whether we are talking about the geode/ repository or the geode-native/ repository we are all one GEODE community. The idea of a native client team may matter in some contexts but in this space we are all GEODE contributors. Adopting a common approach across our repos will make it easier for ne

Re: [DISCUSS] Proposal to require linear commit history on develop

Just to be clear, this proposal wouldn't require anyone to squash their commits before merging a PR. All it’s saying is that if you do have multiple commits in your PR, you would have to rebase those commits onto develop before merging to ensure a linear commit history. - Aaron > On Dec 20, 20

Re: [DISCUSS] Proposal to require linear commit history on develop

Is this a policy the native client team must abide by, as well? It varies slightly with what we've been doing, and all other things being equal I see no reason for us to change that. If I am to have any measure of control over the nc repository, I will definitely enforce a 1:1 correspondence betw

Re: [DISCUSS] Proposal to require linear commit history on develop

Merge commit is the new contributor's default setting. When we are merging new contributor's PR, since we are so used to THINKING "squash-and-merge" is the default, we forgot to check what the button really says when we are merging other people's PR. On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghar

Re: [DISCUSS] Proposal to require linear commit history on develop

The objections in the discuss thread all seemed to hinge on item 2) of the original proposal. With this item removed, perhaps many or all of those people would no longer vote -1. Please feel free to “request changes” on the PR if you still want something different -or- to indicate you believe

Re: [DISCUSS] Proposal to require linear commit history on develop

I'm a proponent of using squash-and-merge, and once a person has chosen this option once it comes up by default afterwards... Owen, I don't think you have consensus to put forth this PR, there are -1s above... (early voting) maybe we'll be better off socializing the norm of squash-and-merge and

Re: [DISCUSS] Proposal to require linear commit history on develop

well, I always use squash-and-merge so I'm not against the primary motivation for this thread. On 12/20/19 10:07 AM, Owen Nichols wrote: The proposed action manifests as a commit to the Geode git repository, so a PR is an acceptable vehicle for voting in this case. On Dec 20, 2019, at 9:38 A

Re: [DISCUSS] Proposal to require linear commit history on develop

The proposed action manifests as a commit to the Geode git repository, so a PR is an acceptable vehicle for voting in this case. > On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt wrote: > > I see a lot of plus-ones and a "voting deadline" on this DISCUSS thread and a > request to "vote" using a

Re: [DISCUSS] Proposal to require linear commit history on develop

I see a lot of plus-ones and a "voting deadline" on this DISCUSS thread and a request to "vote" using a PR.  This all seems out of order to me.  Our votes are supposed to be on the email list, aren't they? and I haven't seen a VOTE request. On 12/20/19 9:33 AM, Nabarun Nag wrote: +1 On Fri,

Re: [DISCUSS] Proposal to require linear commit history on develop

+1 On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols wrote: > Based on the feedback so far, I will amend the proposal to drop item 2). > Therefore, the current ability to create merge commits using command-line > git will remain available. > > The proposal as amended is now: > > Change GitHub setting

Re: [DISCUSS] Proposal to require linear commit history on develop

Based on the feedback so far, I will amend the proposal to drop item 2). Therefore, the current ability to create merge commits using command-line git will remain available. The proposal as amended is now: > Change GitHub settings to make "Squash and merge" the default > (by removing “Create a

Re: [DISCUSS] Proposal to require linear commit history on develop

+1 to (1) and (3) I’m on board with (1). I’m hesitant about agreeing to (2) because it seems harder to “accidentally” do a merge commit via the command line, and I don’t want to add unnecessary restrictions. (3) has needed to be done for some time now, so I’m happy to see a proposal to change t

Re: [DISCUSS] Proposal to require linear commit history on develop

+1 On Fri 20 Dec 2019 at 16:18, Owen Nichols wrote: > Hi Bruce, this proposal will not waste a single second of your time. It > just prevents people from accidentally pressing a button that we have > already agreed should never be pressed, but because we never configured our > GitHub to match o

Re: [DISCUSS] Proposal to require linear commit history on develop

Hi Bruce, this proposal will not waste a single second of your time. It just prevents people from accidentally pressing a button that we have already agreed should never be pressed, but because we never configured our GitHub to match our stated policy, is currently the default. However, it wil

Re: [DISCUSS] Proposal to require linear commit history on develop

Yes, I got freaked out somehow this morning by thinking I had accidentally clicked the wrong button to include all the individual commits in my PR to the develop branch, (luckily it's just a wrong view). I would think disable that button would be a good idea. On Thu, Dec 19, 2019 at 5:04 PM Nabaru

Re: [DISCUSS] Proposal to require linear commit history on develop

I agree with Jake.  I would go further by saying that I see very little merit in this proposal.  I think we're getting more and more bureaucratic in our process and that it stifles productivity.  I was recently forced to spend three days fixing tests in which I had changed an import statement b

Re: [DISCUSS] Proposal to require linear commit history on develop

Hi all, This is not a blanket restriction. My suggestion, like last time, lets try it out and this time we don't even need Apache Infra to step in. Feels like it has been requested in multiple INFRA JIRAs by so many Apache projects to enable only the squash merge button and disable the others, tha

Re: [DISCUSS] Proposal to require linear commit history on develop

If the appropriate or necessary process is a merge then this proposal prevents that. I am not interested in any hard restrictions like this. You proposal in response to dan is not palatable by disabling merges via github but allowing it manually. > On Dec 19, 2019, at 4:54 PM, Owen Nichols wr

Re: [DISCUSS] Proposal to require linear commit history on develop

This proposal in no way prevents you from getting work done. Squash is always enabled and always the most acceptable way to bring changes to develop. Please start a separate thread if you would like to revisit the community decision to require passing PR checks. > On Dec 19, 2019, at 4:49 PM,

Re: [DISCUSS] Proposal to require linear commit history on develop

Dan, to address some of your concerns: This proposal is to block merge commit on develop only. The release process makes a merge commit to master only. This proposal explicitly allows reasonably separate and well written commits in a single PR. For this case simply choose Rebase & Merge, and

Re: [DISCUSS] Proposal to require linear commit history on develop

I’m in agreement with Dan. Changes to the infrastructure to flat out prevent things that should be self policing is annoying. This PR review lock we have had already cost us valuable time waiting for PR pipelines to pass that have no relevance to the commit, like CI work: I’d hat to see yet anot

Re: [DISCUSS] Proposal to require linear commit history on develop

+1 > On Dec 19, 2019, at 4:27 PM, Jinmei Liao wrote: > > +1 > > On Thu, Dec 19, 2019, 4:05 PM Owen Nichols wrote: > >> I’d like to advance this topic from an informal request/discussion to a >> discussion of a concrete proposal. >> >> To recap, it sounds like there is general agreement that

Re: [DISCUSS] Proposal to require linear commit history on develop

-1 to (1) and (2). I think merge commits are appropriate in certain circumstances, so I don't think we should make a blanket restriction. In fact I think our release process involves some merges. I think setting standards on what is reasonable to be an individual commit will do a lot more to clea

Re: [DISCUSS] Proposal to require linear commit history on develop

+1 On Thu, Dec 19, 2019, 4:05 PM Owen Nichols wrote: > I’d like to advance this topic from an informal request/discussion to a > discussion of a concrete proposal. > > To recap, it sounds like there is general agreement that commit history on > develop should be linear (no merge commits), and th

[DISCUSS] Proposal to require linear commit history on develop

I’d like to advance this topic from an informal request/discussion to a discussion of a concrete proposal. To recap, it sounds like there is general agreement that commit history on develop should be linear (no merge commits), and that the biggest obstacle to this is that the PR merge button in