From c27110131fe19908dd95ed99705ce8094138d67c Mon Sep 17 00:00:00 2001
From: cjwatson <>
Date: Fri, 26 Mar 2010 01:00:06 +0000
Subject: [PATCH] typo

---
 debian/2010-03-25-thoughts-on-3.0-quilt-format.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/2010-03-25-thoughts-on-3.0-quilt-format.txt b/debian/2010-03-25-thoughts-on-3.0-quilt-format.txt
index 25a2dc79..4e64507c 100644
--- a/debian/2010-03-25-thoughts-on-3.0-quilt-format.txt
+++ b/debian/2010-03-25-thoughts-on-3.0-quilt-format.txt
@@ -20,7 +20,7 @@ Thoughts on 3.0 (quilt) format
 <p>Bad things:</p>
 
 <ul>
- <li>It's a bit awkward to set things up when checking out from revision control; I didn't really want to check in the <code>.pc</code> directory, and the tree checks out in the patched state (as it should), so I needed some way for developers to get quilt working easily after a checkout.  This is sort of the reverse of the previous problem, where users had to do something special after <code>dpkg-source -x</code>, and I consider it less serious so I'm willing to put up with it.  I ended up <a href="http://bugs.debian.org/572204">a rune in debian/rules that ought to live somewhere more common</a>.</li>
+ <li>It's a bit awkward to set things up when checking out from revision control; I didn't really want to check in the <code>.pc</code> directory, and the tree checks out in the patched state (as it should), so I needed some way for developers to get quilt working easily after a checkout.  This is sort of the reverse of the previous problem, where users had to do something special after <code>dpkg-source -x</code>, and I consider it less serious so I'm willing to put up with it.  I ended up with <a href="http://bugs.debian.org/572204">a rune in debian/rules that ought to live somewhere more common</a>.</li>
  <li>Everything ends up represented twice in revision control: the patch files, plus the changes to the patched files themselves.  I'm OK with this although it is a little inelegant.</li>
  <li>Although I haven't had to do it yet, I expect that merging new upstream releases will be a bit harder.  bzr will deal with resolving conflicts in the patched files themselves, and that's why I use a revision control system after all, but then I'll have to go and refresh all the patches and will probably end up doing some of the same conflict resolution a second time.  I think the best answer right now is to <code>quilt pop -a</code>, force a merge despite the modified working tree, and then <code>quilt push && quilt refresh -pab</code> until I get back to the top of the stack, modulo slight fiddliness when a patch disappears entirely; thus effectively using quilt's conflict resolution rather than bzr's.  I suppose this will serve as additional incentive to reduce my patch count.  I know that people have been working on making this work nicely with topgit, although I'm certainly not going to put up with the rest of git due to that; I'm happy to wait for looms to become usable and integrated. :-)</li>
  <li>It would be nice if there were some standard DEP-3 way to note that a patch has been accepted or rejected upstream, beyond just putting it in the description.  In particular, it seems to me that listing patches accepted upstream could be used to speed up the process of merging new upstream releases.</li>
-- 
2.30.2