You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2016/03/26 20:00:55 UTC
[Math] "rebase" vs "merge" (Was: RNG refactoring)
On Fri, 25 Mar 2016 11:56:26 -0400, Evan Ward wrote:
> I'm not sure if this is the problem, but a good rule of thumb is that
> if
> you have pushed a commit
Did I?
What I wanted is
* publish code ("feature-MATH-1335")
* publish code ("feature-MATH-1158") that requires the new code
present in "feature-MATH-1335"
So I "rebase"d "feature-MATH-1158" on "feature-MATH-1335" in order
to incorporate everything from there. [What "git" tells during this
operation looks like the right thing to do.]
By the way, I did the same with your change: I "rebase"d all my local
branches on "develop" after your merged your change to that branch.
What is the difference with "merge" and if "merge" should have been
used, then when does one use "rebase"?
Maybe I did the right thing; and it's just normal that there is an
email flood in such cases...
Thanks,
Gilles
> you should merge it instead of rebasing it. It
> looks to me like 6ddf476 and ce8c82f are the same, so I think when
> you
> ran rebase it put it on top of the bug fix I pushed up recently,
> duplicating the commit.
>
> Best Regards,
> Evan
>
> On 03/25/2016 11:34 AM, Gilles wrote:
>> Hi.
>>
>> Last week, and just now, I've pushed local branches that handle
>> the following issues (and others, either related, or set to
>> "Won't fix [in current code]" in JIRA[1]):
>>
>> https://issues.apache.org/jira/browse/MATH-1335
>> https://issues.apache.org/jira/browse/MATH-1336
>> https://issues.apache.org/jira/browse/MATH-1337
>> https://issues.apache.org/jira/browse/MATH-1339
>> https://issues.apache.org/jira/browse/MATH-1158
>> https://issues.apache.org/jira/browse/MATH-1338
>>
>> [I've just seen that for branch "feature-MATH-1158" which is
>> "git rebase"d on "feature-MATH-1335", the push is recreating
>> all the MATH-1335 commits (as guessed from the flood of emails).
>> Something I was not expecting: sorry I misunderstood how this
>> is supposed to work...]
>>
>>
>> Regards,
>> Gilles
>>
>> [1] See the "links" in the relevant JIRA reports.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] "rebase" vs "merge" (Was: RNG refactoring)
Posted by Matt Sicker <bo...@gmail.com>.
I once had to do a git filter-branch to remove an emoji from a commit
message that broke our CI server because it was using MySQL. That was fun,
plus I had to get all my co-workers to do a git pull --rebase. So yeah,
there are occasional uses for breaking everyone's history.
On 27 March 2016 at 19:49, Al Chou <ho...@yahoo.com.invalid> wrote:
> Agreed, changing the commit ancestry history of a branch that other people
> have already (even merely potentially) fetched and checked out locally is
> generally frowned upon. Interesting to hear that anyone ever has gotten
> consensus to do so via "pull --rebase"! On rare occasions at my job we
> have needed to "push --force" a publicly shared branch to clear up a
> problem, and we do get consensus before doing so, but no one enjoys those
> situations.
> Al
>
> On Sunday, March 27, 2016 5:44 PM, Matt Sicker <bo...@gmail.com>
> wrote:
>
>
> In general, don't use rebase on branches that other people are also using
> without first making sure everyone is willing to also rebase their own
> local copies. To do that, they can run "git pull --rebase" to update when
> you've force-pushed a rebased branch. This is generally looked down upon,
> but is sometimes necessary.
>
> On 26 March 2016 at 17:33, <Ho...@yahoo.com.invalid> wrote:
>
> > Unlike a regular merge, rebase applies a branch's commits' changes onto
> > the specified commit (which is typically identified by specifying a
> branch
> > name), in the same order as they appear in the branch that is being
> > rebased. The name of the command says that you are redefining the "base",
> > in other words, the starting point, of the branch. Depending on the
> changes
> > made by those commits, you may see what appears to be the same
> > commit/change applied more than once. See http://ProGit.org/book for
> > great explanations of this and other Git features.
> >
> > Al
> >
> > On Mar 26, 2016, 12:01 -0700, Gilles<gi...@harfang.homelinux.org>,
> wrote:
> > > On Fri, 25 Mar 2016 11:56:26 -0400, Evan Ward wrote:
> > > > I'm not sure if this is the problem, but a good rule of thumb is that
> > > > if
> > > > you have pushed a commit
> > >
> > > Did I?
> > >
> > > What I wanted is
> > > * publish code ("feature-MATH-1335")
> > > * publish code ("feature-MATH-1158") that requires the new code
> > > present in "feature-MATH-1335"
> > >
> > > So I "rebase"d "feature-MATH-1158" on "feature-MATH-1335" in order
> > > to incorporate everything from there. [What "git" tells during this
> > > operation looks like the right thing to do.]
> > >
> > > By the way, I did the same with your change: I "rebase"d all my local
> > > branches on "develop" after your merged your change to that branch.
> > >
> > > What is the difference with "merge" and if "merge" should have been
> > > used, then when does one use "rebase"?
> > >
> > > Maybe I did the right thing; and it's just normal that there is an
> > > email flood in such cases...
> > >
> > > Thanks,
> > > Gilles
> > >
> > > > you should merge it instead of rebasing it. It
> > > > looks to me like 6ddf476 and ce8c82f are the same, so I think when
> > > > you
> > > > ran rebase it put it on top of the bug fix I pushed up recently,
> > > > duplicating the commit.
> > > >
> > > > Best Regards,
> > > > Evan
> > > >
> > > > On 03/25/2016 11:34 AM, Gilles wrote:
> > > > > Hi.
> > > > >
> > > > > Last week, and just now, I've pushed local branches that handle
> > > > > the following issues (and others, either related, or set to
> > > > > "Won't fix [in current code]" in JIRA[1]):
> > > > >
> > > > > https://issues.apache.org/jira/browse/MATH-1335
> > > > > https://issues.apache.org/jira/browse/MATH-1336
> > > > > https://issues.apache.org/jira/browse/MATH-1337
> > > > > https://issues.apache.org/jira/browse/MATH-1339
> > > > > https://issues.apache.org/jira/browse/MATH-1158
> > > > > https://issues.apache.org/jira/browse/MATH-1338
> > > > >
> > > > > [I've just seen that for branch "feature-MATH-1158" which is
> > > > > "git rebase"d on "feature-MATH-1335", the push is recreating
> > > > > all the MATH-1335 commits (as guessed from the flood of emails).
> > > > > Something I was not expecting: sorry I misunderstood how this
> > > > > is supposed to work...]
> > > > >
> > > > >
> > > > > Regards,
> > > > > Gilles
> > > > >
> > > > > [1] See the "links" in the relevant JIRA reports.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [Math] "rebase" vs "merge" (Was: RNG refactoring)
Posted by Al Chou <ho...@yahoo.com.INVALID>.
Agreed, changing the commit ancestry history of a branch that other people have already (even merely potentially) fetched and checked out locally is generally frowned upon. Interesting to hear that anyone ever has gotten consensus to do so via "pull --rebase"! On rare occasions at my job we have needed to "push --force" a publicly shared branch to clear up a problem, and we do get consensus before doing so, but no one enjoys those situations.
Al
On Sunday, March 27, 2016 5:44 PM, Matt Sicker <bo...@gmail.com> wrote:
In general, don't use rebase on branches that other people are also using
without first making sure everyone is willing to also rebase their own
local copies. To do that, they can run "git pull --rebase" to update when
you've force-pushed a rebased branch. This is generally looked down upon,
but is sometimes necessary.
On 26 March 2016 at 17:33, <Ho...@yahoo.com.invalid> wrote:
> Unlike a regular merge, rebase applies a branch's commits' changes onto
> the specified commit (which is typically identified by specifying a branch
> name), in the same order as they appear in the branch that is being
> rebased. The name of the command says that you are redefining the "base",
> in other words, the starting point, of the branch. Depending on the changes
> made by those commits, you may see what appears to be the same
> commit/change applied more than once. See http://ProGit.org/book for
> great explanations of this and other Git features.
>
> Al
>
> On Mar 26, 2016, 12:01 -0700, Gilles<gi...@harfang.homelinux.org>, wrote:
> > On Fri, 25 Mar 2016 11:56:26 -0400, Evan Ward wrote:
> > > I'm not sure if this is the problem, but a good rule of thumb is that
> > > if
> > > you have pushed a commit
> >
> > Did I?
> >
> > What I wanted is
> > * publish code ("feature-MATH-1335")
> > * publish code ("feature-MATH-1158") that requires the new code
> > present in "feature-MATH-1335"
> >
> > So I "rebase"d "feature-MATH-1158" on "feature-MATH-1335" in order
> > to incorporate everything from there. [What "git" tells during this
> > operation looks like the right thing to do.]
> >
> > By the way, I did the same with your change: I "rebase"d all my local
> > branches on "develop" after your merged your change to that branch.
> >
> > What is the difference with "merge" and if "merge" should have been
> > used, then when does one use "rebase"?
> >
> > Maybe I did the right thing; and it's just normal that there is an
> > email flood in such cases...
> >
> > Thanks,
> > Gilles
> >
> > > you should merge it instead of rebasing it. It
> > > looks to me like 6ddf476 and ce8c82f are the same, so I think when
> > > you
> > > ran rebase it put it on top of the bug fix I pushed up recently,
> > > duplicating the commit.
> > >
> > > Best Regards,
> > > Evan
> > >
> > > On 03/25/2016 11:34 AM, Gilles wrote:
> > > > Hi.
> > > >
> > > > Last week, and just now, I've pushed local branches that handle
> > > > the following issues (and others, either related, or set to
> > > > "Won't fix [in current code]" in JIRA[1]):
> > > >
> > > > https://issues.apache.org/jira/browse/MATH-1335
> > > > https://issues.apache.org/jira/browse/MATH-1336
> > > > https://issues.apache.org/jira/browse/MATH-1337
> > > > https://issues.apache.org/jira/browse/MATH-1339
> > > > https://issues.apache.org/jira/browse/MATH-1158
> > > > https://issues.apache.org/jira/browse/MATH-1338
> > > >
> > > > [I've just seen that for branch "feature-MATH-1158" which is
> > > > "git rebase"d on "feature-MATH-1335", the push is recreating
> > > > all the MATH-1335 commits (as guessed from the flood of emails).
> > > > Something I was not expecting: sorry I misunderstood how this
> > > > is supposed to work...]
> > > >
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > [1] See the "links" in the relevant JIRA reports.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [Math] "rebase" vs "merge" (Was: RNG refactoring)
Posted by Matt Sicker <bo...@gmail.com>.
In general, don't use rebase on branches that other people are also using
without first making sure everyone is willing to also rebase their own
local copies. To do that, they can run "git pull --rebase" to update when
you've force-pushed a rebased branch. This is generally looked down upon,
but is sometimes necessary.
On 26 March 2016 at 17:33, <Ho...@yahoo.com.invalid> wrote:
> Unlike a regular merge, rebase applies a branch's commits' changes onto
> the specified commit (which is typically identified by specifying a branch
> name), in the same order as they appear in the branch that is being
> rebased. The name of the command says that you are redefining the "base",
> in other words, the starting point, of the branch. Depending on the changes
> made by those commits, you may see what appears to be the same
> commit/change applied more than once. See http://ProGit.org/book for
> great explanations of this and other Git features.
>
> Al
>
> On Mar 26, 2016, 12:01 -0700, Gilles<gi...@harfang.homelinux.org>, wrote:
> > On Fri, 25 Mar 2016 11:56:26 -0400, Evan Ward wrote:
> > > I'm not sure if this is the problem, but a good rule of thumb is that
> > > if
> > > you have pushed a commit
> >
> > Did I?
> >
> > What I wanted is
> > * publish code ("feature-MATH-1335")
> > * publish code ("feature-MATH-1158") that requires the new code
> > present in "feature-MATH-1335"
> >
> > So I "rebase"d "feature-MATH-1158" on "feature-MATH-1335" in order
> > to incorporate everything from there. [What "git" tells during this
> > operation looks like the right thing to do.]
> >
> > By the way, I did the same with your change: I "rebase"d all my local
> > branches on "develop" after your merged your change to that branch.
> >
> > What is the difference with "merge" and if "merge" should have been
> > used, then when does one use "rebase"?
> >
> > Maybe I did the right thing; and it's just normal that there is an
> > email flood in such cases...
> >
> > Thanks,
> > Gilles
> >
> > > you should merge it instead of rebasing it. It
> > > looks to me like 6ddf476 and ce8c82f are the same, so I think when
> > > you
> > > ran rebase it put it on top of the bug fix I pushed up recently,
> > > duplicating the commit.
> > >
> > > Best Regards,
> > > Evan
> > >
> > > On 03/25/2016 11:34 AM, Gilles wrote:
> > > > Hi.
> > > >
> > > > Last week, and just now, I've pushed local branches that handle
> > > > the following issues (and others, either related, or set to
> > > > "Won't fix [in current code]" in JIRA[1]):
> > > >
> > > > https://issues.apache.org/jira/browse/MATH-1335
> > > > https://issues.apache.org/jira/browse/MATH-1336
> > > > https://issues.apache.org/jira/browse/MATH-1337
> > > > https://issues.apache.org/jira/browse/MATH-1339
> > > > https://issues.apache.org/jira/browse/MATH-1158
> > > > https://issues.apache.org/jira/browse/MATH-1338
> > > >
> > > > [I've just seen that for branch "feature-MATH-1158" which is
> > > > "git rebase"d on "feature-MATH-1335", the push is recreating
> > > > all the MATH-1335 commits (as guessed from the flood of emails).
> > > > Something I was not expecting: sorry I misunderstood how this
> > > > is supposed to work...]
> > > >
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > [1] See the "links" in the relevant JIRA reports.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
--
Matt Sicker <bo...@gmail.com>
Re: [Math] "rebase" vs "merge" (Was: RNG refactoring)
Posted by Ho...@yahoo.com.INVALID.
Unlike a regular merge, rebase applies a branch's commits' changes onto the specified commit (which is typically identified by specifying a branch name), in the same order as they appear in the branch that is being rebased. The name of the command says that you are redefining the "base", in other words, the starting point, of the branch. Depending on the changes made by those commits, you may see what appears to be the same commit/change applied more than once. See http://ProGit.org/book for great explanations of this and other Git features.
Al
On Mar 26, 2016, 12:01 -0700, Gilles<gi...@harfang.homelinux.org>, wrote:
> On Fri, 25 Mar 2016 11:56:26 -0400, Evan Ward wrote:
> > I'm not sure if this is the problem, but a good rule of thumb is that
> > if
> > you have pushed a commit
>
> Did I?
>
> What I wanted is
> * publish code ("feature-MATH-1335")
> * publish code ("feature-MATH-1158") that requires the new code
> present in "feature-MATH-1335"
>
> So I "rebase"d "feature-MATH-1158" on "feature-MATH-1335" in order
> to incorporate everything from there. [What "git" tells during this
> operation looks like the right thing to do.]
>
> By the way, I did the same with your change: I "rebase"d all my local
> branches on "develop" after your merged your change to that branch.
>
> What is the difference with "merge" and if "merge" should have been
> used, then when does one use "rebase"?
>
> Maybe I did the right thing; and it's just normal that there is an
> email flood in such cases...
>
> Thanks,
> Gilles
>
> > you should merge it instead of rebasing it. It
> > looks to me like 6ddf476 and ce8c82f are the same, so I think when
> > you
> > ran rebase it put it on top of the bug fix I pushed up recently,
> > duplicating the commit.
> >
> > Best Regards,
> > Evan
> >
> > On 03/25/2016 11:34 AM, Gilles wrote:
> > > Hi.
> > >
> > > Last week, and just now, I've pushed local branches that handle
> > > the following issues (and others, either related, or set to
> > > "Won't fix [in current code]" in JIRA[1]):
> > >
> > > https://issues.apache.org/jira/browse/MATH-1335
> > > https://issues.apache.org/jira/browse/MATH-1336
> > > https://issues.apache.org/jira/browse/MATH-1337
> > > https://issues.apache.org/jira/browse/MATH-1339
> > > https://issues.apache.org/jira/browse/MATH-1158
> > > https://issues.apache.org/jira/browse/MATH-1338
> > >
> > > [I've just seen that for branch "feature-MATH-1158" which is
> > > "git rebase"d on "feature-MATH-1335", the push is recreating
> > > all the MATH-1335 commits (as guessed from the flood of emails).
> > > Something I was not expecting: sorry I misunderstood how this
> > > is supposed to work...]
> > >
> > >
> > > Regards,
> > > Gilles
> > >
> > > [1] See the "links" in the relevant JIRA reports.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>