typo

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 25a2dc794441ba92b11d8759dcaf8d9322b912a7..4e64507c92834d0f5c84deb6316c690f1cb28120 100644 (file)
--- 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>