Tomek CEDRO wrote: > Im afraid there is not much sense in that interactive rebasing for > such big change - it took me so many hours to split patches and in > result now there are even more patches some new patches patched by old > patches ;] This is far from perfect.
You know that interactive rebase can also be used to reorder commits? So you would move the commits that belong together after each other, have the first be pick, and then use squash or fixup for the others. To be able to use this feature it is an absolute requirement that each commit in the repo only changes one logical thing, or there will be massive complications. This is only one of the many reasons why it is so important to have each commit be only a single logical change. > I can see git wants to keep the commit history at all cost, For a public repository it is the prefered way, but it's not a hard requirement, especially not if you announce in advance that there will be history changes in the repository, or maybe only in certain branches. > so the cructial thing here is producting good commits. This is important. Not because git wants it, but rather because it is the only way that allows to take full advantage of features in git, which makes further work in the repo really easy. > how to produce "good patches" from git diff (i.e. something as > git format-patch)... or the git diff is enough? I'd be happy to help you with this but I think email is not so convenient. I would prefer IRC or jabber, and probably some pastebinning. I just joined #openocd on irc.freenode.net. //Peter _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
