On Tue, Jul 15, 2008 at 03:39:27PM -0700, Russ Allbery wrote: > Hm, that's a good point. I'm not sure. It's possible that maintaining a > distinction between manipulating the output source package and > manipulating the revision control system is good. I've documented more > details frequently on a team wiki page for the Debian package mantenance > team.
Yes, the distinction might have sense, as explained in the current wording, which states that the target of README.source is who ends up having in her hands a source package. But then we are back at the initial problem: where to document branch layout and other DVCS related information. Even though this is not a need for the random NMUer, it is a need for someone willing to contribute "more" to the package, for example to propose a significant change. In that case, understanding branch layout and publishing a proper branch is definitely helpful. Of the two one: either we say README.source is the right place or we define a new suitable place. > The system that I describe doesn't maintain any branches that are useful > targets for git format-patch. You'll end up with a pile of merge commits > and other unuseful patches in your stack. That was what I feared ... > The best idea that I've seen for maintaining good branches for git > format-patch is to also maintain features on branches that are rebased > instead of merged against each new upstream. This duplicates the change > in two branches, one that's merged and one that's rebased, but you can use > git rerere to automate resolution of the rebase and the merge using the > results of whichever you do first. (This idea is from Manoj.) > > I'm not actually doing this in practice right now; so far, I'm just using > git diff upstream..branch to generate patches to send to upstream, which > obviously isn't ideal since it doesn't include the commit message. I see. So basically you are accepting the fact that your .diff.gz get "dirty", considering (I guess) that patches are clear enough while looking at the git repo. My opinion is that this is acceptable *only if* we standardize the place where to document branch layout, as per the problem we started from. Otherwise, a random external observer (upstream) included would have a too hard life in trying to understand what happened to some software. 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 firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss