On 06/06/2008, Miriam Ruiz wrote: > As we will have different policies for SVN and git, it might make > sense to make a wiki document defining what is expected from a package > in each of them, and how that can be handled. In SVN whe had a policy > of debhelper+quilt+debian directory only. BTW, this allows the > possibility of adding copyright and license texts to patches (I don't > know how that would be handled in git, probably in the git log). The canonical place to add copyright and license information is debian/copyright. If you want to claim copyright through the git log, see git-commit's -s option. See also Documentation/SubmittingPatches in the Linux kernel source, or at [1]. I think it may be what you want. 1. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches > It is quite logical that we keep using debhelper only (no cdbs in git > either). Also the packages in git need not use any patch system > (quilt, dpatch) as git already takes care of that. I guess > pristine-tar should also be used. JFTR, pristine-tar is just a tool to get any .orig.tar.gz from the upstream branch, nothing more, nothing less. Its use can also be postponed, when migrating a repository from svn to git, since the deltas (the tiny object files that makes it possible to get back the tarballs) are handled in a separate branch, and can be committed for former versions at any time, provided that those versions were previously added in the upstream branch. > Could someone with some experience in managing packages with git step > forward and try to set the basic guidelines about how we should better > handle it to get the best results, please? Maybe Andres or Cyril? As I said, I never used git-buildpackage, nor that everything-in-git layout, so I'm afraid I won't be of some help right now. I'll check the wikipages and possibly convert some repositories to see how things are going, though. Also, pointing to wiki pages in mails is fine, but that makes it impossible for people following discussions to read those pages while disconnected. Maybe we could try and remember pasting (at least the relevant) parts of those wikipages when pointing to them? That particular matters (as opposed to more static pages) since the contents might have changed when people get back online. Mraw, KiBi.
Attachment:
pgpyz77FjVini.pgp
Description: PGP signature