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.


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.


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

Attachment: signature.asc
Description: Digital signature

vcs-pkg-discuss mailing list

Reply via email to