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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
