"Paul Johnson" <[EMAIL PROTECTED]> writes: > On Sat, May 31, 2008 at 9:59 PM, Russ Allbery <[EMAIL PROTECTED]> wrote:
>> At this point, I've converted most of my packages to use Git, which >> means that the source package as uploaded to Debian has one collapsed >> patch including upstream changes and you have to check out the Git >> repository to see the separate branches and how they relate to >> upstream. > You don't keep a patches subdirectory under debian? The idea of using a distributed VCS to manage the package is to use its merge capability rather than a more manual patch update process. To some extent it's an experiment, since I really do like quilt, but it's working fairly well so far. Git lets me manage branches the way that I managed patches and provides a much richer set of commands to manipulate those branches (although it requires some work to figure out which ones to use and how). >> At some point, I'm hoping to be able to generate format 3.0 packages >> from Git in some way that exposes the way that I'm actually working to >> other people working on packages. > I can't understand why you would do it this way. Seems like it would > lead to hard-to-catch coding mistakes. Using Git with feature branches for each patch is exactly equivalent to using separate patches in a debian directory. You can transform one into the other (although feature branches allow more complex merges). It's the same work flow, except you work on nodes rather than edges. It's a classic graph transform. > If there were 50 patches, some of which others contribute, there might > be a chance to figure which one blows something up. As long as the > patches are separate, there's a chance I could back-track and find the > problem. But it seems like you are saying that you apply those 50 > patches, and then make one jumbo diff including all changes. Only in the final build of the source package after everything has already been merged. The working object is 50 separate feature branches, each of which contain only one change, and which I can merge and update indepedently. The only difference is when one does the merge and what artifact of the merge one puts into the source package. Right now, the Git method is less than ideal for anyone working only on the source package, since they get the merge artifact without any of the underlying structure. 3.0 package formats will fix that; in the meantime, if they have Git, debcheckout will get the actual repository and let them work on the same thing that I'm working on. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
