> > So in short: Prefer Rebase, but whenever it gets complicated: STAY WITH > MERGES!!! >
That's fine advice! I think my proposal (this particular git setting) is supportive of that since in the event of a merge conflict, at that point you can choose what to do -- resolve simple conflicts and continue with rebase, or abort and merge in the upstream branch, (after fixing the conflicts). I propose the following wording in the guideline document: "Git: Rebase vs Merge" Please set: git config --global pull.rebase true Consequently, pushing your changes will result in your changes being moved > (rebased) on top of the latest changes to the branch you push to instead of > a merge commit. This keeps the history linear which is nice for simplicity > sake in the vast majority of cases. *However*, if there are non-trivial > conflicts to resolve, then abort and merge into the upstream branch > instead, which generates a merge commit. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Oct 21, 2020 at 4:56 AM Uwe Schindler <u...@thetaphi.de> wrote: > Hi, > > > > I fully agree here and yes we should have stayed with Subversion then. The > merge commits are IMHO the best thing of Git to track if complicated merges > were going on (one thing that never worked with Git). > > > > Not that you misunderstand me: I am fine with rebasing (when it works and > is easy to handle) to keep history clean for simple cases, but if it does > not work ASAP and I get a conflict during rebasing, I will stop that > process and use the normal merge to fix the issues. In that case I will > always keep all the history, so anybody else can see and verify if hard > work was done to get 2 branches / commits together. This is very important > to sort later out when errors during manual merging occurs. > > > > So in short: Prefer Rebase, but whenever it gets complicated: STAY WITH > MERGES!!! > > > > Uwe > > > > ----- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > *From:* Robert Muir <rcm...@gmail.com> > *Sent:* Tuesday, October 20, 2020 3:24 PM > *To:* dev@lucene.apache.org > *Subject:* Re: Please set: git config --global pull.rebase true > > > > if everyone wants a centralized linear history so badly, why not just go > back to using subversion? > > > > On Mon, Oct 19, 2020 at 5:18 PM 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 > >
