"Brent W. Baccala" <cos...@freesoft.org> writes:
> My first question is for advice on managing my workflow. I'm using the
> Debian hurd package, which adds patches on top of a snapshot taken from
> savannah's git tree. I think I want to work on the Debian-ized code, since
> that's what's installed on my system, but that leaves me without git. It's
> just a snapshot, not an actual git repository. Any advice?
Here is what I did. It's cumbersome but at least it works.
I have a "hurd-upstream" working tree with a repository that I
cloned from the "git://git.sv.gnu.org/hurd/hurd.git". I applied
the API-relevant Debian patches as separate commits, in the same
order as in debian/patches/series:
I set an "in-debian" branch at that point, and then made my own
commits on top of them in the "master" branch. I can then build
Debian-compatible executables from these branches.
I also have a "hurd-debian" working tree. I extracted that from
the Debian source package, so that I got a .pc directory with the
correct state information. I then added a .git directory cloned
from "git://anonscm.debian.org/pkg-hurd/hurd.git", so that I can
view the history and make local commits.
When I want to make a private Debian package with my Hurd
changes, I run "git format-patch -o
DIRECTORY/hurd-debian/debian/patches/kon in-debian..master" in my
"hurd-upstream" repository, add the names of the patch files to
debian/patches/series, describe the changes in debian/changelog,
and build it with dpkg-buildpackage. This gives me proper Debian
source and binary packages. In debian/changelog, I use "local"
as the distribution and append ".kon.1" or another number to the
version. I keep my own patches in the debian/patches/kon
directory so that I can easily delete them before generating new
ones from my "hurd-upstream" repository.
The commit messages in my "hurd-upstream" repository have DEP-3
(http://dep.debian.net/deps/dep3/) "Bug", "Bug-Debian", or
"Forwarded" fields at the bottom if applicable. The "Subject"
and "From" fields are generated by git format-patch.
Those working trees and repositories are inside the virtual
machine. I also have clones of those repositories in the host in
case the file system in the VM gets corrupted, and off-site
backups of both the qcow2 disk images and the host-side
repositories. (I did not have backups of my Hurd activity
between May and July, and lost my unpublished patches when the
SSD failed.) I omit the build trees from backups though.