Master and hopefully also 8.x should be disabled.
You can check mailing list, we discussed about that when we switched to GIT. Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen https://www.thetaphi.de eMail: u...@thetaphi.de From: Ishan Chattopadhyaya <ichattopadhy...@gmail.com> Sent: Tuesday, October 20, 2020 11:13 AM To: Lucene Dev <dev@lucene.apache.org> Subject: Re: Please set: git config --global pull.rebase true I don't think it is disabled for Lucene-solr, ab. I can do forced pushes on jira branches, but not sure about branch-8x or master. +100 agree with avoiding forced pushes. I think I was on your team in a previous job once when forced pushes caused us so much trouble. I fully support disabling it outright for the repo (if not done already). On Tue, 20 Oct, 2020, 1:04 pm Dawid Weiss, <dawid.we...@gmail.com <mailto:dawid.we...@gmail.com> > wrote: > [...] in a public repo and may lead to bizarre conflicts and lost local work > Just to clarify - it's hard to lose a local commit, even if somebody changes the remote reference. I agree it is almost equally hard to find it once it's dangling without any named branch or tag (extra knowledge of git is required). Most of the time you can recover it though - looking at git reflog is the first step to try. It's also good to understand what the switch David mentioned really does - for example, I rarely use pull at all these days (I fetch remotes and merge local branches against remote ones directly). The step-by-step git primer at [1] hasn't aged that much; maybe it'll be of some help. D. [1] https://github.com/dweiss/lucene-git-guides On Tue, Oct 20, 2020 at 9:25 AM Andrzej Białecki <a...@getopt.org <mailto:a...@getopt.org> > wrote: +100 IMHO the three greatest evils of git workflow, to be avoided at all cost, are: * pulling without rebasing, as you explained (and then pushing the resulting spaghetti to the repo). Who cares that you made 10 interim local commits and 10 reverts, and you merged from trunk a dozen times on the way before finally pushing your changes? Nobody is interested in this and in the resulting eyesore. * ditto, merging feature branches with the main branches without squashing (and then pushing the resulting spaghetti to the repo) * and the greatest of all evils, a forced push, which should NEVER be used on a public repo. IIRC it’s disabled on lucene-solr repo? I hope it still is, and it needs to be disabled once the Solr repo is separated. Forced push forcibly rewrites the history in a public repo and may lead to bizarre conflicts and lost local work (not to mention the revisionist aspects). — Andrzej Białecki On 19 Oct 2020, at 23:17, David Smiley <dsmi...@apache.org <mailto:dsmi...@apache.org> > wrote: I ask you all to do the following: git config --global pull.rebase true Perhaps you have already set it as such (this retrieves the current setting, possibly a default): git config pull.rebase -> true *What*: As the setting implies, this has to do with what happens on a "pull", but in practice it shows up in a typical workflow on a "push" because some "pushes" need to "pull". When pushes do a pull, it's because the remote branch (e.g. master or branch_8x) has advanced beyond the point that you had committed from. Git will either (A) generate a merge commit between the latest head and your commit (the default behavior) generating a bifurcation in the history, or (b) it will rebase your commit(s) on top of the new head (what I propose) thus producing a linear history. In either case, there may be a conflict which you'll have to resolve. *Why?*: To make our history easier to understand as seen via "git log" and in our IDEs and online. I don't know about you all, but I find those visual branch bifurcations to be a distracting annoyance that is more obfuscating than linear history. I don't think that merge commits are altogether bad, I'd just prefer that they happen in exceptional circumstances instead of common ones. *Why not?:* In full disclosure, I'm aware this is one of those debates like tabs vs spaces. Some will argue that the merge commit is a better reflection of the reality of what happened. While I agree, it has an obfuscation cost on everyone looking at the history. I think it _sometimes_ makes sense for a merge commit, like maybe if the branch was a long lived big feature. The setting I propose does not prevent someone from deliberately choosing a merge commit when they consciously want one, it's aimed at the common scenario during a push. If I can get broad agreement here, I can update https://cwiki.apache.org/confluence/display/LUCENE/Commit+Process+Guidelines#CommitProcessGuidelines-LinearHistoryinGit to recommend the setting above and remove the [PENDING DISCUSSION]. Thankfully, this appears to occur only rarely. It happened today on branch_8x (I'm looking at you Eric Pugh :-) and a worse one there September 29th by Noble. I say "worse" because the branch bifurcation was 2 weeks long for that one. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
