Hi, On Saturday 16 January 2010 19:32:47 Thiago Macieira wrote: > Merges in Git always merge all commits, never any less. That's a definition > of merge. [..] You design your branches so that all commits > are mergeable.
I hope I can still merge the commits one by one, instead of all in one go. Because of the KDE3 to KDE4 port needed for our commits, those commits are inherently unmergable without manually resolving conflicts. > The two situations where one commit may be necessary in one > branch but not in the branch where it's normally merged are: > > 1) a fix that doesn't apply to the other branch > in that case, apply it, then merge to the other branch, then apply the > reverse So I basically apply a patch and then revert it again directly afterwards, and that will fool Git into thinking the commit is merged? Fair enough, if that works it would be a solution. > 2) if this is to happen frequently, then you need actually three branches > a common one, which is merged to two branches Ok, this makes sense, and I can see ourselves using that: Having a seperate branch which contains the changelog and the changed version numbers, and having a branch for everything else, the main bugfixing branch. The main bugfixing branch would be merged to trunk and to the changelog/version number branch regularly. Thanks for your reply. Regards, Thomas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
