GNU bug report logs -
#76594
[PATCH 0/3] some quilt things
Previous Next
Full log
View this message in rfc822 format
Hi,
Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
[...]
>> I still think we should document some way of creating the patches
>> just so we have a canonical way of doing it (even if we don't require
>> strict adherence).
That's just one flow; what I personally do, for example is checkout the
project sources (typically, via git) at the correct release, and apply
the patch with 'git apply' or 'patch -p1 < the-change.patch', fix it up
if it only partially applied. Then I have a revised patch in git that I
can forward to upstream if it's upstream integration is pursued, and
it's easier for the next time I need to do that again. It's also
possible to work from a failed build by copying the current file to a
new file and using diff between both, though I'd say that's a bit more
error prone and less maintainable in the long term.
>> Personally, I think we should use `git format-patch` as that's what
>> contributors would be used to using.
> I prefer quilt for sources that aren't backed by git, in particular
> everything fetched with url-fetch. But we do import patches from Git
> too, so `git format-patch` should be used where it's useful.
Maybe something that could be worth documenting is that typically we
produces just diffs (with 'git diff' for example) without the git
authorship metadata for our custom patches, as that can be misleading
and/or a pain to maintain across later reworks.
The exceptions to the above are when using an unreleased upstream git
commit directly, where it makes sense to preserve all metadata, or when
authoring a commit from your own work and forwarding it to upstream.
--
Thanks,
Maxim
This bug report was last modified 62 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.