Dan Williams wrote:
On Sat, 2008-07-12 at 17:49 -0700, Arjan van de Ven wrote:
On Sat, 12 Jul 2008 20:10:51 -0400
Presumably one could replicate this as needed. However, there is the
question of whether or not it's needed. Remember that the concept
using an upstream tarball as the canonical source version that we
represent to the world that we are using is nothing more than a
policy decision. Nothing in the GPL or anything else said we had to
do that, it was just what we *chose* to do (long, long ago, in a
galaxy far, far away).
one thing to keep in mind... as comparison, what you don't want is what
Ubuntu is doing with their kernel (clone Linus and then just edit the
source tree); it's just one big nightmare (as you can imagine). Keeping
upstream source and local patches separate is a clear winner (anyone
who has worked on the alternative will agree with me).
If those upstream sources are a tarbal, or a tagged commit... is a lot
less relevant.
Yeah, there is actually a benefit to tarball+patches approach we take
right now; and that benefit is that it's extremely easy to see just what
we've done to the upstream package,
Easier than, oh, say "git log -p --reverse fedora..upstream" ?
and it's usually really easy to
extract those changes and push them upstream. You don't want a
mega-diff that includes 20 specific patches.
Who's talking about mega-diffs? You can get each diff individually with
any sane scm (and with quite a few of the insane ones as well).
One problem working directly on exploded source trees is that you as a
developer have to be much more disciplined to make small, targeted
commits that are easily able to go upstream, otherwise you do end up
with a huge diffmess that you simply can't upstream easily.
That's really no difference at all to what needs to be done now. Each
patch has to be kept and generated separately. Using a tool for it only
means you have a much easier way of moving that patch-set around and
automagically finding already applied patches.
And that's where we should always be working: upstream.
So work with the tools they have then. I manage a few projects in git,
and I'd much prefer to get patches sent to me via the git tools than
someone using diff on two exploded source-trees. I'd *love* to get
pull-requests, since I won't have to bring any sourcecode or patch
outside the scm at all that way.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
