On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote: > On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote: > > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: > > > No, I hereby start saying good by to 3.0 > > > > I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also > > found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last > > few packages. > > I can't see any reason to use 1.0 anymore, ever. > > It is true that 3.0 (quilt) does have a great downside, quilt, but it also > has a number of upsides. And working around quilt is simple: > > echo "single-debian-patch" >debian/source/options > echo "/.pc" >>.gitignore > echo "/debian/patches" >>.gitignore I'm confused concerning the above; the point of a VCS in this context is to track changes to the source package, and the patches are themselves important changes to the source package. If you have Git ignore the patches then Git doesn't have a complete view of the source package anymore. Why would you want to do that? > and perhaps "rm -rf .pc debian/patches" in the clean target if those bother > you -- and you have all the goodies that come with the 3.0 format, with > getting none of quilt brain damage onto you. Suddenly, nothing conflicts > with the VCS you're using, nothing breaks bisects, nothing causes spurious > recompiles, etc. > > Except for nuking upstream debian/ dir which can mean a bit of lost work if > the upstream is sane (and can save some if they're not), the 3.0 format is > strictly better than 1.0. If debian/ is nuked then so is debian/patches, and if Git has been told to ignore debian/patches then it cannot bring those files back. Patching the source can be an effort especially concerning documenting why the patches were done and the source of the patches, so these seem like they'd be important to track rather than something to ignore. -- Chris -- Chris Knadle Chris.Knadle@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74
Description: This is a digitally signed message part.