Trent W. Buck wrote:
> Marco Túlio Gontijo e Silva <firstname.lastname@example.org> writes:
>> I think a big repo is good for making the same changes in a lot of
>> packages. If the packages look the same, or almost the same, most of
>> the changes we do to one of the packages will be neeeded to do to the
>> another. Then, we would end up with the same packages, with the same
>> body and description in a lot of different repos.
> If you have a debian/control.in, for example, which is the same for all
> Haskell libraries, this could be done in Darcs without needing a single
> monolithic repository, simply by pulling patches to debian/control.in
> into all the per-package repos. AIUI Mercurial and Git approximate this
> as well (transplant, rebase?), but they do so by changing the patches'
> identity (i.e. it's hash/checksum)... which makes me worry about the
> implications of doing so on a long-term basis.
I worried about that to, moving to git. I have several things like
this: an sgml-common directory that I use in every package that has
manpages, and the like.
A git merge commit is simply a commit with two parents. The sha1 of
both parents is recorded. It is a stable long-term strategy and it works.
I do not recommend rebase for anything this group is doing.
>> It'd be easier to forget a package this way.