Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Chris Knadle <Chris.Knadle@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]
Reply to: