Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Adam Borowski <kilobyte@angband.pl> writes:
> On Fri, May 18, 2012 at 09:24:04AM +0200, Bernd Zeimetz wrote:
>> On 05/17/2012 04:52 PM, Gergely Nagy wrote:
>> >> 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.
>>
>> Doing that is the most stupid idea ever. All it does is to ensure that you
>> package can't be NMUed sanely and that people who need to work with the sources
I have to say you are saddly mistaken there. Just because you use a
single patch under debian/patches and do not track it in git in no way
prevents the debian source package to work as expected. Everybody can
download the source package, build it, NMU it, whatever.
All he is saying is that when building from git all upstream changes not
covered by existing patches shall go into debian/patches/debian-changes
(instead of debian/patches/debian-changes-version) and not to track this
automatically generated file in git. Which is totaly sane.
>> and your patches for whatever reason have to clone your git, which might be not
>> available or just too large for them to download - so at the end changes are
>> high that they end up with a largish unreadable patch, similar to the mess we
>> get from Ubuntu sometimes.
>> The only thing that makes sense would be to use git-format-patch to export your
>> patches to debian/patches and list them in the series file. Or use gbp-pq, which
>> was made exactly for that.
>
> Uhm, please switch around "git" and "quilt", and say that again.
Uhm, no. That is besides the point.
> Quilt is a kind of really primitive VCS. It does not make sense to use both
> it and a modern one, and when someone tries, this ends up with no end of
> woe. Quilt sprinkles its modifications around the source, breaks timestamps
> causing unnecessary rebuilds, breaks basic VCS abilities like bisection,
> makes it really hard to even review history, and so on.
>
> You complain about forcing people to use git, while you push quilt onto
> everyone else. And while git can do every single thing quilt can do, the
> reverse is thoroughly untrue.
>
> I really wish there was a "3.0" format besides "3.0 (quilt)", so people are
> not mislead into thinking they have to (or even, would gain anything) from
> writing patches in quilt's format.
And you too are totaly missing the point of the exercise. The point of
the described setup was so that people do not have to write patches in
quilt's format.
The described setup gives you a 3.0 (quilt) format where quilt plays no
part in your workflow and thus does not interfere with the VCS. The
resulting source package that gets uploaded will use quilt but you as
VCS user don't have to care about it.
All the benefits of the 3.0 format without the (imho mostly imagined)
quilt problems.
MfG
Goswin
Reply to: