> 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.thiba...@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 > >
