Re: How to cope with patches sanely
- To: email@example.com
- Subject: Re: How to cope with patches sanely
- From: Daniel Leidert <firstname.lastname@example.org>
- Date: Fri, 01 Feb 2008 13:33:22 +0100
- Message-id: <[🔎] 1201869202.7335.18.camel@localhost>
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org> <20080131110325.GD2967@kunpuu.plessy.org> <email@example.com> <1201789277.6996.67.camel@localhost> <firstname.lastname@example.org>
Am Freitag, den 01.02.2008, 08:25 +1100 schrieb Ben Finney:
> Daniel Leidert <email@example.com> writes:
> > And people should check the VCS history just to get the current
> > "patch"?
> What is "the current patch"?
The current specific/logical patch for one issue.
> If you mean the entire set of differences
> against the upstream source, I already addressed that: simply generate
> a diff between the branches containing upstream source versus
> debian-packaged source.
I did not refer to generate the .diff.gz. I know, this can easily be
done by diff-ing two branches.
What I mean is: Say you have addressed 5 different issues in the code. I
still think it is easier to understand, if 5 separate patches are
provided instead of one. And tracking each of them be checking commits
for the initial fix and changes done later to update the fix is IMHO not
as easy as simply providing a separate patch. As long as you maintain
the package alone, you probably do not have advantages of using separate
patches. But say e.g. a co-maintainer offers help or you do
collaborative maintenance in general. Then I think, it is much easier to
separate fixes into logical patches. And IMHO this cannot be done by
just using "good" commit messages.
> As I pointed out, there are already tools that generate an entire
> Debian source package, including 'foo.orig.tar.gz' and 'foo.diff.gz',
> in a single step from a given VCS. Evidently what you ask for is
> possible, and already indeed implemented such that it is easy.
What I ask for is already possible and implemented: quilt and dpatch
exist. But I cannot agree to your opinion, that "[..] commits [..] at
the same level of granularity (or finer) [..]" offer the same
functionality and advantages. This is IMO not a valuable replacement for
separated patches, because of the reasons I tried to point out in my
I read your answer to Raphael, where you point to so called "feature
branches". This leads to the question, if people should be forced to use
a special VCS (which is already discussed somewhere else in the thread),
whereas creating Debian packages never relayed on the usage of a VCS.
To be honest, your workflow is different to mine. I would need to
examine your way and compare it to mine. All I can say is, that I'm
pretty satisfied with my workflow and I'm sure, you claim the same for
> If you mean something else by "the current patch", please explain