Re: How to handle Debian patches
Theodore Tso <tytso@mit.edu> writes:
> On Fri, May 16, 2008 at 03:25:11PM -0700, Russ Allbery wrote:
>> In fact, despite being one of the big quilt advocates in the last round
>> of this discussion, I am at this point pretty much sold on using Git
>> due to its merges and branch support and have started to switch my
>> packages over. However, the one thing discussed on this thread is
>> still the thing I don't know how to do easily in Git. I have each
>> logical change on its own branch, so I can trivially generate patches
>> to feed to upstream with git diff upstream..bug/foo, but I don't know
>> how to maintain a detailed description and status other than keeping a
>> separate file with that information somewhere independent of the
>> branch, or some special file included in the branch.
>
> How often is a logical change more than just a single commit?
> Espeically in the context of packaging, usually the changes are pretty
> trivial, and don't require multiple patches.
They often are just a single commit (although there are some exceptions),
but I often need to update the patch description to include more
information long after I originally wrote the patch. I like to note
current upstream reactions and thinking, maybe target version numbers, and
that sort of thing.
I could so that with Manoj's idea of a separate submit branch for each one
of those, since that one I'm rebasing anyway and can use git commit
--amend or something similar to change old log messages without worrying
about breaking things. That does require creating the separate submit
branches, though; I don't think (unless I'm missing something) that I
could do that with my topic branches without creating some of the same
problems as rebasing, since changing the commit message makes the commit a
different commit.
> Sure, a few bugs may require some new infrastructure, or making changes
> that would be best done with 2-3 patches, but any more than that and you
> probably want to be consulting with upstream before submit any changes
> anyway?
The patches that I carry relative to upstream frequently *are* done with
considerable consultation with upstream and are cherry-picked from
upstream, but I still want to track them and I still want upstream to know
what I've cherry-picked, and in general to be able to use the same
infrastructure I'd use for patches that weren't done in consultation with
upstream.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: