* Enrico Weigelt <weig...@metux.de> [110724 05:44]: > I really wonder, why you don't just track everything in a VCS > like git, set the Debian changes (to the source tree) ontop the > upstream release tag and simply add the control files ? > And when a new upstream release comes, simply rebase.
- Git cannot track rebasing branches. To effectively use git to share stuff you need fast-forwarding branches. - Rebasing loses history, so one wants to 'merge' the old state somehow, so the old state is part of the history (which can than also solve the previous point). - To use git as the "better quilt", i.e. to manage a transparent reviewable set of modifications not (yet) found upstream you need to rebase (especially rebase -i). - Git's rebasing does not work if the branch rebased contains older history (it wants to reapply every commit not already in the ancestors of the commit to be rebased to), so rebasing and keeping history of the same branch does not work. In Git-dpm I have the following approach to work around this incompatibilty: Each project/project branch consists of three git heads: An upstream branch, a patched branch and a debian branch. Only the debian branch needs to be public and contains everything else, especially all the history and is fast-forwardable. The upstream branch is something similar enough to the contents of the .orig.tar contents and it's commit-hash is recorded together with the name and checksum of the .orig.tar file in the debian-branch's debian/.git-dpm file to be able to do the other operations. The patched branch only exists as git head temporarily. It is not supposed to be published (except as ancestor of the debian branch and a tag for released versions), but the head is created on the fly and after something in it is changed, it is merged back into the debian branch (and the debian/patches/ directory updated from the commits it contains). This way the patches are rebased git commits, easily reviewable and always ready to be taked from upstream/sidestream, while the whole project can just be pushed/pulled around in the normal git way, the repository is after pull/clone directly dpkg-buildpackage'able and one gets a nice "3.0 (quilt)" style source package also showing the patches in the patch-tracker. (Compare for example http://patch-tracker.debian.org/package/xbuffy/3.3.bl.3.dfsg-8 with http://anonscm.debian.org/gitweb/?p=users/brlink/xbuffy.git;a=shortlog;h=refs/tags/patched-3.3.bl.3.dfsg-8 ) Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110724122104.gb10...@pcpool00.mathematik.uni-freiburg.de
