Hi Sam,
Okay, I think what you proposed works out for me, although adding 20+ files, one by one, is a pain.
I wish there is a way to automate this.
FWIW, this is how I did it.
________
1) Create a new branch from the current one just for sending the patches
$ git branch Code_Review_1
2) Switch to the new branch
$ git checkout Code_Review_1
3) Copy original drivers/gpu/drm/via/ contents (i.e., *.c, *.h, Kconfig, and Makefile) and include/uapi/drm/via_drm.h
4) Delete drivers/gpu/drm/via/ contents and include/uapi/drm/via_drm.h
5) Delete from DRM core make file (Makefile) located at drivers/gpu/drm/ its OpenChrome DRM build switch
. . .
obj-$(CONFIG_DRM_OPENCHROME) +=via/
. . .
6) Commit the change (Note: this commit will not be posted as a patch)
$ git commit -as
7) Move back the preserved files to drivers/gpu/drm/via/ (i.e., *.c, *.h, Kconfig, Makefile) and include/uapi/drm/ (i.e., via_drm.h)
8) Add and commit *.h located at drivers/gpu/drm/via/ one file at a time
$ git add drivers/gpu/drm/via/("Name of the file").h
$ git commit -as
9) Add and commit *.c located at drivers/gpu/drm/via/ one file at a time
$ git add drivers/gpu/drm/via/("Name of the file").c
$ git commit -as
10) Add and commit via_drm.h located at include/uapi/drm/
$ git add include/uapi/drm/via_drm.h
$ git commit -as
11) Commit Kconfig located at drivers/gpu/drm/via/
$ git add drivers/gpu/drm/via/Kconfig
$ git commit -as
12) Commit Makefile located at drivers/gpu/drm/via/
$ git add drivers/gpu/drm/via/Makefile
$ git commit -as
13) Add back to DRM core make file (Makefile) located at drivers/gpu/drm/ the OpenChrome DRM build switch
. . .
obj-$(CONFIG_DRM_OPENCHROME) +=via/
. . .
14) Commit the change
$ git commit -as
15) Generate the commits as patches
$ git format-patch -28
The (-28) may be adjusted to match the number of relevant commits.
It is basically derived from,
- 26 files under drivers/gpu/drm/via/
- 1 file under include/uapi/drm/
- 1 commit to change Makefile located at drivers/gpu/drm/
The first commit that deletes the relevant files should not be included in the patch being generated here.
________
I wish there is a easier, more automated way of doing this, but at least this is the best I can do for now.
I will likely e-mail the mailing list the code in patch form shortly.
Regards,
Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com
> Sent: Wednesday, June 22, 2022 at 1:06 PM
> From: "Sam Ravnborg" <sam@xxxxxxxxxxxx>
> To: "Kevin Brace" <kevinbrace@xxxxxxx>
> Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: How do I gather up new code to be converted as patches?
>
> Hi Kevin,
>
> On Wed, Jun 22, 2022 at 07:18:58PM +0200, Kevin Brace wrote:
> > Hi,
> >
> > How to I use git to gather up new code to be converted to patches?
> > Specifically, I have 20+ new files in one location (drivers/gpu/drm/via)
> > and a small change to DRM main make file (drivers/gpu/drm/Makefile).
>
> One simple way to do this is to start with a clean tree, and then add
> files step by step.
> 20+ files in one patch is too much to review, so decide for a
> reasonable split between the files.
>
> Maybe something like (as inspiration find your own split):
> 0) Documentation - or add this in you cover letter. Enough info to give
> the reader a rough understanding of the HW and the driver structure.
> 1) Driver files
> 2) Util files
> 3) Files for the memory handling
> 4) Files for irq handling
> 5) HW specific files
> 6) A the final patch - the Kconfig, and Makefile adjustments.
>
> It is important that the final patch is final as you would otherwise
> break the build.
>
> I look forward to see the patches!
>
> Sam
>
