Re: fixing an Elpa package

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I originally incorporated the package into Elpa as a subtree, squashed
>> into one commit, from a repository elsewhere on my filesystem that is
>> linked with Github. Since then there are now four commits to this
>> subtree in Elpa, two of them squashes from the external repository.
>
> If I didn't warn you not to squash, then I'm sorry I failed to do that.
> Why did you squash in the first place?

Probably no good reason -- maybe I thought it was tidier. This was my
first time doing anything like this, and I was flailing a bit.

>> In the meantime, my old computer died and I got a new one.  So I
>> re-cloned both the Elpa repository and the Github-based repository onto
>> the new machine. If I add my Github-based repository as a remote in the
>> Elpa repository, then fetch and subtree-merge, Git tells me there are no
>> common commits, and wants to merge in all (317) commits from the
>> external repository.
>
> Is the Github repository using different hashes from the old one from
> which you merged (with squashing)?
>
>> 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.

>> but I don't want to pollute Elpa with all those commits.
>
> Merging subtrees with full history, is the way I recommend people do it
> and the way it's done for most of the current subtrees, AFAIK.
> After all, if it's installed as an "external" we also end up with "all
> those commits".
>
>> I'm not sure it would even work, either.
>
> I can't see why not.
>
>> Granted, it was probably a bad idea to take the subtree approach to
>> begin with.
>
> It's not set in stone.  So to fix this, we can either do a proper
> (non-squashed) "git subtree" merge, or we can switch to a (non-squashed
> either) external tree.

Okay, I'm glad it's salvageable. I don't actually care if it's a subtree
or external, but I've got the subtree-related commands written down, so
might as well stick with that. I think that, so long as I don't squash
this time around, I can avoid stepping on my own feet again.

What's the next step? Commit a removal of the whole subtree, and start
over?

Semi-related question: if a users reports an emacs bug with my package
in the package header, or it gets tagged later, will an email be
automatically sent to me as maintainer?

Thanks for your help,
Eric