Manoj Srivastava wrote: > Only if you like working with patch series, and prefer to lose > all the information that the original VCS contained. I prefer to see > the whole history, not just a snapshot, when I am joining a development > effort.
I agree. > >> I find it quite unenviable to adopt a package >> for which the source package is just one giant .diff.gz, because it >> means either learning potentially elaborate tools to extract the >> individual patches, or manual splitting... For this, the new source >> format based on quilt seems just great. > > This is a strawman, really. [...] You really think so? Just to be curious, imagine I am working with a workflow of my own, and a VCS of my own (I mean, something you don't already know... does that exist? :). I am maintaining several packages you are interested in, and I (and nobody else) don't want anymore. For some reason (e.g. an accident), I cannot help you either. Will you really learn my VCS and understand my workflow to get the history? If yes, just say so, and the discussion will be closed for me. If no, would you have preferred that I had made releases with giant .diff.gz touching upstream files, or rather with patch series? > [...] The options are not the giant big > diff vs quilt (equally horrible, IMHO). The options are 3.0 (quilt) vs > 3.0 (git). I would have gone for the 3.0 (git) format myself, except > that it does not support submodules. IMHO, git is far too complex to be a source format (meaning: forcing everyone to have to deal with). Besides, the raw format is too complex to deal with using simple shell scripts (not using git). On the contrary, the quilt format just needs tar and patch. This seems more suitable for something which is meant to last forever. > The quilt format is the least preferred, for me, since it loses > all the history. Given that, I am not going to go out of my way to > support it. If topgit makes it simple, perhaps. It loses history, sure. But (hopefully) not the semantics of patches. Moreover, the patches can be documented themselves. Do you do long-standing development on your patches? Quoting another mail from you: > Not really. All my upstream like to have a single topic patches > series rebased to their latest release -- and very few of them are > using modern VCS's yet. So, yes, it is fed back upstream, but not > directly into the upstream VCS where I have no commit rights anyway. > > The patches are submitted by whatever mechanism the upstream > wants them to be submitted. At least, if you are able to do this, this is kind of fine. -- Stéphane
Description: OpenPGP digital signature
_______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss