Re: git and quilt
On Wed, Feb 03, 2010 at 04:25:40PM -0600, Matt Zagrabelny wrote:
> I am using git with no debian/patches (quilt/dpatch) to manage the cdpr
> package.
I am doing the same, for the very simple reason that every other
approach I've seen violates the KISS (Keep It Simple, Stupid)
principle.
My Debian patches have two branches: master and upstream (some also
have a pristine-tar branch, but that is beside the point here.) I use
git-import-orig to load upstream, git merge to merge it into master,
and git-buildpackage to build my .debs.
It is easy, it is clean, and it works well. And it works like Git is
supposed to work.
I am not a fan of git-rebase due in part to the difficulty of working
with others, but also in part due to the difficulty of tracking how
your differences from upstream change over time. All the
debian/patches systems I have seen suffer from both of these flaws.
Consider, for instance, a git system in which debian/patches/* is
committed into git. OK, that's fine as it goes. The history of how
you "fixed upstream's frob from going all fubar" is in Git. But how
accessible is it? git blame frob.c is useless now, as the diff to
frob.c isn't in git. There is, in fact, no easy way to find out just
when a given change to frob.c was introduced or why (especially if
multiple debian/patches/* modified frob.c).
A git rebase workflow is slightly better on this, but only slightly.
For some non-Debian packages where I maintain a large number of diffs
against upstream, I use feature branches. Each feature branch can run
git merge upstream, and then the master branch merges all the FBs in.
(A couple of shell scripts automate this easily.)
Frankly I do see the utility of debian/patches for people that don't
use a VCS. But if your VCS already has very strong history analysis
features, which Git does, I see it as an unnecessary complication.
If someone reading this isn't familiar with Git's history features, I
would suggest you read manpages about:
git log --pickaxe or -S (details in gitdiffcore(7)
git blame (one of my very favorite git commands)
git diff -M -C --find-copies-harder
(git can be very intelligent about detecting copies and renames,
more than a debian/patch can reflect)
(these options also work for many other commands)
It all comes down to this: if I avoid debian/patches in my Git
packages, I get:
* A very simple and very fast workflow for routine maintenance
* Powerful history searching for when I need it
* An easily-accessible history of my changes to upstream, and
how they relate to upstream's changes. (How my diffs change over
time)
Looking at a diff of a diff is never easy or powerful, in my
experience. It is more of a bang your head on the keyboard sort of
experience.
-- John
Reply to: