Lo!
Quoting http://jwboyer.livejournal.com/49254.html
[…] Since we're rebasing the patches in git, we don't need to do it separately in the Fedora package repo. There's no sense in doing work twice. After some initial renaming of some patches and such, I now use the git tree to generate the patches we add to the spec file by using git format-patch master.. and a script to copy them to the working dir on my machine. This means we always have a nice fresh copy of the patches for that specific upstream base. It does mean that each patch typically gets one line of change (the sha hash of the commit) everyday, but I don't think that's a big deal. This actually saves me time now and it helps keep our patches fairly "clean". They all apply with git-am and most of them have changelogs and such.
I'm all for making your life easier ;-) But is there maybe some easy way to avoid that "one line of change" per patch? Maybe some sed-call that removes or modifies the commit id sha1sum when the patches get readded to the package repo? It would avoid clutter in the git history and commits diffs. I'd welcome that, because I keep a eye on the kernel changes via the scm-commits mailing list. And it got a lot harder now to see what actually changed. See yourself by comparing these two mails:
https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20140811/1... https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20140922/1...
CU knurd
On Thu, Oct 02, 2014 at 11:32:38PM +0200, Thorsten Leemhuis wrote:
Lo!
Quoting http://jwboyer.livejournal.com/49254.html
[…] Since we're rebasing the patches in git, we don't need to do it separately in the Fedora package repo. There's no sense in doing work twice. After some initial renaming of some patches and such, I now use the git tree to generate the patches we add to the spec file by using git format-patch master.. and a script to copy them to the working dir on my machine. This means we always have a nice fresh copy of the patches for that specific upstream base. It does mean that each patch typically gets one line of change (the sha hash of the commit) everyday, but I don't think that's a big deal. This actually saves me time now and it helps keep our patches fairly "clean". They all apply with git-am and most of them have changelogs and such.
I'm all for making your life easier ;-) But is there maybe some easy way to avoid that "one line of change" per patch? Maybe some sed-call that removes or modifies the commit id sha1sum when the patches get readded to the package repo? It would avoid clutter in the git history and commits diffs. I'd welcome that, because I keep a eye on the kernel changes via the scm-commits mailing list. And it got a lot harder now to see what actually changed. See yourself by comparing these two mails:
OK. That's a reasonable request. I'll see what I can do.
josh
On Thu, Oct 2, 2014 at 8:34 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Oct 02, 2014 at 11:32:38PM +0200, Thorsten Leemhuis wrote:
Lo!
Quoting http://jwboyer.livejournal.com/49254.html
[...] Since we're rebasing the patches in git, we don't need to do it separately in the Fedora package repo. There's no sense in doing work twice. After some initial renaming of some patches and such, I now use the git tree to generate the patches we add to the spec file by using git format-patch master.. and a script to copy them to the working dir on my machine. This means we always have a nice fresh copy of the patches for that specific upstream base. It does mean that each patch typically gets one line of change (the sha hash of the commit) everyday, but I don't think that's a big deal. This actually saves me time now and it helps keep our patches fairly "clean". They all apply with git-am and most of them have changelogs and such.
I'm all for making your life easier ;-) But is there maybe some easy way to avoid that "one line of change" per patch? Maybe some sed-call that removes or modifies the commit id sha1sum when the patches get readded to the package repo? It would avoid clutter in the git history and commits diffs. I'd welcome that, because I keep a eye on the kernel changes via the scm-commits mailing list. And it got a lot harder now to see what actually changed. See yourself by comparing these two mails:
OK. That's a reasonable request. I'll see what I can do.
Starting with the changes after today's push, you shouldn't see this issue any longer.
josh
Josh Boyer wrote on 03.10.2014 15:54:
On Thu, Oct 2, 2014 at 8:34 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Thu, Oct 02, 2014 at 11:32:38PM +0200, Thorsten Leemhuis wrote:
[...]
working dir on my machine. This means we always have a nice fresh copy of the patches for that specific upstream base. It does mean that each patch typically gets one line of change (the sha hash of the commit) everyday, but I don't think that's a big deal. This
[...]
I'm all for making your life easier ;-) But is there maybe some easy way to avoid that "one line of change" per patch? Maybe some sed-call that
[...]
OK. That's a reasonable request. I'll see what I can do.
Starting with the changes after today's push, you shouldn't see this issue any longer.
Many thx, seems to work!
CU knurd
kernel@lists.fedoraproject.org
-
Josh Boyer -
Thorsten Leemhuis