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 00:13:20 +0100 Message-ID: <874mszp2i7.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1418512447 16527 80.91.229.3 (13 Dec 2014 23:14:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Dec 2014 23:14:07 +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 00:14:01 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 1Xzvst-0002Jc-OC for ged-emacs-devel@m.gmane.org; Sun, 14 Dec 2014 00:14:00 +0100 Original-Received: from localhost ([::1]:34551 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xzvst-0003u0-2X for ged-emacs-devel@m.gmane.org; Sat, 13 Dec 2014 18:13:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzvsZ-0003sr-1Q for emacs-devel@gnu.org; Sat, 13 Dec 2014 18:13:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XzvsT-0000LS-OC for emacs-devel@gnu.org; Sat, 13 Dec 2014 18:13:38 -0500 Original-Received: from randomsample.de ([5.45.97.173]:44938) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzvsT-0000GT-Bw; Sat, 13 Dec 2014 18:13:33 -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=8V3fL31fJVsdjI8oiZhV72HaMou+R5B6i//nK96KWpA=; b=RHl1KrMo6Jw7e2cde6piDJKjQpbsi4PM8gYN2JNj15z0tMg2WMkFzuc3vykX+pmmbNolm8rTJCzR4ZoZWOZE0fP9aW7R8FlEFY0siC5pNt9ir+oId/f7L/ZP6HkynDdn; 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 1XzvsM-0008DI-1J; Sun, 14 Dec 2014 00:13:26 +0100 In-Reply-To: <83sigj48z5.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 13 Dec 2014 21:59:10 +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:180043 Archived-At: --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> 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? I think we really have to discuss this on an actual example. I've attached a small script which will create three directories underneath a directory called "MERGE_REBASE_TEST": 'upstream', 'ted' and 'eli'. There are two branches, 'master' and 'stable', which Ted sets up and pushes. I put some sleeps in there just so that the commits have different time stamps. Ted merges 'stable' into 'master', but does not push yet. Then Eli makes a new commit on 'master' and pushes. This is where the script ends. Now go to 'ted' and do 'gitk --all' to see the situation. If you try to push with 'git push origin master', then this will fail because there's this new commit from Eli. Now do 'git pull --rebase=preserve', and then again do 'gitk --all'. You'll see that the 'stable' branch was rebased onto 'origin/master'. This changed the SHA1 of those two commits on 'stable', as they now descend from a different parent. You *have* a merge, but it is *not* a merge from origin/stable, but from a new (unnamed) branch that was created by rebasing origin/stable. Simply delete the MERGE_REBASE_TEST directory and run the script again to try the alternatives for Ted. 'git pull --rebase' will do the same as '--rebase=preserve' but will simply drop the merge commit ("flatten the history"). Again, this will *not* merge the two commits from origin/stable (a 'git log stable ^master' will list all commits that are in stable but not in master). If you simply do 'git pull', this will merge origin/master into your tree. If you push this, everything will be OK. The above log command will show nothing, just as it should after a succesful merge. > 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. 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. > 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. > 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'? I guess it's better to forget conflicts. I was hoping it would make clearer how rebase works, but it just complicates things. -David --=-=-= Content-Type: text/x-sh Content-Disposition: inline; filename=merge-rebase-test.sh #!/bin/sh mkdir MERGE_REBASE_TEST cd MERGE_REBASE_TEST # Create bare upstream mkdir upstream cd upstream git init --bare cd .. # Ted clones, creates two commits on master and pushes. git clone upstream ted cd ted echo "bla" > foo git add foo sleep 2 git commit -a -m "first commit on master" echo "bla2" >> foo sleep 2 git commit -a -m "second commit on master" git push origin master # Ted now creates branch 'stable' with two commits and pushes. git checkout -b stable echo "bla" > bar git add bar sleep 2 git commit -a -m "commit to stable 1" echo "bla2" >> bar sleep 2 git commit -a -m "commit to stable 2" git push origin stable # Ted goes back to master and merges 'origin/stable', but does NOT push. git checkout master sleep 2 git merge --no-ff origin/stable -m "merge stable" cd .. # Eli clones, creates new commit on master and pushes git clone upstream eli cd eli git checkout master echo "bla3" >> foo sleep 2 git commit -a -m "New commit on master" git push origin master cd .. --=-=-=--