Version mismatch when building trunk

Gary Greene greeneg at
Fri Oct 16 19:41:50 BST 2009

On 10/16/09 11:14 AM, "Pau Garcia i Quiles" <pgquiles at> wrote:
>> So we really want to switch to git at some point in the future ?
>> I've seen several times now in the last weeks to some git-related question an
>> answer like "you just need to do "$ git magic spell of the day" and it will
>> work" that I have slight doubts that it might be just too complicated.
>> With svn/cvs I just needed co/update/commit/diff, sometimes status/log, very
>> rarely blame/copy/move. What I have seen here for git looked so much more
>> complicated, and additionally it seems I still have to actually _learn_ how
>> to deal with all the branches, trees, roots, etc, while I basically just want
>> HEAD and the current release branch.
> IMO problem is we are not only changing VCSs but also changing paradigms.
> In Subversion, the default branch always had the advised stuff. The
> only thing I had to take care of is "svn up" to update sources.
> With git, we are saying "there is no default branch! you must change
> to branch XXX and keep it updated" so now I need to know what is the
> advised branch *and* have that branch updated. That makes it quite
> difficult to follow unless you keep both eyes on k-c-d, qt labs,
> planetkde and whatnot.
> I think it would be easier if the master branch in git always pointed
> to the advised release. I. e. instead of cloning kde-qt.git and
> finding "master" branch is 4.5.2, therefore after cloning 4.5.2 is the
> version I have, please rename the former "master" to "4.5.2",
> "4.5.2-patched" or whatever, and rename "4.6-stable" (or
> "4.6-stable-patched", can't remember now) to "master". This way, when
> I git clone kde-qt.git, or qt.git, I am in the branch I should use to
> develop.
> Now we have these branches:
>    master -> 4.5.2
>    4.6-stable-patched
>    ...
> and ask people to do "git checkout -b 4.6-stable-patched
> origin/4.6-stable-patched" after cloning. Not intuitive unless you
> know git to a certain degree (more than basics). When Qt 4.7 is
> released, we'd have:
>    master -> 4.5.2
>    4.6-stable-patched
>    4.7-stable-patched
>    ...
> and would ask people to checkout 4.7-stable-patched.
> What we should have:
> * Now:
>     master -> 4.6-stable-patched
>     4.6-rc1
>     4.5.2
>     ...
> * When 4.7 is released:
>    master ->4.7-stable-patched
>    4.6-stable-patched
>    ...
> etc
> (I've used 4.7 instead of 4.6 RC1, 4.6 beta 1, etc so that it's easier
> to understand what I mean: "master" should always be the latest Qt
> used to develop KDE, at least in kde-qt.git)
> My 2 cents.

Agreed. VCS' shouldn't be making developers jobs _harder_, but easier. This
means that while this is a little extra work for the merge dude, it's far
easier on the Git challenged/novice KDE programmer that doesn't have the
time/inclination of wanting to learn the "dark magick" portions of a
particular version control system.

Gary L. Greene, Jr.
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See and for more information

Please avoid sending me Word or PowerPoint attachments.

More information about the kde-core-devel mailing list