Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Date: Mon, 28 Mar 2016 00:49:27 +0000 (UTC)
From: Al Chou <hotfusionman@yahoo.com.INVALID>
Reply-To: Al Chou <hotfusionman@yahoo.com>
To: Commons Developers List <dev@commons.apache.org>
Message-ID: <258366476.1360521.1459126167994.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
 <CACmp6kr2A=S+R162+_JsHmTT9Cf4nm0FYf6OSvAAaAG3i7yR+w@mail.gmail.com>
References: <77698a8bd514adeebd721fd1b682a5ec@scarlet.be>
 <56F55FAA.20405@nrl.navy.mil> <e595dc4ba59025416321da7276dc23cb@scarlet.be>
 <e2a9e4b4-900e-47a8-8803-cf5fe3d1772a@Spark>
 <CACmp6kr2A=S+R162+_JsHmTT9Cf4nm0FYf6OSvAAaAG3i7yR+w@mail.gmail.com>
Subject: Re: [Math] "rebase" vs "merge" (Was: RNG refactoring)
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_1360520_2105796411.1459126167989"

------=_Part_1360520_2105796411.1459126167989
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Agreed, changing the commit ancestry history of a branch that other people =
have already (even merely potentially) fetched and checked out locally is g=
enerally frowned upon. =C2=A0Interesting to hear that anyone ever has gotte=
n consensus to do so via "pull --rebase"! =C2=A0On rare occasions at my job=
 we have needed to "push --force" a publicly shared branch to clear up a pr=
oblem, and we do get consensus before doing so, but no one enjoys those sit=
uations.
Al=20

    On Sunday, March 27, 2016 5:44 PM, Matt Sicker <boards@gmail.com> wrote=
:
=20

 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, <HotFusionMan@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 branc=
h
> 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 chang=
es
> 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<gilles@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
> >
>


--=20
Matt Sicker <boards@gmail.com>


------=_Part_1360520_2105796411.1459126167989--