recreating historic packages

[Manoj Srivastava]

On Tue, Sep 30 2008, martin f krafft wrote:

> also sprach Manoj Srivastava <srivasta at acm.org> [2008.09.30.2131 +0200]:
>>         At this point, pre-topgit, that is what my tags do:
>>  I tag the ./debian/ branch and the integration branch. Checking out the
>>  tag on the integration branch, and installing the submodules, are all
>>  you need to do. The single tag checkout reproduces exactly the state of
>>  the tree that was used to build the package.
>
> git-submodules simply track refs of, uh, submodules, in the index.

        Yes, And?

>>         With topgit, this gets messy, since not just the integration
>>  branch tip needs to be tracked, we need every topgit branch base and
>>  tip to regenerate the patch series. me no likum.
>
> Well, with-git-submodules, you need to create a new commit on the
> integration or master branch *every* time you change any submodule
> so that it points to the latest head of the submodule. That's hardly
> cleaner...

        The submodule I have are the ./debian and ./debian/common
 directories. So, evey time I change ./debian/common (once or twice a
 year), the ./debian directories for all packages are updated (about 30
 or so branches). For every debian release, the ./debian dir is changed,
 and the integration branch is updated.

        This is mostly automated. I change ./debian, and commit,
 git_rel does a cd..; git add debian, git commit -s; and I am done.
 After testing, I just run tag_release <package> from anywhere on my
 home machine, and it does the tagging and the pushing.

        One tag.

        Now, if I have 5-6 branches, I can perhaps write something up
 that goes to each branch, and tags the base/tip. This is another 10-12
 tags.

        Seems more messy to me. YMMV.

        manoj
-- 
"Little else matters than to write good code." Karl Lehenbauer
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C