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 > >
