Rémi Vanicat a écrit :
When using rebase, one lose the history of the patch. One important role of our VCS is to save this history, so i prefer to not use rebase like that.
I beg to differ. Could you elaborate on this? IMHO, using rebase is the cleanest way I've seen so far to maintain patches and their history, in the sense that upstream could just import directly these patches (with their history) into their repos.
Another reason to not use rebase, is that in a shared repository rebasing make cooperation and synchronization more difficult than it have to be.
More than using dpatch/quilt independently of the VCS?
I really hope the solution we use will not only give us the patch we have, but also the history of those patch.
I realized writing this mail that one could be interested into two kinds of history: the "true" history of development, and the "intended" patch series, I mean the patch series where each patch introduces one feature that is not tampered with afterwards. In other words, the history you can afford when you are an upstream developer, and the history you can afford when you just maintain patches, with no upstream influence. An upstream developer is more likely to accept a patch series in the second form than in the first. For Debian packaging, I think we are interested in the second. What do you think?
Cheers, -- Stéphane