Re: Please set: git config --global pull.rebase true

[David Smiley]

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

RE: Please set: git config --global pull.rebase true

[Uwe Schindler]

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

Re: Please set: git config --global pull.rebase true

[Robert Muir]

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

Re: Please set: git config --global pull.rebase true

[Dawid Weiss]

> Yes, that’s technically true … and now multiply this exercise by the
> number of devs across the globe, each with some local changes :)
>

Technically, I did say it's going to be hard - just not impossible. ;)


> I went through this process once on an active project with a team of dozen
> people in different timezones, and it wasn’t pleasant.
>

I don't have this experience but knowing how it works I can fully
appreciate the effort and pain.

Dawid

Re: Please set: git config --global pull.rebase true

[Michael Sokolov]

My experience has been "git pull" -- starts a merge -- slowly back
away, "git reset --hard", and the "git pull --rebase". If this setting
would help me avoid that dance, I'm all for it

On Tue, Oct 20, 2020 at 6:55 AM Andrzej Białecki  wrote:
>
>
> On 20 Oct 2020, at 09:33, Dawid Weiss  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.
>
>
>
> Yes, that’s technically true … and now multiply this exercise by the number 
> of devs across the globe, each with some local changes :) I went through this 
> process once on an active project with a team of dozen people in different 
> timezones, and it wasn’t pleasant.
>
> —
>
> Andrzej Białecki
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Please set: git config --global pull.rebase true

[Andrzej Białecki]

> On 20 Oct 2020, at 09:33, Dawid Weiss  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.


Yes, that’s technically true … and now multiply this exercise by the number of 
devs across the globe, each with some local changes :) I went through this 
process once on an active project with a team of dozen people in different 
timezones, and it wasn’t pleasant.

—

Andrzej Białecki

RE: Please set: git config --global pull.rebase true

[Uwe Schindler]

Master and hopefully also 8.x should be disabled.

 

You can check mailing list, we discussed about that when we switched to GIT.

 

Uwe

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Ishan Chattopadhyaya  
Sent: Tuesday, October 20, 2020 11:13 AM
To: Lucene Dev 
Subject: Re: Please set: git config --global pull.rebase true

 

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, mailto: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 mailto: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 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 

Re: Please set: git config --global pull.rebase true

[Ishan Chattopadhyaya]

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

Re: Please set: git config --global pull.rebase true

[Dawid Weiss]

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

Re: Please set: git config --global pull.rebase true

[Andrzej Białecki]

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

Re: Please set: git config --global pull.rebase true

[Yonik Seeley]

On Mon, Oct 19, 2020 at 5:17 PM David Smiley  wrote:

> I ask you all to do the following:
>
> git config --global pull.rebase true
>
>
+1
It's what you want 99% of the time.

-Yonik