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 <[email protected]> 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 <[email protected]> > 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, <[email protected]> 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<[email protected]>, > 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > -- > Matt Sicker <[email protected]> > > > > -- Matt Sicker <[email protected]>
