From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: master c6f03ed: Fix a problem in url.el without GnuTLS Date: Thu, 18 Dec 2014 22:18:44 +0100 Message-ID: <87ppbgmzbf.fsf@engster.org> References: <20141211155740.11916.1584@vcs.savannah.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> <87egrynhcd.fsf@engster.org> <87wq5pd0ap.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418937550 3247 80.91.229.3 (18 Dec 2014 21:19:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Dec 2014 21:19:10 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 18 22:19:04 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 1Y1iTP-000410-F0 for ged-emacs-devel@m.gmane.org; Thu, 18 Dec 2014 22:19:03 +0100 Original-Received: from localhost ([::1]:55776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1iTO-0007Oc-Il for ged-emacs-devel@m.gmane.org; Thu, 18 Dec 2014 16:19:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1iTG-0007OL-7f for emacs-devel@gnu.org; Thu, 18 Dec 2014 16:18:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y1iTA-000519-Nw for emacs-devel@gnu.org; Thu, 18 Dec 2014 16:18:54 -0500 Original-Received: from randomsample.de ([5.45.97.173]:49222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y1iTA-00050i-CS; Thu, 18 Dec 2014 16:18:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=0GxCJ1POiZGh7l8koP7Hjh7tjef3LJ9ApjuH5T6XpN0=; b=qblHbOFUU89PDbfsbacqVDvsPY3zv53+jBSqjRKHpLri7Vgde+J1v8RAMNojr6KhrOtR8Q7rrc7wGEbt2CHA1fnNGCH5QHNLGhSMGFzpi2dGa6Xf9NbTnMm74h2NUtiQ; Original-Received: from ip4d154cb9.dynamic.kabel-deutschland.de ([77.21.76.185] helo=spaten) by randomsample.de with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y1iT8-0006eb-Bm; Thu, 18 Dec 2014 22:18:46 +0100 In-Reply-To: <87wq5pd0ap.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Thu, 18 Dec 2014 13:55:26 +0900") User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.91 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 5.45.97.173 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:180295 Archived-At: Stephen J. Turnbull writes: > David Engster writes: > > > up anew. If HEAD is your merge commit, this would mean doing > > > > git branch -D branchname > > git branch branchname HEAD^2 > > > > (You have to delete with '-D', since Git won't see your non-rebased > > branch as merged...). > > Aside: can't you do this in one operation with "git branch -f > branchname HEAD^2"? Yes, thanks. > (Real question, I don't understand your reference > to "seeing ... branch as merged". The docs seem to indicate it should > work.) I posted a script which will set up a few repositories where you can test this: http://article.gmane.org/gmane.emacs.devel/180043 Simply enter the 'ted' repository, do 'git pull --rebase=preserve' and then do 'git branch -d stable'. It won't work. > > This conflicts with how Git orders the parents of a merge. The first > > parent is always the tip of the branch you're currently on. And since > > you do 'git pull' while being on your local master, that will be the > > first parent. > > I don't see a conflict here. What I do see is an ambiguity in the > discription of entry conditions. I don't know what that means. But I can show you how it should *not* look. Simply set up the above test repositories again, now go into 'ted' and do 'git pull', which will merge origin/master. Now do 'git log --first-parent' and you'll see something like this: 82d09a7 Merge branch 'master' of MERGE_REBASE_TEST/upstream 0da1327 merge stable 1f487c9 second commit on master 106847b first commit on master Note how the commit with subject "New commit on master" is not visible anymore, although it was previously (go to 'eli' and type the same log command there, then pull, do it again). AFAIU, this is what Eli wants to avoid. > To push to public: > > git checkout master > git push # public mainline is preserved > git checkout feature-1 # #### these three commands are error-prone > > AFAICS this is what you need to do for emacs-24, too. The problems > are (1) a convenient discipline for those last three commands and (2) > recovery from failed push due to concurrent development. (2) is the problem we are talking about. > > Of course, while *you* can take care in keeping the correct ordering of > > mainline, others won't do that (I guess most are not even aware of this > > issue), > > All bzr fans are aware of it though. There are not many. (FTR, I'm not actually seeing myself as a "bzr fan". I do think however that the bad reputation it got around here was undeserved.) > It's an important part of Bazaar's identity in VCS space. The problem > will be git users who are used to a spaghetti DAG. Yes, as I've written: "most are not aware of this issue". From my experience, many Git users don't even recognize the problem (and when they do, it's usually answered with 'just use gitk', which is kinda sad). > > One could implement a git hook that checks for a linear git history > > of mainline and that rejects pushes otherwise, but I guess Stefan > > isn't very inclined to agree to that. > > My impression is that Stefan is not inclined to encourage work on this > problem; he thinks it's a waste of time. I think he'd come around > quickly if presented with either another problem that would be solved > by the same workflow that preserves linear mainline, or a > "sufficiently convenient" workflow that preserves linear mainline. I > don't intend to speak for Stefan, just to encourage you to not give up > on the idea of a hook before you've clarified the point with him. On further thought, I think such a hook that rejects pushes because of "non-linear mainline" would confuse people to no end. I don't know any project which would do this, and as I've written above, many Git users do not recognize the problem, which makes it hard to fix for them... -David