I'm a happy (Debian) package maintainer which have just switched most of his packages from svn to git. All nice, finally I can work directly on a real source code tree instead of fiddling with patch management system. Nevertheless, patches are separate in topic branches which enable knowing the conceptual changes applied to upstream sources.
But. Even though I can declare where my git repository for package management is, there is still people only playing with the (Debian) source package. Unfortunately, there all changes are flattened in .diff.gz, with neither change separation, nor description of which changes have been made. I know I can use git format-patch to serialize patches into patch series and make them available with dpatch/quilt/..., and precisely here is my question. Have I to do that by hand and by myself? Even though I can do it, I'm convinced there is room for creating a best practice on this, if not even some tools. Is anybody aware of anything like that? Specifically for Debian: do we have any guideline on how to do that? If not it is probably worth to create one ... And finally, the problem of the problems: how about the situation where one patch for topic branch is not enough as topic branches have got intertwined? (I guess this can happen fairly easily with changes evolution, unless git rebase is used). A guideline/best practice on that as well would be utterly welcome. TIA, Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time
Description: Digital signature
_______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss