On Sat, Feb 16, 2008 at 09:24:12AM +0000, martin f krafft wrote:
> > Because it's a way to high level tool for the task. Git (and
> > I suppose that the following is true for other DVCS, and if not,
> > they _REALLY_ suck, and I mean it, really) has been designed so
> > that you can only exchange patches.
>
> Many people actually tend to think of Git as a filesystem...
I do too, it's just that if you know where you come from, all you need
to rebuild the same state are the patches. Most of the kernel and git
developments are done this way. For the kernel not even every major
contributor uses git (akpm didn't last time I checked) and their
exchange format is patch series, completely bijective with quilt format.
And given their current tremendous patch integration rate, I _really_
think this format has proven its robustness, while being good enough for
git.
> > Are you sure git will be there and backward compatible in 10 years ?
> > Okay, it's likely given the current upstream, that focuses a _lot_ on
> > backward compatibility. But still. Some repository formats have been
> > deprecated (the object store is of version3 and IIRC git doesn't grok
> > version1 anymore, but I may be mistaken). That's the kind of gamble I
> > wouldn't take.
> >
> > Whereas I guess tar will always grok tarballs it generates today in 10
> > years, and gzip/bzip2/lzma/$compressor won't change either, and text is
> > text for enough time to assume it'll remain as editeable in 10 years.
>
> Fair enough, but why would e.g. version3 ever be removed? It's not
> like versioned storage formats need a whole lot more support than
> the infrastructure to identify them, which is already in place.
Well, you still don't know if upstream will become mad in the next 10
years, can you ? :) And git code isn't trivial, so I don't think you'll
be able to hack version3 back into it if it's stripped from upstream at
some point.
> > > Nice, I didn't see this before. This *is* in fact nice and puts
> > > the quilt *format* very high on my list.
> >
> > Yes, quilt preserves *everything* you put in the header, so if you use
> > git (or $scm) to generate the patches with authoring information, commit
> > message and so on, it wont be lost.
>
> Excellent.
In fact afaict, git-quiltimport is able to get authoring informations
and so on, and if it's not able to use embedded blob sha's yet, it's
probably not hard to build from there. As a matter of a fact, I'm
experimenting right now with the llvm2 packaging a way to share our
"patch branch" (with a co-maint) through debian/patches, and so far, it
doesn't work so badly. IOW, what the xorg people do for months actually,
except that I use git all over the place.
[ and to be fair we export patches through git-format-patch so there
isn't a series file, but the series file would basically built this
way: (ls -1 * 2>/dev/null || :) > series ]
> > What I ask you is just to be consistent. Either we _will_ modify
> > source packages, either we won't. If we will, adding features to it is a
> > good idea, if we won't, let's just focus on how to let it be expressive
> > enough to encode in it all what we use as new features upstream from it.
> > And as a matter of a fact, quilt is enough for that.
>
> Good arguments. Thanks!
:)
> With Extremadura coming up, who would be interested in joining
> a "workgroup" to work on this stuff? I would volunteer to chair such
> a session...
I would be very much interested, but I'm not really sure that I'd have
the time to join a session. Note that my talk at FOSDEM could be also a
place to discuss some points too on the subject (If I get the time to
write the damn slides *cough*) :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpoj6vGU6xgr.pgp
Description: PGP signature