Using git for patch management in Fedora

Dridi Boukelmoune dridi.boukelmoune at
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 [1] (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) [2] and github even allows you to use a shortened
sha-1 [3].

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> 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.
> Rich.
> --
> Richard Jones, Virtualization Group, Red Hat
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> --
> devel mailing list
> devel at
> Fedora Code of Conduct:

More information about the devel mailing list