On Sun, 2017-12-31 at 18:13 -0800, Laura Abbott wrote: > On 12/30/2017 04:52 AM, Paul Bolle wrote: > > 2) Would it make sense to further gitify the specfile and move from patch to > > "git apply" here (and a few other places)? Or should we expect patch to do the > > right thing? (In the latter case I guess I might have to report a bug against > > patch.) > > > > We've generally been expecting patch to do the right thing and it's > worked so far. A few web searches helped me remember something comparable: https://lkml.org/lkml/2015/1/26/692 . What I did remember without hitting the web was that "git apply" is meant to be a drop in replacement for patch (for the patches "git diff" creates, that is). Since we are only using patches created by git nowadays, aren't we, we might as well use "git apply" for them. > I'm not opposed to gitifying more parts of the spec > file but do you have a particular reason for doing so? Preventing problems like this (and the one from 2015). Another thing is that I noticed that the git repository we create during rpmbuild doesn't properly track all changes. In this case we do not "git add" new files. That is why I changed git commit -a -m "..." to git add -A git commit -m "..." I also noticed that the removal of .gitignore files isn't tracked. And it's a bit annoying to have the removal of those files show up in "git status". "git status" was one of the things I did when pinpointing this issue. Of course these are just small things, but they do make pinpointing stuff like this a bit more annoying than it should be. > It seemed like when Josh made the original change for git he had a few things > in mind. A bit off topic: I suppose at the ultimate goal is to do rpmbuild from within a proper git clone of the kernel repository. Ie, using a branch with Fedora's patches, a specfile, and whatever else we need. Perhaps further gitifying the current specfile helps to reach that goal. Not sure, though. Thanks, Paul Bolle _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
