Re: [PATCH] SMP initialization: detection and enumeration OFF TOPIC PRAISE

[Joshua Branson]

Almudena! Nice work on this! and Holy cow! Your English is getting
fantastic! It inspires me, when I see how much you're learning on this
SMP project. Keep up the good work!

P.S. You might be interested in using the program git send-email.
Apparently it makes it really easy to send in a patches series. It's
actually what GNU Guix contributing guidelines recommends.

https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html

P.P.S. I feel slightly silly giving tips, when everyone else on this
email list is several orders of magnitude a better developer than I am.
In fact, I probably only understood 50% of what this email chain was
about. I hope this off topic email is not offensive or annoying to
anyone. I just wanted an excuse to encourage and praise Almudena
publicly!

--
Joshua Branson
Sent from Emacs and Gnus

[Almudena Garcia]

Hi! Thanks for your comments!!

> P.S.  You might be interested in using the program git send-email.

> Apparently it makes it really easy to send in a patches series.  It's
> actually what GNU Guix contributing guidelines recommends.

My problem is that, in my internal repository, I do many commits for each change (even for each file). The development is progressive.

Then, if I take the commit history to generate my patches, I would generate many spurious patches, making it very difficult to check and apply them.

Even doing a rebase over another branch, the rebase adds the commit history, so I keep the same problem.

And squash commits can be difficult too, because some commits are doing changes in many files.

So, at the moment, I only know dirty tricks to generate the patches.

Thanks anyway

[Samuel Thibault]

Almudena Garcia, le mar. 11 août 2020 13:45:19 +0200, a ecrit:

> > P.S.  You might be interested in using the program git send-email.
> > Apparently it makes it really easy to send in a patches series.  It's
> > actually what GNU Guix contributing guidelines recommends.
> My problem is that, in my internal repository, I do many commits for each
> change (even for each file). The development is progressive.
> Then, if I take the commit history to generate my patches, I would generate
> many spurious patches, making it very difficult to check and apply them.

Sure, that's a common thing when developping.

> Even doing a rebase over another branch, the rebase adds the commit history, so
> I keep the same problem.

? On the contrary, rebase lets you decide what exactly you keep in the
history and what you squash.

> And squash commits can be difficult too, because some commits are doing changes
> in many files.

You can use b (break) within a git rebase session to stop at some point.
That way you can stop before the big change, commit part of it, and use
git rebase --continue, and let git discover that part of the big change
is already there and drop it from the big change.

Samuel

[Almudena Garcia]

> You can use b (break) within a git rebase session to stop at some point.
> That way you can stop before the big change, commit part of it, and use
> git rebase --continue, and let git discover that part of the big change
> is already there and drop it from the big change.

But I have tons of commits. Is there any simple way to only take the latest version of each file and generate a set of commits for them?

[Amos Jeffries]

On 11/08/20 11:57 pm, Samuel Thibault wrote:
> Almudena Garcia, le mar. 11 août 2020 13:45:19 +0200, a ecrit:
>>> P.S.  You might be interested in using the program git send-email.
>>> Apparently it makes it really easy to send in a patches series.  It's
>>> actually what GNU Guix contributing guidelines recommends.
>> My problem is that, in my internal repository, I do many commits for each
>> change (even for each file). The development is progressive.
>> Then, if I take the commit history to generate my patches, I would generate
>> many spurious patches, making it very difficult to check and apply them.
>
> Sure, that's a common thing when developping.
>
>> Even doing a rebase over another branch, the rebase adds the commit history, so
>> I keep the same problem.
>
> ? On the contrary, rebase lets you decide what exactly you keep in the
> history and what you squash.
>

Almundena:

To clarify in case you are not aware. The "rebase -i" operation is what
is being suggested. The -i option enables much more flexibility of
control over the patch sequence and history during rebase.


HTH
Amos

[Amos Jeffries]

On 12/08/20 12:17 am, Almudena Garcia wrote:
>> You can use b (break) within a git rebase session to stop at some point.
>> That way you can stop before the big change, commit part of it, and use
>> git rebase --continue, and let git discover that part of the big change
>> is already there and drop it from the big change.
>
> But I have tons of commits. Is there any simple way to only take the
> latest version of each file and generate a set of commits for them?
>

Is your branch public? I can take some time to go over the history and
make suggestions on cleaning it up if you like.


Amos

[Almudena Garcia]

Yes, It is. This is the branch.

https://github.com/AlmuHS/GNUMach_SMP/tree/smp-new

All commits are related with this patch. The development was long

[Samuel Thibault]

Almudena Garcia, le mar. 11 août 2020 14:17:17 +0200, a ecrit:

> > You can use b (break) within a git rebase session to stop at some point.
> > That way you can stop before the big change, commit part of it, and use
> > git rebase --continue, and let git discover that part of the big change
> > is already there and drop it from the big change.
>
> But I have tons of commits. Is there any simple way to only take the latest
> version of each file and generate a set of commits for them?

Simplest might be to just do it by hand: git diff between master and
your branch to get the complete patch, start a new branch from master,
and apply the patch by pieces to make up proper commits, and finish with
a diff between your old branch and your new branch, to check that you
have everything in place.

Samuel

[Joshua Branson]

Fair enough. I'll see if I can't try to help you in your project. Fair
warning, I am a little out of my league here. Just writing plain
ordinary C programs with pointers to strucks and memory management is
hard for me.