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 <ben.w.tr...@gmail.com> 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 <rcm...@gmail.com> 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 <md...@mdrob.com> 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 <rcm...@gmail.com> 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 <u...@thetaphi.de> 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)
