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 <msokolov@gmail.com>
> 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
> <lucene@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 <gus.heck@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.trent@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
> <rcmuir@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
> <mdrob@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
> <rcmuir@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
> <uwe@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: uwe@thetaphi.de
> >> >
> >> >
> >> >
> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail:
> dev-unsubscribe@lucene.apache.org
> >> > For additional commands, e-mail:
> dev-help@lucene.apache.org
> >> >
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail:
> dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail:
> dev-help@lucene.apache.org
>
>
>
> --
> http://www.needhamsoftware.com (work)
> https://a.co/d/b2sZLD9 (my fantasy fiction book)
>
>
>
> --
> http://www.needhamsoftware.com (work)
> https://a.co/d/b2sZLD9 (my fantasy fiction book)
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de eMail:uwe@thetaphi.de