From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: fixing an Elpa package Date: Mon, 20 Apr 2015 13:04:56 +0800 Message-ID: <87383vgzk7.fsf@ericabrahamsen.net> References: <87a8y5ih6c.fsf@ericabrahamsen.net> <87wq18hji4.fsf@ericabrahamsen.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429506331 32692 80.91.229.3 (20 Apr 2015 05:05:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Apr 2015 05:05:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 20 07:05:20 2015 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 1Yk3tY-00046a-9J for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 07:05:20 +0200 Original-Received: from localhost ([::1]:51801 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yk3tX-0003nQ-8s for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 01:05:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yk3tS-0003jH-NG for emacs-devel@gnu.org; Mon, 20 Apr 2015 01:05:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yk3tP-0002Sm-GY for emacs-devel@gnu.org; Mon, 20 Apr 2015 01:05:14 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:49695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yk3tP-0002Se-A6 for emacs-devel@gnu.org; Mon, 20 Apr 2015 01:05:11 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Yk3tO-00040H-7z for emacs-devel@gnu.org; Mon, 20 Apr 2015 07:05:10 +0200 Original-Received: from 222.129.224.131 ([222.129.224.131]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Apr 2015 07:05:10 +0200 Original-Received: from eric by 222.129.224.131 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Apr 2015 07:05:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 81 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 222.129.224.131 User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:xPeNXGRaIxlZOZg+kNAWwUtS0cE= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:185688 Archived-At: Stefan Monnier writes: >>>> I guess that makes sense from Git's point of view, >>> If the hashes are the same, then I don't see why it makes sense. >> About 275 commits from the external repo went into Elpa as a single >> squashed commit, ab3b913. The file contents are the same, but I assumed >> Git saw no correspondence between the one squashed and many un-squashed >> commits, and told me I was starting over. > > I think the situation is not quite like you say. I tried > > git subtree merge --squash -P packages/gnorb gnorb/master > > and it did not try to re-add everything. It did try to add too much > ("git diff | wc" is a whole 80KB), because in > > % git log packages/gnorb/ > [...] > commit ce7004456df8d17d1b1bb9b1feab3ddafb1e078a > Author: Eric Abrahamsen > Date: Sat Oct 25 08:19:41 2014 -0700 > > Merging Gnorb commits up to 1.0.1 > > you somehow managed to "merge" without keeping track of the metadata > ("git subtree merge --squash" doesn't keep all commits, but it does > keep the hashes in the commit messages, so "git merge" doesn't > understand what's going on, but "git subtree merge --squash" normally > does, although in the above commit there's no such tracking, so maybe > you didn't use "git subtree merge --squash"). Thanks, I didn't realize that's how it worked. Beats me how I got it into that state, though. >> What's the next step? Commit a removal of the whole subtree, and start >> over? > > I installed a dummy commit which merges the tree to which you apparently > sync'd in the above commit, so the above > > git subtree merge --squash -P packages/gnorb gnorb/master > > now results in much fewer conflicts ("git diff | wc" is a mere 5KB). > So now you just have to use the above command (or another one if you > want to merge another revision than "gnorb/master"), then resolve the > conflicts, then commit and push. > If you need more help, you know where to find me ;-) Okay, thanks for this. Just so I'm very clear: the above command uses --squash so that Git would pay attention to the metadata in your dummy commit, but I should not be using --squash from here on out, is that correct? I ran the command you listed above, resolved the conflicts, and committed. That gave me one squashed commit containing all the new commits from my external repo, and another merge commit (this second commit was huge, and looked like most of the code from the package). The external and Elpa trees were not in sync, though -- "diff -r" gave me some differences. Running the subtree merge just told me that the subtree was already at 4e7039a15, and didn't do anything else. I ran the merge again without --squash, just to see what would happen, and that appeared to pull in most of the remaining differences. Once I'd resolved conflicts and committed, though, all of the individual commits from the external repo were pulled into Elpa. So maybe I'm meant to keep --squash in after all? The top of the log now reads: 47f3dce Merge commit '4e7039a15b47244e7bd2c580d8bce976a6116b5a' d3ce5e0 Merge commit 'be7fc18f06df6a73214c03e9f28640ec77b24264' be7fc18 Squashed 'packages/gnorb/' changes from 321b23b..4e7039a With all the commits from the external repo below that. And, amazingly, there is still a two-line diff (in gnorb-bbdb.el) between the external and Elpa repos. I don't get it. Sorry to keep on with this... Eric