Re: [PATCH] SMP initialization: detection and enumeration

From:

Almudena Garcia

Subject:

Date:

Sun, 19 Jul 2020 20:46:50 +0200

> for any patch it’s best to not just show a single large diff but to
> split the changes into logically related commits
I've just split the patch. I enumerated them following the dependencies order.

> The commit
> message should describe the changes in a GNU-style ChangeLog format; you
> may also add additional descriptions.

Where can I add this information? In the same patch or in a log file?

Thanks

El dom., 19 jul. 2020 a las 20:23, Almudena Garcia (<liberamenso10000@gmail.com>) escribió:

Anyway, my patch is short. Maybe I can split It manually, taking care about dependencies between blocks.

El dom., 19 jul. 2020 a las 20:17, Almudena Garcia (<liberamenso10000@gmail.com>) escribió:
Thanks for your explanation:

> To commit only some changes and not others you can select lines of
> interest with “git add -p” (or similar). Once all connected changes
> have been staged you can commit them. Do this repeatedly until you have
> a series of commits that are all small enough that a reviewer can
> understand them (and thus your thinking) at a glance.

I have already a commit list pushed in my GitHub repository. You can see It here: https://github.com/AlmuHS/GNUMach_SMP/commits/smp-new
But, in this case, my code is almost written from scratch, so It's complex to filter line by line.
The code only makes sense in a single piece. Otherway, the code doesn't compile or does nothing.

> You can then turn that series of commits into a series of patches with
> “git format-patch”. For example, “git format-patch -10” will generate
> 10 patch files from the last 10 commits.

Ok, I'll try this. But there are so many commits.

El dom., 19 jul. 2020 a las 19:52, Ricardo Wurmus (<rekado@elephly.net>) escribió:

Hi,

for any patch it’s best to not just show a single large diff but to
split the changes into logically related commits. You’re probably
working with Git, so the unit that we’re working with is a Git commit.

You should group related changes and commit them together. The commit
message should describe the changes in a GNU-style ChangeLog format; you
may also add additional descriptions. Here’s an example:

--8<---------------cut here---------------start------------->8---
kern: Frobnicate the jabberwocky.

In order to frobnicate the jabberwocky without confusion we only add the
core functionality here.

* kern/smp.c, kern/smp.h: New files.
* Makefrag.am (libkernel_a_SOURCES): Add them.
--8<---------------cut here---------------end--------------->8---

To commit only some changes and not others you can select lines of
interest with “git add -p” (or similar). Once all connected changes
have been staged you can commit them. Do this repeatedly until you have
a series of commits that are all small enough that a reviewer can
understand them (and thus your thinking) at a glance.

You can then turn that series of commits into a series of patches with
“git format-patch”. For example, “git format-patch -10” will generate
10 patch files from the last 10 commits. You can attach these patches
to an email, or if you have configured “git send-email” correctly you
could send them directly via email to this list. A reviewer can then
comment on each commit individually and apply them one by one if they
pass muster.

(This process is similar for most GNU packages.)

Hope this helps!

--
Ricardo