Using git for patch management in Fedora
dridi.boukelmoune at gmail.com
Wed Nov 20 10:36:24 UTC 2013
For github-hosted upstreams, you can suffix some URLs with '.diff' or
'.patch'. I have used it for vcsh  (which btw is a tool I'd
recommend to anyone who keeps dotfiles in sync on several machines). I
did that on a pull request, but you can also do that on a commit (for
cherry-picking)  and github even allows you to use a shortened
Of course this doesn't prevent you from putting the patch files in the
package's repository, which seems to be the main issue. But one could
write a script to fetch such patches at %prep time.
On Wed, Nov 20, 2013 at 10:19 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
> On Tue, Nov 19, 2013 at 03:36:54PM -0800, Toshio Kuratomi wrote:
>> One note though, I think that in the past one of the discussion points we've
>> foundered on is whether we want to be mirroring upstream's git repo or
>> (approximately) upstream's releases. I think that's probably where we'd
>> need to start discussion.
> From the point of view of patch management, I have a strong view here:
> We should be mirroring upstream's git, if they have one.
> The reason is that it makes it trivial to cherry pick upstream patches
> on top of the Fedora branch.
> So I'd arrange it by having a straight mirror of upstream, then have
> our own 'fNN-branch' branches which contain the upstream releases
> (ideally from upstream tags if they are using git sensibly) + our
> cherry picked patches.
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> devel mailing list
> devel at lists.fedoraproject.org
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
More information about the devel