+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 > > <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 > <http://www.linkedin.com/in/davidwsmiley>
