Fedora kernel git tree: each patch typically gets one line of change everyday

[Thorsten Leemhuis]

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-2014081...
https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-2014092...

CU
knurd

[Josh Boyer]

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

[Josh Boyer]

On Thu, Oct 2, 2014 at 8:34 PM, Josh Boyer <jwboyer(a)fedoraproject.org&gt; 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

[Thorsten Leemhuis]

Josh Boyer wrote on 03.10.2014 15:54:
>  On Thu, Oct 2, 2014 at 8:34 PM, Josh Boyer
> <jwboyer(a)fedoraproject.org&gt; wrote:
> > On Thu, Oct 02, 2014 at 11:32:38PM +0200, Thorsten Leemhuis wrote:
> >> Quoting http://jwboyer.livejournal.com/49254.html
>  [...]
> >> > 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