Re: fixing an Elpa package

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> 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?

> 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.

> 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.


        Stefan