Re: Squash vs merge of PRs
Hi, thnaks for all the responses. Robert and I figured everything out. He merged with squasihng for that PR. I fully agree that sometimes *not* squashing everthing is a good idea. If you want to control that, you can do this all in your local branch (I generally do this before I merge) to "clean up history" and the force-push to my own github repo. After that yo can manually merge into main. We did this last time when we change the java formatter version, because the commits with the pure-formatter-cleanups should be excluded from git blame. I take care of readability of history and because of that I wanted to bring this issue up here. Normally for small self-contained changes, everything should be squashed. If one keeps the original branch the hitsory is not gone. We can also preserve complex branches in the official git repo (like we preserved Mike's refactoring to use Codecs in 4.0). My problem with the Hotspot cleanup branch was that there were many small commits, often reverting what was done before and at end the PR was quite small (as we did some stuff in separate PRs before). In those cases it is easier for a reader of the PR and the Git history to have all commits next to each other. Final note: Never squashing branches also does not prevent merge conflicts. I often figured out that non-squashed branches having many commits often merge harder than a clean commit. So my final words: For small self contained changes we should really use Github UI and squash everything together. All contributors are preserved (because Git collects them and adds the extra Git tags to preserve them). This makes a nice-looking history with "rmuir and uschindler authored XY". If it is a complex change covering many commits we can keep commits, but should make them more readable. And in that case each inner commit should refer to the original issue number. Otherwise it is hard to follow to where it belongs. Uwe Am 04.11.2023 um 17:33 schrieb Gus Heck: For what it's worth I basically agree with Michael Sokolov with the caveat that I think it's sometimes useful to create a clean branch and re-pick the changes if the merging has become complex just to make sure you are not accidentally reverting anything vs what is on head unintentionally. Squashing has always worried me but not severely, so I do it when requested. Part of it hinges on commit style too. If you regularly have lots of frequent, small commits including broken, non-compiling state, then squashing might be a good idea. -Gus On Sat, Nov 4, 2023 at 11:59 AM Michael Sokolov wrote: Personally for me it's about how meaningful the commit messages (and contents) are vs whether we use merge commits or not. If it;s a long series of "fixed bug" "reformatted" "did stuff" "more stuff" "it finally works" and so on ... that doesn't smell good to me, but you know we all have done that from time to time too, either by accident or because we're in a rush and didn't practice perfect hygiene. I guess the commit branching/linear purity debate is mostly a matter of taste; we can try to have some standards, but we should be forgiving and not try to dictate with automation. Honestly I didn't look at whatever Robert's commits were that started this discussion since it seems to have metastasized into a general commit history health discussion so just throwing another opinion into the mix here, maybe getting off topic sorry. On Sat, Nov 4, 2023 at 11:18 AM Michael McCandless wrote: I didn't realize the community had decided squashing (rewriting history) was our standard. > Comparing histories between branches with git-bisect to find bugs is just one example. But if the bug was introduced in one of the N local commits the developer had done, wouldn't that be helpful? You could see that one commit instead of all N squashed, and get better context on how/why the bug was introduced? I would prefer history-preserving commits. It can reveal/preserve important information -- like we tried one approach, and discovered some issue, tweaked it to a better approach. This can be useful in the future if someone is working on that part of the code and is trying to understand why it was done a certain way. It preserves the natural and healthy iterations we all experience when working closely together. Why discard such possibly helpful history? Also, one can always wear hazy glasses in the future to "summarize" the full history down to a view that's more palatable to them personally, if you don't like seeing merge commit branching. But we cannot do the reverse. Discarding the actual development history is a one-way door. http://blog.mikemccandless.com On Sat, Nov 4, 2023 at 11:03 AM Gus Heck
Re: Squash vs merge of PRs
For what it's worth I basically agree with Michael Sokolov with the caveat that I think it's sometimes useful to create a clean branch and re-pick the changes if the merging has become complex just to make sure you are not accidentally reverting anything vs what is on head unintentionally. Squashing has always worried me but not severely, so I do it when requested. Part of it hinges on commit style too. If you regularly have lots of frequent, small commits including broken, non-compiling state, then squashing might be a good idea. -Gus On Sat, Nov 4, 2023 at 11:59 AM Michael Sokolov wrote: > Personally for me it's about how meaningful the commit messages (and > contents) are vs whether we use merge commits or not. If it;s a long series > of "fixed bug" "reformatted" "did stuff" "more stuff" "it finally works" > and so on ... that doesn't smell good to me, but you know we all have done > that from time to time too, either by accident or because we're in a rush > and didn't practice perfect hygiene. I guess the commit branching/linear > purity debate is mostly a matter of taste; we can try to have some > standards, but we should be forgiving and not try to dictate with > automation. Honestly I didn't look at whatever Robert's commits were that > started this discussion since it seems to have metastasized into a general > commit history health discussion so just throwing another opinion into the > mix here, maybe getting off topic sorry. > > On Sat, Nov 4, 2023 at 11:18 AM Michael McCandless < > luc...@mikemccandless.com> wrote: > >> I didn't realize the community had decided squashing (rewriting history) >> was our standard. >> >> > Comparing histories between branches with git-bisect to find bugs is >> just one example. >> >> But if the bug was introduced in one of the N local commits the developer >> had done, wouldn't that be helpful? You could see that one commit instead >> of all N squashed, and get better context on how/why the bug was introduced? >> >> I would prefer history-preserving commits. It can reveal/preserve >> important information -- like we tried one approach, and discovered some >> issue, tweaked it to a better approach. This can be useful in the future >> if someone is working on that part of the code and is trying to understand >> why it was done a certain way. It preserves the natural and healthy >> iterations we all experience when working closely together. Why discard >> such possibly helpful history? >> >> Also, one can always wear hazy glasses in the future to "summarize" the >> full history down to a view that's more palatable to them personally, if >> you don't like seeing merge commit branching. But we cannot do the >> reverse. Discarding the actual development history is a one-way door. >> >> http://blog.mikemccandless.com >> >> >> On Sat, Nov 4, 2023 at 11:03 AM Gus Heck wrote: >> >>> Also, since (as noted) this is a previously decided issue, not sure why >>> this is a list email instead of a simple direct query to Robert seeking to >>> understand the specific case? No need to make a public discussion unless >>> it's a long term pattern, actually breaking something, or we want to change >>> something? >>> >>> On Sat, Nov 4, 2023 at 9:37 AM Benjamin Trent >>> wrote: >>> TL;DR, forcing non-committers to squash things is a good idea. Enforcing through some measure for committers is a bad idea. Since this thread is now in Robert's spam, I am guessing it won't have any impact :). I do not think Robert is actively trying hurt the project in any way. It seems to me that he doesn't think a clean git history is worth the effort. Having a clean git history makes things easier for everyone. Comparing histories between branches with git-bisect to find bugs is just one example. Another is simply reading commits to see when features/bug fixes/etc. were added. I do NOT think we should add procedures or branch protections to actively enforce this. Small personal sacrifices (like dealing with commit conflicts) are necessary for a community. Being part of a community is about buying into what the community is about and working towards a common goal. Many times we do things we don't agree with, or make things slightly more difficult for us, for the community as a whole. This thing being OSS shows that we all buy into its importance and are willing to put work into the project. Having a cultural default of "make things nice for others" is good. Enforcing this ideology on others is antithesis to its definition. On Sat, Nov 4, 2023 at 9:02 AM Robert Muir wrote: > This isn't a community issue, it is me avoiding useless unnecessary > merge conflicts. Word "community" is invoked here to try to make it > out, like you can hold a vote about what git commands i should type on > my computer? You know that isn't gonna work.
Re: Squash vs merge of PRs
Personally for me it's about how meaningful the commit messages (and contents) are vs whether we use merge commits or not. If it;s a long series of "fixed bug" "reformatted" "did stuff" "more stuff" "it finally works" and so on ... that doesn't smell good to me, but you know we all have done that from time to time too, either by accident or because we're in a rush and didn't practice perfect hygiene. I guess the commit branching/linear purity debate is mostly a matter of taste; we can try to have some standards, but we should be forgiving and not try to dictate with automation. Honestly I didn't look at whatever Robert's commits were that started this discussion since it seems to have metastasized into a general commit history health discussion so just throwing another opinion into the mix here, maybe getting off topic sorry. On Sat, Nov 4, 2023 at 11:18 AM Michael McCandless < luc...@mikemccandless.com> wrote: > I didn't realize the community had decided squashing (rewriting history) > was our standard. > > > Comparing histories between branches with git-bisect to find bugs is > just one example. > > But if the bug was introduced in one of the N local commits the developer > had done, wouldn't that be helpful? You could see that one commit instead > of all N squashed, and get better context on how/why the bug was introduced? > > I would prefer history-preserving commits. It can reveal/preserve > important information -- like we tried one approach, and discovered some > issue, tweaked it to a better approach. This can be useful in the future > if someone is working on that part of the code and is trying to understand > why it was done a certain way. It preserves the natural and healthy > iterations we all experience when working closely together. Why discard > such possibly helpful history? > > Also, one can always wear hazy glasses in the future to "summarize" the > full history down to a view that's more palatable to them personally, if > you don't like seeing merge commit branching. But we cannot do the > reverse. Discarding the actual development history is a one-way door. > > http://blog.mikemccandless.com > > > On Sat, Nov 4, 2023 at 11:03 AM Gus Heck wrote: > >> Also, since (as noted) this is a previously decided issue, not sure why >> this is a list email instead of a simple direct query to Robert seeking to >> understand the specific case? No need to make a public discussion unless >> it's a long term pattern, actually breaking something, or we want to change >> something? >> >> On Sat, Nov 4, 2023 at 9:37 AM Benjamin Trent >> wrote: >> >>> TL;DR, forcing non-committers to squash things is a good idea. Enforcing >>> through some measure for committers is a bad idea. >>> >>> Since this thread is now in Robert's spam, I am guessing it won't have >>> any impact :). I do not think Robert is actively trying hurt the project in >>> any way. It seems to me that he doesn't think a clean git history is worth >>> the effort. >>> >>> Having a clean git history makes things easier for everyone. Comparing >>> histories between branches with git-bisect to find bugs is just one >>> example. Another is simply reading commits to see when >>> features/bug fixes/etc. were added. >>> >>> I do NOT think we should add procedures or branch protections to >>> actively enforce this. >>> >>> Small personal sacrifices (like dealing with commit conflicts) are >>> necessary for a community. Being part of a community is about buying into >>> what the community is about and working towards a common goal. Many times >>> we do things we don't agree with, or make things slightly more difficult >>> for us, for the community as a whole. This thing being OSS shows that we >>> all buy into its importance and are willing to put work into the project. >>> >>> Having a cultural default of "make things nice for others" is good. >>> Enforcing this ideology on others is antithesis to its definition. >>> >>> >>> >>> On Sat, Nov 4, 2023 at 9:02 AM Robert Muir wrote: >>> This isn't a community issue, it is me avoiding useless unnecessary merge conflicts. Word "community" is invoked here to try to make it out, like you can hold a vote about what git commands i should type on my computer? You know that isn't gonna work. have some humility. thread moved to spam. On Sat, Nov 4, 2023 at 8:36 AM Mike Drob wrote: > > We all agree on using Java though, and using a specific version, and even the style output from gradle tidy. Is that nanny state or community consensus? > > On Sat, Nov 4, 2023 at 7:29 AM Robert Muir wrote: >> >> example of a nanny state IMO, trying to dictate what git commands to >> use, or what editor to use. Maybe this works for you in your corporate >> hellholes, but I think some folks have a bit of a power issue, are >> accustomed to dictacting this stuff to their employees and so on, but >> this is open-source. I
Re: Squash vs merge of PRs
I didn't realize the community had decided squashing (rewriting history) was our standard. > Comparing histories between branches with git-bisect to find bugs is just one example. But if the bug was introduced in one of the N local commits the developer had done, wouldn't that be helpful? You could see that one commit instead of all N squashed, and get better context on how/why the bug was introduced? I would prefer history-preserving commits. It can reveal/preserve important information -- like we tried one approach, and discovered some issue, tweaked it to a better approach. This can be useful in the future if someone is working on that part of the code and is trying to understand why it was done a certain way. It preserves the natural and healthy iterations we all experience when working closely together. Why discard such possibly helpful history? Also, one can always wear hazy glasses in the future to "summarize" the full history down to a view that's more palatable to them personally, if you don't like seeing merge commit branching. But we cannot do the reverse. Discarding the actual development history is a one-way door. http://blog.mikemccandless.com On Sat, Nov 4, 2023 at 11:03 AM Gus Heck wrote: > Also, since (as noted) this is a previously decided issue, not sure why > this is a list email instead of a simple direct query to Robert seeking to > understand the specific case? No need to make a public discussion unless > it's a long term pattern, actually breaking something, or we want to change > something? > > On Sat, Nov 4, 2023 at 9:37 AM Benjamin Trent > wrote: > >> TL;DR, forcing non-committers to squash things is a good idea. Enforcing >> through some measure for committers is a bad idea. >> >> Since this thread is now in Robert's spam, I am guessing it won't have >> any impact :). I do not think Robert is actively trying hurt the project in >> any way. It seems to me that he doesn't think a clean git history is worth >> the effort. >> >> Having a clean git history makes things easier for everyone. Comparing >> histories between branches with git-bisect to find bugs is just one >> example. Another is simply reading commits to see when >> features/bug fixes/etc. were added. >> >> I do NOT think we should add procedures or branch protections to actively >> enforce this. >> >> Small personal sacrifices (like dealing with commit conflicts) are >> necessary for a community. Being part of a community is about buying into >> what the community is about and working towards a common goal. Many times >> we do things we don't agree with, or make things slightly more difficult >> for us, for the community as a whole. This thing being OSS shows that we >> all buy into its importance and are willing to put work into the project. >> >> Having a cultural default of "make things nice for others" is good. >> Enforcing this ideology on others is antithesis to its definition. >> >> >> >> On Sat, Nov 4, 2023 at 9:02 AM Robert Muir wrote: >> >>> This isn't a community issue, it is me avoiding useless unnecessary >>> merge conflicts. Word "community" is invoked here to try to make it >>> out, like you can hold a vote about what git commands i should type on >>> my computer? You know that isn't gonna work. have some humility. >>> >>> thread moved to spam. >>> >>> On Sat, Nov 4, 2023 at 8:36 AM Mike Drob wrote: >>> > >>> > We all agree on using Java though, and using a specific version, and >>> even the style output from gradle tidy. Is that nanny state or community >>> consensus? >>> > >>> > On Sat, Nov 4, 2023 at 7:29 AM Robert Muir wrote: >>> >> >>> >> example of a nanny state IMO, trying to dictate what git commands to >>> >> use, or what editor to use. Maybe this works for you in your corporate >>> >> hellholes, but I think some folks have a bit of a power issue, are >>> >> accustomed to dictacting this stuff to their employees and so on, but >>> >> this is open-source. I don't report to you, i dont use the editor you >>> >> tell me, or the git commands you tell me. >>> >> >>> >> On Sat, Nov 4, 2023 at 8:21 AM Uwe Schindler wrote: >>> >> > >>> >> > Hi, >>> >> > >>> >> > I just wanted to give your attention to the following discussion: >>> >> > https://github.com/apache/lucene/pull/12737#issuecomment-1793426911 >>> >> > >>> >> > From my knowledge the Lucene (and Solr) community decided a while >>> back >>> >> > to disable merging and only allow squashig of PRs. Robert always did >>> >> > this, but because of a one-time problem with two branches he was >>> working >>> >> > on in parallel, he suddenly changed his mind and did merges on his >>> own, >>> >> > not sqashing the branch and pushing to ASF Git. >>> >> > >>> >> > I am also not a fan of removing all history, but especially for >>> heavy >>> >> > committing branches like the given PR, I think we should invite our >>> >> > committers to also adhere to community standards everyone else >>> >> > practices. I would agree with merging those
Re: Squash vs merge of PRs
Also, since (as noted) this is a previously decided issue, not sure why this is a list email instead of a simple direct query to Robert seeking to understand the specific case? No need to make a public discussion unless it's a long term pattern, actually breaking something, or we want to change something? On Sat, Nov 4, 2023 at 9:37 AM Benjamin Trent wrote: > TL;DR, forcing non-committers to squash things is a good idea. Enforcing > through some measure for committers is a bad idea. > > Since this thread is now in Robert's spam, I am guessing it won't have any > impact :). I do not think Robert is actively trying hurt the project in any > way. It seems to me that he doesn't think a clean git history is worth the > effort. > > Having a clean git history makes things easier for everyone. Comparing > histories between branches with git-bisect to find bugs is just one > example. Another is simply reading commits to see when > features/bug fixes/etc. were added. > > I do NOT think we should add procedures or branch protections to actively > enforce this. > > Small personal sacrifices (like dealing with commit conflicts) are > necessary for a community. Being part of a community is about buying into > what the community is about and working towards a common goal. Many times > we do things we don't agree with, or make things slightly more difficult > for us, for the community as a whole. This thing being OSS shows that we > all buy into its importance and are willing to put work into the project. > > Having a cultural default of "make things nice for others" is good. > Enforcing this ideology on others is antithesis to its definition. > > > > On Sat, Nov 4, 2023 at 9:02 AM Robert Muir wrote: > >> This isn't a community issue, it is me avoiding useless unnecessary >> merge conflicts. Word "community" is invoked here to try to make it >> out, like you can hold a vote about what git commands i should type on >> my computer? You know that isn't gonna work. have some humility. >> >> thread moved to spam. >> >> On Sat, Nov 4, 2023 at 8:36 AM Mike Drob wrote: >> > >> > We all agree on using Java though, and using a specific version, and >> even the style output from gradle tidy. Is that nanny state or community >> consensus? >> > >> > On Sat, Nov 4, 2023 at 7:29 AM Robert Muir wrote: >> >> >> >> example of a nanny state IMO, trying to dictate what git commands to >> >> use, or what editor to use. Maybe this works for you in your corporate >> >> hellholes, but I think some folks have a bit of a power issue, are >> >> accustomed to dictacting this stuff to their employees and so on, but >> >> this is open-source. I don't report to you, i dont use the editor you >> >> tell me, or the git commands you tell me. >> >> >> >> On Sat, Nov 4, 2023 at 8:21 AM Uwe Schindler wrote: >> >> > >> >> > Hi, >> >> > >> >> > I just wanted to give your attention to the following discussion: >> >> > https://github.com/apache/lucene/pull/12737#issuecomment-1793426911 >> >> > >> >> > From my knowledge the Lucene (and Solr) community decided a while >> back >> >> > to disable merging and only allow squashig of PRs. Robert always did >> >> > this, but because of a one-time problem with two branches he was >> working >> >> > on in parallel, he suddenly changed his mind and did merges on his >> own, >> >> > not sqashing the branch and pushing to ASF Git. >> >> > >> >> > I am also not a fan of removing all history, but especially for heavy >> >> > committing branches like the given PR, I think we should invite our >> >> > committers to also adhere to community standards everyone else >> >> > practices. I would agree with merging those branches if all commit >> >> > messages in the branch would be well-formed with issue ID or PR >> number, >> >> > but in the above case you get a history of random commits which is no >> >> > longer linear and not easy readable. >> >> > >> >> > What do others think? >> >> > >> >> > Uwe >> >> > >> >> > -- >> >> > Uwe Schindler >> >> > Achterdiek 19, D-28357 Bremen >> >> > https://www.thetaphi.de >> >> > eMail: u...@thetaphi.de >> >> > >> >> > >> >> > - >> >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > >> >> >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
Re: Squash vs merge of PRs
TL;DR, forcing non-committers to squash things is a good idea. Enforcing through some measure for committers is a bad idea. Since this thread is now in Robert's spam, I am guessing it won't have any impact :). I do not think Robert is actively trying hurt the project in any way. It seems to me that he doesn't think a clean git history is worth the effort. Having a clean git history makes things easier for everyone. Comparing histories between branches with git-bisect to find bugs is just one example. Another is simply reading commits to see when features/bug fixes/etc. were added. I do NOT think we should add procedures or branch protections to actively enforce this. Small personal sacrifices (like dealing with commit conflicts) are necessary for a community. Being part of a community is about buying into what the community is about and working towards a common goal. Many times we do things we don't agree with, or make things slightly more difficult for us, for the community as a whole. This thing being OSS shows that we all buy into its importance and are willing to put work into the project. Having a cultural default of "make things nice for others" is good. Enforcing this ideology on others is antithesis to its definition. On Sat, Nov 4, 2023 at 9:02 AM Robert Muir wrote: > This isn't a community issue, it is me avoiding useless unnecessary > merge conflicts. Word "community" is invoked here to try to make it > out, like you can hold a vote about what git commands i should type on > my computer? You know that isn't gonna work. have some humility. > > thread moved to spam. > > On Sat, Nov 4, 2023 at 8:36 AM Mike Drob wrote: > > > > We all agree on using Java though, and using a specific version, and > even the style output from gradle tidy. Is that nanny state or community > consensus? > > > > On Sat, Nov 4, 2023 at 7:29 AM Robert Muir wrote: > >> > >> example of a nanny state IMO, trying to dictate what git commands to > >> use, or what editor to use. Maybe this works for you in your corporate > >> hellholes, but I think some folks have a bit of a power issue, are > >> accustomed to dictacting this stuff to their employees and so on, but > >> this is open-source. I don't report to you, i dont use the editor you > >> tell me, or the git commands you tell me. > >> > >> On Sat, Nov 4, 2023 at 8:21 AM Uwe Schindler wrote: > >> > > >> > Hi, > >> > > >> > I just wanted to give your attention to the following discussion: > >> > https://github.com/apache/lucene/pull/12737#issuecomment-1793426911 > >> > > >> > From my knowledge the Lucene (and Solr) community decided a while > back > >> > to disable merging and only allow squashig of PRs. Robert always did > >> > this, but because of a one-time problem with two branches he was > working > >> > on in parallel, he suddenly changed his mind and did merges on his > own, > >> > not sqashing the branch and pushing to ASF Git. > >> > > >> > I am also not a fan of removing all history, but especially for heavy > >> > committing branches like the given PR, I think we should invite our > >> > committers to also adhere to community standards everyone else > >> > practices. I would agree with merging those branches if all commit > >> > messages in the branch would be well-formed with issue ID or PR > number, > >> > but in the above case you get a history of random commits which is no > >> > longer linear and not easy readable. > >> > > >> > What do others think? > >> > > >> > Uwe > >> > > >> > -- > >> > Uwe Schindler > >> > Achterdiek 19, D-28357 Bremen > >> > https://www.thetaphi.de > >> > eMail: u...@thetaphi.de > >> > > >> > > >> > - > >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> > For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Squash vs merge of PRs
This isn't a community issue, it is me avoiding useless unnecessary merge conflicts. Word "community" is invoked here to try to make it out, like you can hold a vote about what git commands i should type on my computer? You know that isn't gonna work. have some humility. thread moved to spam. On Sat, Nov 4, 2023 at 8:36 AM Mike Drob wrote: > > We all agree on using Java though, and using a specific version, and even the > style output from gradle tidy. Is that nanny state or community consensus? > > On Sat, Nov 4, 2023 at 7:29 AM Robert Muir wrote: >> >> example of a nanny state IMO, trying to dictate what git commands to >> use, or what editor to use. Maybe this works for you in your corporate >> hellholes, but I think some folks have a bit of a power issue, are >> accustomed to dictacting this stuff to their employees and so on, but >> this is open-source. I don't report to you, i dont use the editor you >> tell me, or the git commands you tell me. >> >> On Sat, Nov 4, 2023 at 8:21 AM Uwe Schindler wrote: >> > >> > Hi, >> > >> > I just wanted to give your attention to the following discussion: >> > https://github.com/apache/lucene/pull/12737#issuecomment-1793426911 >> > >> > From my knowledge the Lucene (and Solr) community decided a while back >> > to disable merging and only allow squashig of PRs. Robert always did >> > this, but because of a one-time problem with two branches he was working >> > on in parallel, he suddenly changed his mind and did merges on his own, >> > not sqashing the branch and pushing to ASF Git. >> > >> > I am also not a fan of removing all history, but especially for heavy >> > committing branches like the given PR, I think we should invite our >> > committers to also adhere to community standards everyone else >> > practices. I would agree with merging those branches if all commit >> > messages in the branch would be well-formed with issue ID or PR number, >> > but in the above case you get a history of random commits which is no >> > longer linear and not easy readable. >> > >> > What do others think? >> > >> > Uwe >> > >> > -- >> > Uwe Schindler >> > Achterdiek 19, D-28357 Bremen >> > https://www.thetaphi.de >> > eMail: u...@thetaphi.de >> > >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Squash vs merge of PRs
We all agree on using Java though, and using a specific version, and even the style output from gradle tidy. Is that nanny state or community consensus? On Sat, Nov 4, 2023 at 7:29 AM Robert Muir wrote: > example of a nanny state IMO, trying to dictate what git commands to > use, or what editor to use. Maybe this works for you in your corporate > hellholes, but I think some folks have a bit of a power issue, are > accustomed to dictacting this stuff to their employees and so on, but > this is open-source. I don't report to you, i dont use the editor you > tell me, or the git commands you tell me. > > On Sat, Nov 4, 2023 at 8:21 AM Uwe Schindler wrote: > > > > Hi, > > > > I just wanted to give your attention to the following discussion: > > https://github.com/apache/lucene/pull/12737#issuecomment-1793426911 > > > > From my knowledge the Lucene (and Solr) community decided a while back > > to disable merging and only allow squashig of PRs. Robert always did > > this, but because of a one-time problem with two branches he was working > > on in parallel, he suddenly changed his mind and did merges on his own, > > not sqashing the branch and pushing to ASF Git. > > > > I am also not a fan of removing all history, but especially for heavy > > committing branches like the given PR, I think we should invite our > > committers to also adhere to community standards everyone else > > practices. I would agree with merging those branches if all commit > > messages in the branch would be well-formed with issue ID or PR number, > > but in the above case you get a history of random commits which is no > > longer linear and not easy readable. > > > > What do others think? > > > > Uwe > > > > -- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Squash vs merge of PRs
example of a nanny state IMO, trying to dictate what git commands to use, or what editor to use. Maybe this works for you in your corporate hellholes, but I think some folks have a bit of a power issue, are accustomed to dictacting this stuff to their employees and so on, but this is open-source. I don't report to you, i dont use the editor you tell me, or the git commands you tell me. On Sat, Nov 4, 2023 at 8:21 AM Uwe Schindler wrote: > > Hi, > > I just wanted to give your attention to the following discussion: > https://github.com/apache/lucene/pull/12737#issuecomment-1793426911 > > From my knowledge the Lucene (and Solr) community decided a while back > to disable merging and only allow squashig of PRs. Robert always did > this, but because of a one-time problem with two branches he was working > on in parallel, he suddenly changed his mind and did merges on his own, > not sqashing the branch and pushing to ASF Git. > > I am also not a fan of removing all history, but especially for heavy > committing branches like the given PR, I think we should invite our > committers to also adhere to community standards everyone else > practices. I would agree with merging those branches if all commit > messages in the branch would be well-formed with issue ID or PR number, > but in the above case you get a history of random commits which is no > longer linear and not easy readable. > > What do others think? > > Uwe > > -- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: u...@thetaphi.de > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Squash vs merge of PRs
Hi, I just wanted to give your attention to the following discussion: https://github.com/apache/lucene/pull/12737#issuecomment-1793426911 From my knowledge the Lucene (and Solr) community decided a while back to disable merging and only allow squashig of PRs. Robert always did this, but because of a one-time problem with two branches he was working on in parallel, he suddenly changed his mind and did merges on his own, not sqashing the branch and pushing to ASF Git. I am also not a fan of removing all history, but especially for heavy committing branches like the given PR, I think we should invite our committers to also adhere to community standards everyone else practices. I would agree with merging those branches if all commit messages in the branch would be well-formed with issue ID or PR number, but in the above case you get a history of random commits which is no longer linear and not easy readable. What do others think? Uwe -- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
