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