On Saturday 16. January 2010 18.50.17 Thomas McGuire wrote: > Hi, > > On Thursday 14 January 2010 09:59:22 Patrick Ohly wrote: > > On Tue, 2010-01-12 at 19:54 +0000, Stephen Kelly wrote: > > > The "blocked" commits issue poses bigger problems I think. My knowledge > > > of the internals of git is not strong, but I don't think it would be > > > possible to identify commits to keep only in one branch and not merge > > > with the rest. > > > > What you could do is a "git merge --no-commit". Then look at all changes > > that would be committed and revert those that are not wanted in the > > branch that is getting merged into. Commit. The next "git merge" will > > only merge changes made since the last merge, so this manual selection > > only needs to be done once per patch. > > That sounds like something that could work. > When I revert those unwanted commits, they will not get re-merged with the > next "git merge", right? > > One potential problem is that by using this approach, you merge all commits > at once. This doesn't fit nicely in our workflow, we need to merge each > commit by itself. The reason for that is that we have some commits that > come from the ancient enterprise35 branch, which is still KDE3-based, so > we need to port each commit to KDE 4 and also port it to Akonadi now. > That involves fixing a lot of conflicts and also testing things a lot, and > therefore can only be done sanely on individual commits, and not on a merge > of dozens of commits.
Read the manpage of git merge; it allows you to do this trivially as you can specify what you want to merge. -- Thomas Zander _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest