how to generate patches out of $DVCS branches: best practices?
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 signature.asc Description: Digital signature ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: how to generate patches out of $DVCS branches: best practices?
On Tue, Jul 15, 2008 at 01:38:14PM -0500, John Goerzen wrote: I don't split out patches, but all my Debian packages live on git.debian.org (except software where I'm the upstream, in which case it's on my own git server). Using gitweb, people can inspect the changelog and download diffs of individual changesets. You can also craft URLs for people that will do things such as spit out a diff between upstream and debian heads, or between two different Debian releases. Well, it's all fine and I'm already doing all of this, but this doesn't really address my problem. My problem is to cope with people not knowing git at all. I feel they have the right to understand what changes I applied wrt upstream (remember the discussions after the OpenSSL security flaw?). Also, diffs and individual changesets fail to address a problem which is instead addressed by commented patches. That is, they are missing a single description for the whole topic branch. You can address this in git (AFAIK) only by keeping topic branches as single changesets using a describing commit message, but this requires rebasing which is bad in published topic branches. Also, currently in Debian you have tools which help maintainers describing their patches, e.g. lintian complaining about dpatches not commented. You loose this benefit if you go for $DVCS branches alone. 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 ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: how to generate patches out of $DVCS branches: best practices?
Stefano Zacchiroli wrote: 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. I don't split out patches, but all my Debian packages live on git.debian.org (except software where I'm the upstream, in which case it's on my own git server). Using gitweb, people can inspect the changelog and download diffs of individual changesets. You can also craft URLs for people that will do things such as spit out a diff between upstream and debian heads, or between two different Debian releases. -- John ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Re: [debian] where to document branch layout
Stefano Zacchiroli [EMAIL PROTECTED] writes: My question is whether we have a guideline about *where* to document branch layout for a given package. Regarding Debian, debian/README.source comes to mind quickly, but its current description in policy does not make it clear that it is the suitable place where to document branch layout. The intention is to use that file for anything that helps explain how to make changes to a Debian source package. I think this would qualify. A more general question is whether there is a fixed set of well known branch layouts that can be written down so that we can reference each layout with a clear name. If this is so, I believe this is the right place where to attempt defining such a set. FWIW, I've been keeping notes on what I'm personally doing at: http://www.eyrie.org/~eagle/notes/debian/git.html -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ ___ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss