[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Workflow with debian/ in VCS



* Enrico Weigelt <weigelt@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


Reply to: