Differences

This shows you the differences between two versions of the page.

--- lkmp:lkmp_first_kernel_patch [2019/04/06 02:37]
ShuahKhanLF
+++ lkmp:lkmp_first_kernel_patch [2019/08/08 22:22] (current)
ShuahKhanLF
@@ Line 2: / Line 2: @@
 This material in this guide is based on the KernelNewbies [[https://kernelnewbies.org/FirstKernelPatch|FirstKernelPatch]] tutorial.
+Let's start by configuring global git options and then you can go onto cloning the kernel repository.
 ==== Setup git ====
-First, you need to tell git what your name and email address is, so that it can be used in the authorship information in the git commit. Create a file named .gitconfig in your home directory and add lines like these to it:
+Create a user-specific Git configuration file named **.gitconfig** in your home directory with your name, email, and other configuration. This information is used for commits and patch generation.
 <code>
 [user]
    name = Your Name
@@ Line 23: / Line 26: @@
 	smtpuser       = user
 	smtppass       = password
 </code>
-**Make sure that the email you specify here is the same email you used to set up sending mail**. The Linux kernel developers will not accept a patch where the "From" email differs from the "Signed-off-by" line, which is what will happen if these two emails do not match.
+**The email in the .gitconfig should be the same email you will use to send patches**. The "name" is the "Author" name and the email is the email address for the commit. The Linux kernel developers will not accept a patch where the "From" email differs from the "Signed-off-by" line, which is what will happen if these two emails do not match.
-Make sure you store your full, legal name in the 'name' line. By adding your Signed-off-by line to a patch, you are certifying that you have read and understood the [[https://www.kernel.org/doc/html/latest/process/submitting-patches.html|Developer's Certificate of Origin]] and abide by the [[https://www.kernel.org/doc/html/latest/process/kernel-enforcement-statement.html|Linux Kernel Enforcement Statement]]. Please read though the documents before you send patches to the kernel.
+Make sure you store your full, legal name in the name line. By adding your Signed-off-by line to a patch, you are certifying that you have read and understood the [[https://www.kernel.org/doc/html/latest/process/submitting-patches.html|Developer's Certificate of Origin]] and abide by the [[https://www.kernel.org/doc/html/latest/process/kernel-enforcement-statement.html|Linux Kernel Enforcement Statement]]. Please read though the documents before you send patches to the kernel.
 ==== Explore the kernel tree ====
@@ Line 43: / Line 47: @@
 </code>
-This is the Linux kernel tree.  You can explore it by using the `ls` and `cd` commands. If you run `ls`, you'll see several different folders:
+This is the Linux kernel tree.  You can explore it by using the "**ls**" and "**cd**" commands. If you run "**ls**", you'll see several different folders:
 <code>
@@ Line 53: / Line 57: @@
 </code>
-There's more to this directory than meets the eye!  If you run ls -A, you'll see there's a hidden directory called **.git**.  This contains all the meta information that git uses to track branches, remote repositories, and changes to files in the local directory.
+There's more to this directory than meets the eye!  If you run "**ls -A**", you'll see there's a hidden directory called "**.git**".  This contains all the meta information that git uses to track branches, remote repositories, and changes to files in the local directory.
 <code>
@@ Line 66: / Line 70: @@
 </code>
-You can view the commit history by running `git log`. The following example uses `git log -2` to look at the top two coomits to illustrate the difference between full commit log vs. the short log.
+You can view the commit history by running git log. The following example uses "**git log -2**" to look at the top two commits to illustrate the difference between full commit log vs. the short log.
 <code>
@@ Line 129: / Line 133: @@
 Git includes support for branches.  Each branch can contain a completely different set of patches. Kernel developers typically use one branch per patch set. For example, you might have one branch that includes bug fixes, and another branch that contains commits for a new feature you're working on.
-You can run `git branch` to see which branch you're on:
+You can run "**git branch**" to see which branch you're on:
 <code>
@@ Line 138: / Line 142: @@
 In this case, there is only one branch, called master. The star indicates that the "master" branch is the one you are currently on. In git speak, we say that you currently have the master branch "checked out".
-You can also use the git branch command to show branches on the staging remote repository. Run the `git branch -a` command:
+You can also use the git branch command to show branches on the staging remote repository. Run the "**git branch -a**" command:
 <code>
@@ Line 151: / Line 155: @@
 </code>
-The first remote repository that is used to create the git checkout is called "origin".  For now, just remember that "origin" means Greg Kroah-Hartman's staging git repository.  Here, you can see the staging remote has five branches: master, staging-linus, staging-next, staging-testing, and test. The staging-linus branch contains bug fix patches for the current kernel release candidate, and the staging-next branch contains patches for the next kernel release.  Your patches will all go into staging-testing (since they will be code clean up, not bug fixes), so you want to base all your branches on the staging-testing branch.  Greg first applies patches to staging-testing. They are moved to staging-next shortly thereafter.
+The first remote repository that is used to create the git checkout is called "origin".  For now, just remember that "origin" means Greg Kroah-Hartman's staging git repository.  Here, you can see the staging remote has five branches: master, staging-linus, staging-next, staging-testing, and test. The staging-linus branch contains bug fix patches for the current kernel release candidate, and the staging-next branch contains patches for the next kernel release.  Your patches will all go into staging-testing (since they will be code clean up, not bug fixes), so you want to base all your branches on the staging-testing branch. Greg first applies patches to staging-testing. They are moved to staging-next shortly thereafter.
@@ Line 225: / Line 229: @@
 </code>
-If you run `git log` to show your staging branch history and then `git log origin/staging-testing` to show the staging-testing branch history, you should see that they have exactly the same commits.
+If you run "**git log**" to show your staging branch history and then "**git log origin/staging-testing**" to show the staging-testing branch history, you should see that they have exactly the same commits.
 ==== Configure the kernel ====
 The next step is to create a configuration file, compile the new kernel, and install it.
-The first thing to know is that the Linux kernel is completely configurable.  Each driver can be separately configured to be installed or not.  There are three choices for driver installation:
+The first thing to know is that the Linux kernel is completely configurable. Each driver can be separately configured to be installed or not. There are three choices for driver installation:
   * disable the driver completely,
@@ Line 253: / Line 257: @@
 </code>
-You can duplicate the distro's configuration by copying one of the config-* files to a .config file in your git tree.
+You can duplicate the distro's configuration by copying one of the **config-*** files to a **.config** file in your git tree.
 You can read more about configuring a kernel [[http://www.linuxjournal.com/content/kbuild-linux-kernel-build-system|here]].
 ==== Compile the kernel ====
-Next, you'll need to run `make` to compile your new kernel.  Optionally, make can take a flag that indicates how many threads to spawn to start separate compilations. Usually you want to pick a number that is equal to the number of CPUs you have in your machine.  For example, if you had a dual core system, you would run:
+Next, you'll need to run "**make**" to compile your new kernel. Optionally, make can take a flag that indicates how many threads to spawn to start separate compilations. Usually you want to pick a number that is equal to the number of CPUs you have in your machine.  For example, if you had a dual core system, you would run:
 <code>
@@ Line 272: / Line 276: @@
 Your native Linux system will have many different drivers. Find out which drivers are loaded on your system, and modify one of them.
-First, use `lsmod` to see what drivers are loaded, and pick a name from that list to modify. This example shows making changes to uvcvideo.
+First, use "**lsmod**" to see what drivers are loaded, and pick a name from that list to modify. This example shows making changes to uvcvideo.
-Once you have the name of a driver, it's time to find out where the .c and .h files for that driver are in the Linux kernel repository.  You can do that by searching through the Makefiles to find out what C files are compiled into the driver binary. The best way to do that is with `git grep`. Unlike normal grep, git grep only searches through checked-in files in the repository. Normal grep will also search the binary files, and even the .git directory, which isn't useful and wastes your time.
+Once you have the name of a driver, it's time to find out where the .c and .h files for that driver are in the Linux kernel repository.  You can do that by searching through the Makefiles to find out what C files are compiled into the driver binary. The best way to do that is with "**git grep**". Unlike normal grep, git grep only searches through checked-in files in the repository. Normal grep will also search the binary files, and even the .git directory, which isn't useful and wastes your time.
-For example, if you wanted to search for the files that are compiled into the xhci-hcd driver, you would run this command:
+For example, if you wanted to search for the files that are compiled into the uvcvideo driver, you would run this command:
 <code>
@@ Line 324: / Line 328: @@
 </code>
-Then type :wq<enter> to save the file and quit.
+Then type **:wq<enter>** to save the file and quit.
-A pr_info() function causes a message to be written to the kernel log buffer, which can then be viewed using the dmesg command.
+A pr_info() function causes a message to be written to the kernel log buffer, which can then be viewed using the "**dmesg**" command.
 Now edit drivers/media/usb/uvc/uvc_video.c, find the _prove function and add a pr_info() to it.
@@ Line 358: / Line 362: @@
 </code>
-Then type :wq<enter> to save the file and quit.
+Then type **:wq<enter>** to save the file and quit.
-A pr_info() function causes a message to be written to the kernel log buffer, which can then be viewed using the dmesg command.
+A pr_info() function causes a message to be written to the kernel log buffer, which can then be viewed using the "**dmesg**" command.
 ==== Compile your changes ====
-Recompile your kernel, by running make (with an optional -jN flag):
+Recompile your kernel, by running **make (with an optional -jN flag)**:
 <code>
@@ Line 370: / Line 374: @@
 </code>
-You may need to fix some compilation errors.  Also fix any new warnings that are due to your changes.  In the Linux kernel, we strive to make sure that drivers do not produce warnings on anyone's system (this includes 32-bit and 64-bit systems, as well as different architectures, such as PPC, ARM, or x86). New features or bug fix patches that add additional warnings may not get merged. Please read the [[https://www.kernel.org/doc/html/latest/process/submit-checklist.html|Linux Kernel patch submission checklist]] to understand what Linux kernel maintainers expect patch authors to do before sending the patch.
+You may need to fix some compilation errors. Also fix any new warnings that are due to your changes.  In the Linux kernel, we strive to make sure that drivers do not produce warnings on anyone's system (this includes 32-bit and 64-bit systems, as well as different architectures, such as PPC, ARM, or x86). New features or bug fix patches that add additional warnings may not get merged. Please read the [[https://www.kernel.org/doc/html/latest/process/submit-checklist.html|Linux Kernel patch submission checklist]] to understand what Linux kernel maintainers expect patch authors to do before sending the patch.
 ==== Install your changes ====
@@ Line 386: / Line 390: @@
 </code>
-Search for your pr_info in the log file by typing "/I changed". You should be able to find this message within the driver output during boot. If you don't see this message, ask for help on the #kernelnewbies IRC channel on irc.oftc.net, or on the linux-kernel-mentees mailing list
+Search for your pr_info in the log file by typing "**/I changed**". You should be able to find this message within the driver output during boot. If you don't see this message, ask for help on the #linux-kernel-mentees IRC Channel on [[https://freenode.net/|freenode]] irc.freenode.net, or on the linux-kernel-mentees mailing list
 ==== Revert your changes ====
@@ Line 401: / Line 405: @@
 ==== Git post-commit hooks ====
-Git includes some "hooks" for scripts that can be run before or after specific git commands are executed.  The "post-commit" hook is run after you make a git commit with the `git commit` command.
+Git includes some "hooks" for scripts that can be run before or after specific git commands are executed.  The "post-commit" hook is run after you make a git commit with the "**git commit**" command.
 Linux kernel developers follow [[https://www.kernel.org/doc/html/latest/process/coding-style.html|Linux kernel coding style]]. Once you made changes, you can run [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl|checkpatch.pl]] that you can run over your patches to make sure the patch complies with the kernel coding style.
@@ Line 407: / Line 411: @@
 To ensure that you create good commits that comply with the coding style, you can run checkpatch.pl over your commit with the "post-commit" hook. Note that running checkpatch after the commit, checks the patch file you've created - not just the source code diff.  Therefore it will catch more issues - spelling errors in log messages, spacing in log messages, warnings about adding/removing files, etc.
-If you already have a .git/hooks/post-commit file, move it to .git/hooks/post-commit.sample.  git will not execute files with the .sample extension.
+If you already have a .git/hooks/post-commit file, move it to .git/hooks/post-commit.sample. git will not execute files with the .sample extension.
 Then edit the .git/hooks/post-commit file to contain only the following two lines:
@@ Line 429: / Line 433: @@
 </code>
-After you commit, this hook will output any checkpatch errors or warnings that your patch creates.  If you see warnings or errors that you know you added, you can amend the commit by changing the file, using `git add` to add the changes, and then using `git commit --amend` to commit the changes.
+After you commit, this hook will output any checkpatch errors or warnings that your patch creates.  If you see warnings or errors that you know you added, you can amend the commit by changing the file, using "**git add**" to add the changes, and then using "**git commit --amend**" to commit the changes.
 ==== Checking that the post-commit hook works ====
-You can check that the post-commit hook is working by adding a deliberate change that will trigger checkpatch (such as adding a really long line or adding trailing whitespace to a line), and then attempting to run `git commit`. After you commit, you should see the additional checkpatch.pl warning or error.
+You can check that the post-commit hook is working by adding a deliberate change that will trigger checkpatch (such as adding a really long line or adding trailing whitespace to a line), and then attempting to run "**git commit**". After you commit, you should see the additional checkpatch.pl warning or error.
 Note that you will need to place this hook in any/every tree in which you build patches.
@@ Line 488: / Line 492: @@
 </code>
-You should reboot your kernel, load the driver with `modprobe`.  You'll be able to see that the driver is loaded by running `lsmod`.  Loading the driver at least makes sure that the driver probe function works.
+You should reboot your kernel, load the driver with "**modprobe**".  You'll be able to see that the driver is loaded by running "**lsmod**".  Loading the driver at least makes sure that the driver probe function works.
-**Note:** Do not work on drivers that show that they depend on CONFIG_BROKEN.  If you search for a driver after running `make menuconfig`, and you notice the "Depends on:" line includes BROKEN, do not work on this driver.
+**Note:** Do not work on drivers that show that they depend on CONFIG_BROKEN.  If you search for a driver after running "**make menuconfig**", and you notice the "Depends on:" line includes BROKEN, do not work on this driver.
 ==== Compiling only part of the kernel ====
@@ Line 523: / Line 527: @@
 </code>
-Now, I run `make menuconfig` and type '/' to search for USB_XHCI_HCD.  The search entry shows:
+Now, I run "**make menuconfig**" and type "**/**" to search for USB_XHCI_HCD.  The search entry shows:
 <code>
@@ Line 536: / Line 540: @@
 </code>
-Look at the "Depends on" line.  This is a boolean equation that represents the driver dependencies that need to be enabled in order to even show the driver option in the menus.  A 'y' means the driver or subsystem is built into the kernel and an 'm' means the driver is built as a module.  Both these options are equivalent to '1' in boolean logic.  A 'n' means the driver or subsystem is disabled.  An 'n' is equivalent to a '0' in boolean logic.
+Look at the "Depends on" line.  This is a boolean equation that represents the driver dependencies that need to be enabled in order to even show the driver option in the menus.  A **'y'** means the driver or subsystem is built into the kernel and an 'm' means the driver is built as a module.  Both these options are equivalent to **'1'** in boolean logic.  A **'n'** means the driver or subsystem is disabled. An **'n'** is equivalent to a **'0'** in boolean logic.
 Tip: If you don't know boolean logic, you can take a look at these [[http://www.youtube.com/watch?v=gj8QmRQtVao|tutorials]].  If you just need a brush up on boolean logic, here's a [[http://stackoverflow.com/questions/7583853/true-and-false-for-logic-and-logic-table|crib sheet]].  If you're lazy, here's a boolean algebra [[http://www.wolframalpha.com/examples/BooleanAlgebra.html|calculator]], or you can use the "Programming Mode" for the calculator application installed in Ubuntu by default.
-In this case, the xHCI driver config option is not being shown in the menus because USB is set to 'n'.  If I search for USB, I see lots of results, and finally find this relevant one:
+In this case, the xHCI driver config option is not being shown in the menus because USB is set to **'n'**.  If I search for USB, I see lots of results, and finally find this relevant one:
 <code>
@@ Line 553: / Line 557: @@
 </code>
-If I look under the Device Drivers menu, I can find "USB Support" and set it to 'm'.  Once that's done, I can find CONFIG_XHCI_HCD under the "USB Support" menu.
+If I look under the Device Drivers menu, I can find "USB Support" and set it to **'m'**.  Once that's done, I can find CONFIG_XHCI_HCD under the "USB Support" menu.
 It may take recursively enabling several different configuration options before you can even see your driver in the menu.  Ask for help if you're stuck.
-Note: Do not work on drivers that show that they depend on CONFIG_BROKEN.  If you search for a driver after running `make menuconfig`, and you notice the "Depends on:" line includes BROKEN, do not work on this driver.
+Note: Do not work on drivers that show that they depend on CONFIG_BROKEN.  If you search for a driver after running "**make menuconfig**", and you notice the "Depends on:" line includes BROKEN, do not work on this driver.
 Please read [[https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt|Kconfig Language]] for details.
 ==== Reloading modules ====
-If you're running a kernel that has the same release version (`uname -r`) as the new code you're compiling, you can test your changes without rebooting. Simply install the module in /lib/modules, and unload and reload the driver:
+If you're running a kernel that has the same release version (**uname -r**) as the new code you're compiling, you can test your changes without rebooting. Simply install the module in /lib/modules, and unload and reload the driver:
 <code>
@@ Line 570: / Line 574: @@
 </code>
-How do you know what the module name is?  If you've compiled the driver as a module, there should be a .ko file in the parent directory.  For example, after we configure the android driver to be compiled as a module, we can run this command:
+How do you know what the module name is? If you've compiled the driver as a module, there should be a .ko file in the parent directory.  For example, after we configure the android driver to be compiled as a module, we can run this command:
 <code>
@@ Line 577: / Line 581: @@
 </code>
-So, there are two drivers that we need to load with modprobe. You can load those drivers one at a time by passing modprobe the base filename:
+So, there are two drivers that we need to load with **modprobe**. You can load those drivers one at a time by passing **modprobe** the base filename:
 <code>
@@ Line 593: / Line 597: @@
 ==== Viewing your changes ====
-Git keeps track of changes in the working directory.  Git can be told to ignore binary files (like .o or .ko files), so it won't track changes to those files.  You can see which files have been modified by running:
+Git keeps track of changes in the working directory.  Git can be told to ignore binary files (like .o or .ko files), so it won't track changes to those files. You can see which files have been modified by running:
 <code>
@@ Line 612: / Line 616: @@
 </code>
-If you run `git diff` again, you'll notice it doesn't list any changed files. That's because, by default, git diff only shows you the unstaged changes.  If you run this command instead, you'll see the staged changes:
+If you run "**git diff**" again, you'll notice it doesn't list any changed files. That's because, by default, git diff only shows you the unstaged changes. If you run this command instead, you'll see the staged changes:
 <code>
@@ Line 656: / Line 660: @@
 </code>
-This will show the latest commit. If you want git to show a different commit, you can pass the commit ID (the long number that's shown in `git log`, or the short number that's shown in `git log --pretty=oneline --abbrev-commit`).  Read the "Specifying Revisions section" of the `git rev-parse` manual page for more details on what you can in place of a commit ID.
+This will show the latest commit. If you want git to show a different commit, you can pass the commit ID (the long number that's shown in "**git log**", or the short number that's shown in "**git log --pretty=oneline --abbrev-commit**".  Read the "Specifying Revisions section" of the "**git rev-parse**" manual page for more details on what you can in place of a commit ID.
 You'll also want to make sure your commit looks fine when you run these two commands:
@@ Line 702: / Line 706: @@
 ==== Sending patches with git send-email ====
-You can also send a patch with the command-line tool `git send-email`. You can either pass it the file that `git format-patch` generated, or you can give it the same commit ID range you gave `git format-patch`:
+You can also send a patch with the command-line tool "**git send-email**". You can either pass it the file that "**git format-patch**" generated, or you can give it the same commit ID range you gave "**git format-patch**":
 <code>
@@ Line 708: / Line 712: @@
 </code>
-You should already have all the information in your .gitconfig at the beginning in **Setup git** section of this document.
+You should already have all the information in your **.gitconfig** at the beginning in **Setup git** section of this document.
 git send email will prompt you with who to send the message to, and other odd questions:
@@ Line 719: / Line 723: @@
 Put in your mentor's address in the first line, and leave the second blank unless you want it to appear as a thread in an existing conversation.
-At this point `git send-email` will look for Cc: lines in your commit message, and include them in the email headers. It will then show you the resulting email header, and ask you to confirm:
+At this point "**git send-email**" will look for Cc: lines in your commit message, and include them in the email headers. It will then show you the resulting email header, and ask you to confirm:
 <code>
 Send this email? ([y]es|[n]o|[q]uit|[a]ll):
-<code>
+</code>
 [[https://vthakkar1994.wordpress.com/2017/01/21/sending-patches-with-the-git-send-email/|More help with git send-email]]
@@ Line 739: / Line 743: @@
 Send your patch to the maintainer and lists that the get_maintainer.pl script tells you to.
-Please send you patch to linux-kernel-mentees mailing list
+Please send you patch to **linux-kernel-mentees** mailing list
 ==== Responding to emails ====
@@ Line 805: / Line 809: @@
 </code>
-It's fairly simple to accomplish this, and there's certainly a few ways to do this.  If you generate your patches using `git format-patch`, then it's simple to do this. Just add the --subject-prefix option like this:
+It's fairly simple to accomplish this, and there's certainly a few ways to do this.  If you generate your patches using "**git format-patch**", then it's simple to do this. Just add the --subject-prefix option like this:
 <code>
@@ Line 838: / Line 842: @@
 ==== Versioning patchsets ====
-When you send out a new version of a patchset, you could either indicate on each patch what has changed or you could include the changes in a coverletter. If you plan to indicate the changes in each patch, you need to specify what has changed in each version like in this [[https://lkml.org/lkml/2018/2/23/287|patch example]] and indicate '''No change''' explicitly for patch versions that are unaltered. In case you decide to indicate the changes in a coverletter, here is an [[http://marc.info/?l=linux-usb&m=139302798628519&w=2|Example cover letter.]]  You can include a coverletter in your patchset by using the `--cover-letter` option to `git format-patch`, e.g.
+When you send out a new version of a patchset, you could either indicate on each patch what has changed or you could include the changes in a coverletter. If you plan to indicate the changes in each patch, you need to specify what has changed in each version like in this [[https://lkml.org/lkml/2018/2/23/287|patch example]] and indicate "**No change**" explicitly for patch versions that are unaltered. In case you decide to indicate the changes in a coverletter, here is an [[http://marc.info/?l=linux-usb&m=139302798628519&w=2|Example cover letter.]]  You can include a coverletter in your patchset by using the "**--cover-letter**" option to "**git format-patch**", e.g.
 <code>
@@ Line 846: / Line 850: @@
 where Y is the version of the patch you are currently sending.  The cover-letter option will create a "PATCH 0/Y" that you can add a change log to.  Make sure to change the SUBJECT HERE on the coverletter subject line.  Note that cover letters are discarded when applying patches, so any information that you want to preserve in the git log should be in the patch descriptions, not the cover letter.  The cover letter is for introducing what problem you're trying to solve, and including version change logs.
-'''Make sure to include all of the patches you sent in the patchset before''' (i.e. if you sent three patches and you had to revise the second patch, send all three again).
+Make sure to include all of the patches you sent in the patchset before (i.e. if you sent three patches and you had to revise the second patch, send all three again).
 An example of what this would look like is:
@@ Line 883: / Line 887: @@
 Typically, the subject prefix for patches in the patchset are [PATCH X/Y] or [RFC X/Y], where Y is the total number of patches, and X is the current patch number.  Patchsets often have a "cover letter" that is [PATCH 0/Y] or [RFC 0/Y].  A cover letter is used to explain why the patchset is necessary, and provide an overview of the end result of the patches.  Cover letters are also great places to ask for help in reviewing specific patches in the patchset.
-In order to create patchsets like this, you will need to use either `git send-email`` or `git format-patch`. These tools will generate the right "In-Reply-To" Headers, so that in a text mail client, the patches will appear next to each other, rather than having unrelated email in between.  Otherwise, patches may get jumbled, depending on when they were received.
+In order to create patchsets like this, you will need to use either "**git send-email**" or "**git format-patch**". These tools will generate the right "In-Reply-To" Headers, so that in a text mail client, the patches will appear next to each other, rather than having unrelated email in between.  Otherwise, patches may get jumbled, depending on when they were received.
 ==== Using git format-patch to send patchsets ====
-First, use `git log --pretty=oneline --abbrev-commit` to figure out the first commit ID you want to send.  For example, say that my tree had this git log history:
+First, use "**git log --pretty=oneline --abbrev-commit**" to figure out the first commit ID you want to send.  For example, say that my tree had this git log history:
 <code>
@@ Line 921: / Line 925: @@
 </code>
-Please send patch to linux-kernel-mentees mailing list.
+Please send patch to **linux-kernel-mentees** mailing list.

Wiki

User Tools

Site Tools

Differences

Page Tools