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 <msoko...@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
<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 <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)
--
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:u...@thetaphi.de
