On Sun, 07 Feb 2010, Vincent Bernat wrote: > While git allows to keep track of modifications, it is difficult for > upstream (or some other people) to review a precise patch. Or maybe you > rebase master branch on the upstream one (which would be great to see > watch patches are applying to upstream but will lead to difficulties > when tracking master branch)?
Well, a non-native Debian package would need to use a git workflow that is optimized for downstream maintenance. And that does mean rebases. One should never confuse the optimal *upstream* git workflow, with downstream workflows. Anything that goes "never rebase" is solely for pure upstream use. Downstream, you "fork" from upstream each release, either by merging topic branches (_rebasing_ them if any sort of conflict happens, all merge commits must be perfectly clean ones), or rebasing the debian changes on top of the new upstream and calling that the new 'master' branch. This doesn't mean a lot of branches. You just need "master", and to tag every release so that you can get it back (and even make it a permanent or temporary branch) at any time. And you shouldn't have a mess of a history, either. All patches cleaned up. If this doesn't suit your style of developent, you should have a work repo somewhere, and keep the package repo separate and clean. There are different ways of doing the above, of course. The important details are exactly what you pointed at: it needs to result in clean commits that are easy to locate, and that apply cleanly to the upstream version matching the package's (and not to some past upstream version). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
