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

[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?

El mar., 11 ago. 2020 a las 13:57, Samuel Thibault (<samuel.thibault@gnu.org>) escribió:

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