From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master c6f03ed: Fix a problem in url.el without GnuTLS Date: Sun, 14 Dec 2014 18:09:49 +0200 Message-ID: <83iohe43hu.fsf@gnu.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1418573449 1770 80.91.229.3 (14 Dec 2014 16:10:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Dec 2014 16:10:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 14 17:10:42 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 1Y0Bkn-0003HO-TN for ged-emacs-devel@m.gmane.org; Sun, 14 Dec 2014 17:10:42 +0100 Original-Received: from localhost ([::1]:36380 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0Bkn-0000lW-64 for ged-emacs-devel@m.gmane.org; Sun, 14 Dec 2014 11:10:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0BkM-0000lO-C6 for emacs-devel@gnu.org; Sun, 14 Dec 2014 11:10:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0BkH-0003j3-0K for emacs-devel@gnu.org; Sun, 14 Dec 2014 11:10:14 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:49219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0BkG-0003iH-OG for emacs-devel@gnu.org; Sun, 14 Dec 2014 11:10:08 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NGK00I00Y07I900@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sun, 14 Dec 2014 18:10:07 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NGK00I0CY8SHJ20@a-mtaout22.012.net.il>; Sun, 14 Dec 2014 18:10:05 +0200 (IST) In-reply-to: <874mszp2i7.fsf@engster.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:180090 Archived-At: > From: David Engster > Cc: emacs-devel@gnu.org > Date: Sun, 14 Dec 2014 00:13:20 +0100 > > > Sorry, I still don't understand. Which commits from what branches > > does Git merge after 'rebase=preserve'? > > It merges the branch that is implicitly created by moving > 'origin/emacs-24' to a newer parent. That's the missing link, thanks. 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. . 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. . IOW, rebase=preserve is not useful in a merge-based workflow. Is my interpretation correct? 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. I thought that using rebase=preserve would cover the latter use cases as well, but now I understand I was mistaken: I can use "pull --rebase" only if there were no merge-commits since the last refs update; otherwise I need to use "pull". So I cannot configure Git to always use some option when pulling, and forget about that. 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's significantly more complicated, sigh. Which means there's no easy way with Git to support a workflow that preserves mainline, without jumping through some hoops. Is that correct? Or is there a better workflow that preserves the mainline? 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. Because what bzr supported easily and almost seamlessly, Git doesn't -- in the sense that emulating the same workflow is more complicated and thus error-prone. To me, this spells that we fight the tool, i.e. our workflow should change. > You can't at the same time move a branch onto a new parent (which is > what rebase does) and then merge it, so that it looks like you've merged > the original one which had another parent. I only use rebase because I don't know of another way of being able to work on master without having my commits look as if they were made on a branch, after I push them, which AFAIU will happen if someone else pushes before I push my local commits made on master. If there's a reasonably simple way to avoid this effect without rebasing, I guess I'll switch to that. I didn't use rebase with bzr, because there was a simple way to preserve the mainline without rebasing. Btw, I think we need to do something urgently in gitmerge.el to avoid this kind of mistakes. Otherwise, people will keep making these mistakes, and no amount of explanations will ever be able to prevent that. Thanks.