You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by David Smiley <ds...@apache.org> on 2020/10/19 21:17:43 UTC
Please set: git config --global pull.rebase true
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
Posted by Yonik Seeley <ys...@gmail.com>.
On Mon, Oct 19, 2020 at 5:17 PM David Smiley <ds...@apache.org> 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
RE: Please set: git config --global pull.rebase true
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
From: Ishan Chattopadhyaya <ic...@gmail.com>
Sent: Tuesday, October 20, 2020 11:13 AM
To: Lucene Dev <de...@lucene.apache.org>
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, <dawid.weiss@gmail.com <ma...@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 <ab@getopt.org <ma...@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 <dsmiley@apache.org <ma...@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
Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
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, <da...@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 <ab...@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 <ds...@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
Posted by Michael Sokolov <ms...@gmail.com>.
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 <ab...@getopt.org> wrote:
>
>
> On 20 Oct 2020, at 09:33, Dawid Weiss <da...@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.
>
>
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Please set: git config --global pull.rebase true
Posted by Dawid Weiss <da...@gmail.com>.
> 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
Posted by Andrzej Białecki <ab...@getopt.org>.
> On 20 Oct 2020, at 09:33, Dawid Weiss <da...@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.
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
Posted by Dawid Weiss <da...@gmail.com>.
> [...] 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 <ab...@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 <ds...@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
Posted by Andrzej Białecki <ab...@getopt.org>.
+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 <ds...@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>
Re: Please set: git config --global pull.rebase true
Posted by David Smiley <ds...@apache.org>.
>
> 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 <uw...@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: uwe@thetaphi.de
>
>
>
> *From:* Robert Muir <rc...@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 <ds...@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
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
From: Robert Muir <rc...@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 <dsmiley@apache.org <ma...@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
Posted by Robert Muir <rc...@gmail.com>.
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 <ds...@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
>