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