From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.devel Subject: Re: master c6f03ed: Fix a problem in url.el without GnuTLS Date: Wed, 17 Dec 2014 10:58:15 +0100 Organization: Probably a good idea Message-ID: References: <20141211155740.11916.1584@vcs.savannah.gnu.org> <87ppbquo97.fsf@gmail.com> <83zjaurreb.fsf@gnu.org> <874mt14wrc.fsf@lifelogs.com> <83egs5rzlr.fsf@gnu.org> <877fxx2e6t.fsf@lifelogs.com> <83a92trlgs.fsf@gnu.org> <87oar81jlp.fsf@lifelogs.com> <87bnn7rkcq.fsf@engster.org> <877fxvri96.fsf@engster.org> <87zjarznzs.fsf@lifelogs.com> <87sigjpri2.fsf@engster.org> <838uib60jv.fsf@gnu.org> <87mw6rpc6l.fsf@engster.org> <83sigj48z5.fsf@gnu.org> <874mszp2i7.fsf@engster.org> <83iohe43hu.fsf@gnu.org> <87vbldoqp2.fsf@engster.org> <83a92py3p3.fsf@gnu.org> <87mw6oodep.fsf@engster.org> <83lhm7wfd4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418810340 5889 80.91.229.3 (17 Dec 2014 09:59:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Dec 2014 09:59:00 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 17 10:58:53 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y1BNd-0005by-DF for ged-emacs-devel@m.gmane.org; Wed, 17 Dec 2014 10:58:53 +0100 Original-Received: from localhost ([::1]:48601 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1BNc-0004co-DU for ged-emacs-devel@m.gmane.org; Wed, 17 Dec 2014 04:58:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1BNT-0004by-3h for emacs-devel@gnu.org; Wed, 17 Dec 2014 04:58:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1BNN-0001uK-4o for emacs-devel@gnu.org; Wed, 17 Dec 2014 04:58:43 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:49271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1BNM-0001u7-Py for emacs-devel@gnu.org; Wed, 17 Dec 2014 04:58:37 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Y1BNK-0005Sl-8U for emacs-devel@gnu.org; Wed, 17 Dec 2014 10:58:34 +0100 Original-Received: from steria10.steria.no ([195.204.41.10]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Dec 2014 10:58:34 +0100 Original-Received: from sb by steria10.steria.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 17 Dec 2014 10:58:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 129 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: steria10.steria.no Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (windows-nt) Cancel-Lock: sha1:dqOoth/mjkYg+hi7/BXlB4s+bSE= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:180222 Archived-At: >>>>> Eli Zaretskii : > Once again, the problem is in this situation: > . My work on a feature branch is almost finished, so I merge from > master to make sure my feature doesn't break anything and isn't > broken by development on master. > . I then merge from the feature branch to master and attempt to push, > but the push is rejected. > . I then pull --rebase=preserve and push again > It's the last step that causes trouble, and the "trouble" here is that > commits I merged from master before merging back might be merged again > in the future, if I need for some reason to continue working on that > feature branch again. Let me see if I understand, you branch off from master like so: -a---b-c-d- master \ e-f- eli-feature-1 Then you wish to prepare for a push so you merge in master: -a---b-c-d--- master \ \ e-f----g- eli-feature-1 (where "g" is the merge commit) You merge your feature branch into master (ff merge): -a---b-c-d------ master \ \ / e-f----g---- eli-feature-1 And then push of master fails, and you do git pull --rebase=preserve and at this point I have no idea what the branches look like, since I've never used "--rebase=preserve". But if I understand you correctly, you're concerned that if you continue to work on eli-feature-1 and then merge into master, then the commits "b", "c", and "d" that were merged into your feature branch will be re-applied? Have you seen this happen? The "git merge" command seems to be generally very good at backing off when the changes are already in place (e.g. when I cherry pick changes from master back to a release branch, and later merge the release branch, I rarely see conflicts). At least, if you were doing ordinary merges in pull, it would never be a problem... but I'm guessing (note: "guessing") now that what happens is that what you end up with on master, is a rebased version of the merge commit "g", ie. something like this: -a---b-c-d-i-j-h- master \ \ / e-f----\/ \g---- eli-feature-1 where "i" and "j" are the commits that blocked your push, and "h" is a rebased version of "g"? (I saw later that my guessing might be off, see below for more) Hm... what would happend if you continue to work on eli-feature-1 and then merge back into master, I have no idea... probably nothing good. The simplest way to proceed would be to just delete the existing eli-feature-1 and create a new eli-feature-1 off the rebased merge commit "h". You could pop off "g" of eli-feature-1, ie. git checkout eli-feature-1 git reset --hard HEAD~1 and then merge in master to get "h" in its place git merge master But it amounts to the more or less same thing (and it all depends on the behaviour being like I describe, which may not be the case, since I'm just guessing). > Where will origin/master help in this situation? Not directly, but you can prepare for the newest that will be on master after the pull before push, without moving off your feature branch, ie. git fetch git merge origin/master >> But actually, instead of merging master into your feature >> branch, I'd rather recommend rebasing it *onto* master, but explicitly > That'd lose too much information, so I'd like to avoid that if > possible. It might also cause complications if I have more than 1 > active feature branch, and want to compare or merge between them. It > is also a bad idea when the branch is a public one, as you point out. FWIW I agree on all of Eli's saying here. [snip! rebasing feature branches] > I would like to have the same workflow for both local branches and > public ones, such as emacs-24, if at all possible. That will > relieve the "memory pressure" and reduce the probability of errors. I'm again in complete agreement with Eli. [snip!] > I actually don't mind merge commits, as long as they reflect what > was actually done, as opposed to being generated by Git out of thin > air. +10 > What I certainly want to avoid is any kind of rebasing, cherry-picking > or similar things that will then put me at risk of having the same > commits merged again, because the original commits are rewritten or > not recorded in the DAG. Aah... so that's what happens: "b", "c", "d" in the example above (that come from master into your feature branch), are rebased, and then later reapplied...? If so that's bad! (I *knew* there were good reasons to shun rebase, and if this is the case I have some real ammunition the next time a discussion with a rebase entusiast comes up)