Re: how to generate patches out of $DVCS branches: best practices?
On Tue, Sep 23, 2008 at 08:25:38AM +0200, martin f krafft wrote: also sprach Stefano Zacchiroli [EMAIL PROTECTED] [2008.07.15.2031 +0200]: 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. So that I can remove this thread from my pending list, have you looked at topgit? I know it's still rough, but I think it's what you're looking for. topgit's source package has a README.source, and I've looked at least at what topgit is and I indeed got convinced that it is what I was looking for. Still, I haven't put it into use to be able to comment any further. 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?
also sprach Stefano Zacchiroli [EMAIL PROTECTED] [2008.07.15.2031 +0200]: 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. So that I can remove this thread from my pending list, have you looked at topgit? I know it's still rough, but I think it's what you're looking for. topgit's source package has a README.source, and I'd love comments, especially how to improve the process: http://git.debian.org/?p=collab-maint/topgit.git;a=blob;f=debian/README.source;hb=HEAD -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems in a country where the sole employer is the state, opposition means death by slow starvation. the old principle: who does not work shall not eat, has been replaced by a new one: who does not obey shall not eat. -- leon trotsky, 1937 digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ 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