Re: patch management with git
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
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?