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 <gus.h...@gmail.com> 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 <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) >
