Theodore Tso <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
