Re: fixing an Elpa package

[Eric Abrahamsen]

Stefan Monnier <address@hidden> 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 <address@hidden>
>    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