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