You have two options. In both cases, you'll have a separate elpa
branch on your repo. Whenever you do your git subtree merging into the
GNU Elpa repository, use your repo's elpa branch as the remote
(instead of master).

You can:

Create an elpa branch in your repo, child of the master branch.
Delete from the elpa branch everything but the package source files.
Whenever you update master, merge that into elpa.

This has two small disadvantages. - Every time you edit a test file
you'll get a merge conflict when you try to merge master into elpa. -
Even though you deleted the files from HEAD, they will still exist in
the history of your repo (and therefore, in the history of the GNU
Elpa repo).

You can also (this is the one I used):

Create an orphan elpa branch, and manually place in there only the
files you're ok with.
Delete and recreate the master branch.
Merge elpa into master, then manually add to master all of the files
you didn't want on elpa.
Do your development on the elpa branch, and merge that into master.

This has the advantage that the unwanted files will be wiped from
history, so the GNU Elpa repo will never know about them. It has the
obvious disadvantage that it will completely reset your repo's
history.


Cheers

2015-02-04 7:24 GMT-02:00 Jackson Hamilton <jackson@jacksonrayhamilton.com>:

> Hi Artur, I am interested in the "git details". Please elaborate.
>
> On Tue, Feb 3, 2015 at 4:13 AM, Artur Malabarba <bruce.connor.am@gmail.com>
> wrote:
>>
>> If that package is only used for testing, you can also just not merge
>> it into elpa and do your testing elsewhere (e.g. Travis+github).
>> That's what I did with Names, because the tests involved a lot of
>> packages from other people with a ton of changes made by me. I'm not
>> saying I couldn't put those inside the Elpa/package/ directory, but it
>> was easier this way than to worry about copyrights.
>>
>> I can go into the `git' details necessary for this if you'd like.
>>
>> 2015-02-03 5:57 GMT+00:00 Jackson Hamilton
>> <jackson@jacksonrayhamilton.com>:
>> > On the "Copyright (C) 2014 Johan Andersson", are you suggesting I change
>> > the
>> > copyright notice in ert-async.el myself, or that I should contact the
>> > author
>> > and tell him to change it?
>> >
>> > In either case that seems inappropriate.
>> >
>> > context-coloring/languages/javascript/libraries/ also includes 3
>> > JavaScript
>> > libraries with their own copyright notices. These appear to be licensed
>> > under the FreeBSD license. Should they be handled specially?
>> >
>> > Regards,
>> > Jackson
>> >
>> > On Mon, Feb 2, 2015 at 9:58 AM, Stefan Monnier
>> > <monnier@iro.umontreal.ca>
>> > wrote:
>> >>
>> >> > which included 247 commits. I am not sure if these should be
>> >> > squashed,
>> >> > but
>> >> > based on the commit log it seems like this subtree approach is how
>> >> > other
>> >> > people are managing their externally-maintained packages, so I assume
>> >> > it
>> >> > is
>> >> > okay to add the whole history.
>> >>
>> >> Indeed, it's OK to keep the history.
>> >>
>> >> > On top of that, I added 2 patches so that I could test ELPA locally.
>> >> > I
>> >> > was
>> >> > able to install my package via a "local-elpa" as described in the
>> >> > README.
>> >> > The patches for that are attached in this email.
>> >>
>> >> I think the hydra-test.el has been fixed by someone else in the
>> >> mean time.  As for your change:
>> >>
>> >> > +./context-coloring/libraries/ert-async.el:;; Copyright (C) 2014
>> >> > Johan
>> >> > Andersson
>> >>
>> >> I think this change is incorrect.  IIUC this is johan.rejeep@gmail.com
>> >> we're talking bout, and he signed the copyright assignment forms, so
>> >> the line in ert-async.el should say "Copyright (C) 2014 Free Software
>> >> Foundation, Inc" (at which point you won't need any change to
>> >> copyright_exceptions).
>> >>
>> >>
>> >>         Stefan
>> >
>> >
>
>