> [...] 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 > > >
