[Kde-pim] [Kde-scm-interest] Git and the needs of KDE PIM

Thomas McGuire mcguire at kde.org
Sat Jan 16 19:36:12 GMT 2010


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100116/30477f75/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list