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: Sun, 14 Dec 2014 22:40:41 +0100 Message-ID: <87vbldoqp2.fsf@engster.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418593280 2402 80.91.229.3 (14 Dec 2014 21:41:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Dec 2014 21:41:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 14 22:41:14 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 1Y0Gue-0001lA-SG for ged-emacs-devel@m.gmane.org; Sun, 14 Dec 2014 22:41:13 +0100 Original-Received: from localhost ([::1]:37241 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0Gue-0003zW-EF for ged-emacs-devel@m.gmane.org; Sun, 14 Dec 2014 16:41:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0GuN-0003RO-2B for emacs-devel@gnu.org; Sun, 14 Dec 2014 16:41:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0GuF-0003cX-PR for emacs-devel@gnu.org; Sun, 14 Dec 2014 16:40:55 -0500 Original-Received: from randomsample.de ([5.45.97.173]:45764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0GuF-0003cL-G9; Sun, 14 Dec 2014 16:40:47 -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=DLHpwAPujQuMW5UiGLhU0Nl4UcGlsZgfaVLIbmlltx0=; b=IEETGKbboylJxUdwALH4AjAzQD4aeEGMNRPLaeDMlSfqWsxknic+ezc1jb5Yq7SspUkF6Ws7A7SKaW7wEUTqOkvRFcDatC2Js6S2PO66fzuinAqYHUhrBg6UaWpahyjW; 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 1Y0GuD-0004Ja-JE; Sun, 14 Dec 2014 22:40:45 +0100 In-Reply-To: <83iohe43hu.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 14 Dec 2014 18:09:49 +0200") 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:180107 Archived-At: Eli Zaretskii writes: > So this means that: > > . Using "pull --rebase=preserve" always rewrites the merge to come > from some unnamed branch, which is different from the branch that > originated the merged commits. Yes. > . This is true for merges from local branches as well. Therefore, > using this option is not advisable for local branches, because > doing that would mean trouble when I next merge from master into > my local branch -- I will get the same commits back again. Do you mean you have a long-living local branch which you regularly merge to master? You're right that in this case doing 'pull --rebase=preserve' is problematic. If you continue to work on your branch and merge from master, you will indeed merge the rebased commits. To avoid that, you would have to delete the old branch and continue working on the rebased one. > . IOW, rebase=preserve is not useful in a merge-based workflow. Rebasing is the anti-thesis to merging, so a purely merge-based workflow wouldn't touch it in the first place (see: Bazaar). > If it is, then here's my conundrum. When I make changes in master, I > don't want them to look as if they were made on some branch when I > push them. Why? for starters, because "log --first-parent" won't show > them. So I use "pull --rebase" to avoid that. This works well as > long as I didn't make any local merge-commits, be it from my local > branches or from public branches such as emacs-24. Isn't flattening of the history precisely what you want when you have merges of local branches, so that they appear like they were made on master? > AFAIU, an alternative, when I have local merge-commits, is to use > "pull --ff-only", and when it refuses to pull, use "reset --hard > origin/master", and then "merge -no-ff" and commit, before pushing. That would also mean you have to fix conflicts again (unless you use the 'rerere' feature, but let's not go there yet). > Which means there's no easy way with Git to support a workflow that > preserves mainline, without jumping through some hoops. > > Is that correct? I would say it is. AFAIK, Git has no notion of 'mainline' like Bazaar had, so trying to preserve it does require a lot of discipline. > If there is no better workflow, perhaps we need to radically rethink > our recommended project workflow, like not base it on merges but on > rebase, or push fixes to master and then cherry-pick them to the > release branch, or something else. Cherry-picking to emacs-24 would indeed make some things easier. Most importantly, it would make gitmerge.el obsolete (which I consider a good thing). -David