On Tue, Sep 13, 2016 at 4:05 PM, Eric Anholt <[email protected]> wrote: > Ilia Mirkin <[email protected]> writes: > >> On Mon, Sep 12, 2016 at 11:55 AM, Emil Velikov <[email protected]> >> wrote: >>> On 12 September 2016 at 15:35, Ilia Mirkin <[email protected]> wrote: >>>> On Mon, Sep 12, 2016 at 10:10 AM, Emil Velikov <[email protected]> >>>> wrote: >>>>> Keeping diff/patches in git always felt like a hack, imho. Plus >>>>> most/all(?) distros rely on the Mesa headers, so I'm not sure how that >>>>> is going to work. >>>> >>>> The alternatives are considerably more painful for just a handful of >>>> files with a small number of diffs. This would be as a tool for >>>> developers like us who update the mesa versions by importing new KHR >>>> versions, which will not have our local changes applied. The patch >>>> would not be used as part of the build process or anything else. >>>> >>> The goal being to have the patches alongside the patched headers. >>> This way one can use them as reference ? Sure sounds great imho. >> >> Exactly. So that when I download new KHR headers, I just apply the >> patch to them (and hope it applies), and if not, look at what was >> being done and try to repeat the process. Then I regenerate the patch >> against the (new) originals and check the whole thing in. > > Or you could just use git like normal: You have a public branch of the > unchanged headers. You make your own changes to the headers on master. > When you want to update to new upstream headers, you check out the > unchanged-headers branch, commit new unchanged upstreams there, check > out master, and git merge.
Right. Seems hardly worth the hassle for a small handful of diffs on files we update once every 2 years. -ilia _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
