threads / discuss / 9460

git and linux kernel source

Subject: git and linux kernel source

## tl;dr

6 messages between Aug 9, 2007 and Aug 13, 2007.

replies: 5people: 3as markdown or json

Joe Perches· Aug 9, 2007, 23:11 UTC · lore

A few linux kernel source and git questions:

What's the best procedure to handle a tree-wide source tranformation? For instance:

  git branch foo2bar
  egrep -r -w --include=*.[ch] -l "foo" * | \
	xargs perl -pi -e 's/\bfoo\b/bar/msg'
  git commit -a -m "use bar not foo"

Is there a way to separate the resultant single patch into multiple patches by subdirectory? Perhaps some git-rev-parse option?

  git-format-patch -p --stat -o outputdir

Is there a way to automatically include the appropriate MAINTAINER and mailing lists from the MAINTAINERS file for each subdirectory?

  git-send-mail --to $APPROPRIATE_MAINTAINER \
	-cc linux-kernel@vger.kernel.org

Any ideas or help?

J. Bruce Fields· Aug 9, 2007, 23:17 UTC · re: Joe Perches · lore

Re: git and linux kernel source

On Thu, Aug 09, 2007 at 04:11:46PM -0700, Joe Perches wrote:

Show 9 quoted lines

> A few linux kernel source and git questions:
> 
> What's the best procedure to handle a tree-wide source tranformation?
> For instance:
> 
>   git branch foo2bar
>   egrep -r -w --include=*.[ch] -l "foo" * | \
> 	xargs perl -pi -e 's/\bfoo\b/bar/msg'
>   git commit -a -m "use bar not foo"

> Is there a way to separate the resultant single patch into multiple
> patches by subdirectory?  Perhaps some git-rev-parse option?

Something like

	for each sub/dir:
		git add sub/dir
		git commit -m "use bar not foo in sub/dir"

should do it. (Of course, in the particular case above the patches you ended up with probably wouldn't compile individually.)

--b.

Joe Perches· Aug 10, 2007, 01:59 UTC · re: J. Bruce Fields · lore

Re: git and linux kernel source

On Thu, 2007-08-09 at 19:17 -0400, J. Bruce Fields wrote:

Show 8 quoted lines

> > Is there a way to separate the resultant single patch into multiple
> > patches by subdirectory?  Perhaps some git-rev-parse option?
> Something like
> 	for each sub/dir:
> 		git add sub/dir
> 		git commit -m "use bar not foo in sub/dir"
> should do it.  (Of course, in the particular case above the patches you
> ended up with probably wouldn't compile individually.)

Nor would it likely survive a git bisect, but it's a start. My goal is to eventually commit by maintainer.

Thanks, Joe

J. Bruce Fields· Aug 13, 2007, 15:27 UTC · re: J. Bruce Fields · lore

Re: git and linux kernel source

On Thu, Aug 09, 2007 at 07:17:18PM -0400, bfields wrote:

Show 23 quoted lines

> On Thu, Aug 09, 2007 at 04:11:46PM -0700, Joe Perches wrote:
> > A few linux kernel source and git questions:
> > 
> > What's the best procedure to handle a tree-wide source tranformation?
> > For instance:
> > 
> >   git branch foo2bar
> >   egrep -r -w --include=*.[ch] -l "foo" * | \
> > 	xargs perl -pi -e 's/\bfoo\b/bar/msg'
> >   git commit -a -m "use bar not foo"
> 
> 
> > Is there a way to separate the resultant single patch into multiple
> > patches by subdirectory?  Perhaps some git-rev-parse option?
> 
> Something like
> 
> 	for each sub/dir:
> 		git add sub/dir
> 		git commit -m "use bar not foo in sub/dir"
> 
> should do it.  (Of course, in the particular case above the patches you
> ended up with probably wouldn't compile individually.)

OK, now I feel like I have to ask--you're not seriously considering doing anything like that, are you?

--b.

Rogan Dawes· Aug 13, 2007, 15:32 UTC · re: J. Bruce Fields · lore

Re: git and linux kernel source

J. Bruce Fields wrote:

Show 27 quoted lines

> On Thu, Aug 09, 2007 at 07:17:18PM -0400, bfields wrote:
>> On Thu, Aug 09, 2007 at 04:11:46PM -0700, Joe Perches wrote:
>>> A few linux kernel source and git questions:
>>>
>>> What's the best procedure to handle a tree-wide source tranformation?
>>> For instance:
>>>
>>>   git branch foo2bar
>>>   egrep -r -w --include=*.[ch] -l "foo" * | \
>>> 	xargs perl -pi -e 's/\bfoo\b/bar/msg'
>>>   git commit -a -m "use bar not foo"
>>
>>> Is there a way to separate the resultant single patch into multiple
>>> patches by subdirectory?  Perhaps some git-rev-parse option?
>> Something like
>>
>> 	for each sub/dir:
>> 		git add sub/dir
>> 		git commit -m "use bar not foo in sub/dir"
>>
>> should do it.  (Of course, in the particular case above the patches you
>> ended up with probably wouldn't compile individually.)
> 
> OK, now I feel like I have to ask--you're not seriously considering
> doing anything like that, are you?
> 
> --b.

Have you seen LKML recently? Maybe that will answer your question. (A 500+ patch mail bomb . . .)

Rogan

J. Bruce Fields· Aug 13, 2007, 15:38 UTC · re: Rogan Dawes · lore

Re: git and linux kernel source

On Mon, Aug 13, 2007 at 05:32:42PM +0200, Rogan Dawes wrote:

Show 29 quoted lines

> J. Bruce Fields wrote:
>> On Thu, Aug 09, 2007 at 07:17:18PM -0400, bfields wrote:
>>> On Thu, Aug 09, 2007 at 04:11:46PM -0700, Joe Perches wrote:
>>>> A few linux kernel source and git questions:
>>>>
>>>> What's the best procedure to handle a tree-wide source tranformation?
>>>> For instance:
>>>>
>>>>   git branch foo2bar
>>>>   egrep -r -w --include=*.[ch] -l "foo" * | \
>>>> 	xargs perl -pi -e 's/\bfoo\b/bar/msg'
>>>>   git commit -a -m "use bar not foo"
>>>
>>>> Is there a way to separate the resultant single patch into multiple
>>>> patches by subdirectory?  Perhaps some git-rev-parse option?
>>> Something like
>>>
>>> 	for each sub/dir:
>>> 		git add sub/dir
>>> 		git commit -m "use bar not foo in sub/dir"
>>>
>>> should do it.  (Of course, in the particular case above the patches you
>>> ended up with probably wouldn't compile individually.)
>> OK, now I feel like I have to ask--you're not seriously considering
>> doing anything like that, are you?
>> --b.
>
> Have you seen LKML recently? Maybe that will answer your question. (A 500+ 
> patch mail bomb . . .)

Yes. And it looks like preparation for doing the above kind of splitting-by-maintainer. Which may not be a sensible thing to do for a variety of reasons that I assume people know. But the patch bomb suggests I shouldn't make that kind of assumption.

--b.