Chris Knadle <chris.kna...@coredump.us> writes: > 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?
Git does have a complete view. What the above does, is tell dpkg-source to fold any changes made to the upstream sources into a single patch. Since the git tree already has the patches applied (with upstream sources on a different branch, most probably), it has a full view. This basically folds whatever patches the git tree has over upstream, outside of debian/ into a single file. That's about it. Since that file is generated, it has no business staying in git. >> 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. You're misreading this. "Nuking upstream debian/" means ignoring any debian/ directory upstream may have had. That is generally a Good Thing(tm), as we want to have our own packaging. The original is still available in both the upstream tarball, and the upstream branch. debian/patches in this case is irrelevant, as that is automatically generated by diffing the upstream tree against the current (git) tree and folding it into a single patch file. > 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. The reasons can - and should be - documented in git. Granted, that does not transfer to the debianized source package, which is unfortunate, but it's still better than fighting with integrating quilt with a VCS (in which case, everyone with a higher number of patches would go back to 1.0 and custom patching systems and ignore every other benefit of 3.0, because quilt and VCS generally don't play nice together). -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871umioo6l.fsf@algernon.balabit
