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: Sat, 13 Dec 2014 21:59:10 +0200 Message-ID: <83sigj48z5.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1418500788 13802 80.91.229.3 (13 Dec 2014 19:59:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Dec 2014 19:59:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 13 20:59:41 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 1Xzsqn-0001VU-IP for ged-emacs-devel@m.gmane.org; Sat, 13 Dec 2014 20:59:37 +0100 Original-Received: from localhost ([::1]:34156 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xzsqn-0004RU-5f for ged-emacs-devel@m.gmane.org; Sat, 13 Dec 2014 14:59:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xzsqf-0004RC-GK for emacs-devel@gnu.org; Sat, 13 Dec 2014 14:59:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xzsqa-0001DI-67 for emacs-devel@gnu.org; Sat, 13 Dec 2014 14:59:29 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:59915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzsqZ-0001Cv-Tf for emacs-devel@gnu.org; Sat, 13 Dec 2014 14:59:24 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NGJ00M00DV8FS00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 13 Dec 2014 21:59:22 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NGJ00M7UE6XEF20@a-mtaout20.012.net.il>; Sat, 13 Dec 2014 21:59:22 +0200 (IST) In-reply-to: <87mw6rpc6l.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.166 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:180035 Archived-At: > From: David Engster > Cc: emacs-devel@gnu.org > Date: Sat, 13 Dec 2014 20:44:18 +0100 > > When you rebase a commit, it becomes a new one. Therefore, you can only > safely rebase "local" commits (meaning: commits only *you* have). If "safely" here means "while preserving the commit's sha1", then it's quite obvious. But why would that matter in this scenario? And why does that cause the merged versions appear as if they were not merged at all, even when rebase=preserve was/is used? > > The documentation seems to suggest that "pull --rebase=preserve" is > > exactly the right thing in this situation. > > The name "preserve" is misleading. I didn't mean the name, I meant its documentation. It says: locally committed merge commits will not be flattened by running 'git pull' "locally committed" seems to fit the scenario we are discussing, no? > It does not mean that you have the same merge after the > rebase. That's not possible, since the commits change during this > operation. I didn't say I want to have the same merge. All I want is to have _some_ indication there was a merge from the other branch, including when that branch is a public branch. You seem to say it's not possible with Git. > It helps to think of a rebase simply as a series of cherry-picks. Any > conflicts you resolved in a merge commit are now resolved commit by > commit. If you do 'rebase=preserve', what git does is: it tries to > re-create(!) the merge commit with the rebased commits afterwards. This > merge commit is pure metadata now, since there are no conflicts to > resolve. Sorry, I still don't understand. Which commits from what branches does Git merge after 'rebase=preserve'? And how do conflicts enter this picture? Suppose there were no conflicts at all during the original merge -- would the merge still disappear after 'rebase=preserve'? > >> Instead, simply merge master into your tree. Despite what others may > >> say, this is still a perfectly valid thing to do in Git. :-) This what > >> 'git pull' will do by default (unless you configured it otherwise). > > > > Yes, but then my commits will appear as merge-commits, won't they? > > Not sure what you mean. This is equivalent to the merge-based workflow > we had with Bazaar. But I didn't work on a separate branch, I worked in master. Therefore, I'd like to avoid merge-commits if possible, and I thought using 'rebase=preserve' does that, and also lets me merge branches, whether my local branches or the emacs-24 release branch.