Version mismatch when building trunk

[Andreas Pakulat]

On 16.10.09 19:49:06, Alexander Neundorf wrote:
> On Friday 16 October 2009, Thiago Macieira wrote:
> > Em Quinta-feira 15. Outubro 2009, às 23.53.18, Chani escreveu:
> > > > > If git is not capable of updating a branch, can I at least clone the
> > > > > same
> > > >
> > > > It's capable of updating a branch.
> > > >
> > > > I chose not to. I chose to create a new one and force you to switch.
> > > >
> > > > >  URL and have the server figure out which branch this currently
> > > > > points to?
> > > >
> > > > Yes, it's already there. The recommended branch is stored in HEAD. Just
> > > >  keep resetting to kde-qt/HEAD.
> > >
> > > [chani at brain kde-qt]$ git remote show origin
> > > * remote origin
> > >   Fetch URL: git://gitorious.org/+kde-developers/qt/kde-qt.git
> > >   Push  URL: git://gitorious.org/+kde-developers/qt/kde-qt.git
> > >   HEAD branch: 4.6-stable-patched
> > >
> > > this is what you're referring to?
> >
> > Yes.
> >
> > > so if there *is* a way for people to set up their git repository so that
> > > it automagically updates to the latest recommended qt with just a 'git
> > > pull' or whatever, can we have instructions for that please? :)
> >
> > There is a way, provided you never have commits of your own on top.
> >
> > git fetch origin HEAD
> > git reset --hard FETCH_HEAD
> 
> So we really want to switch to git at some point in the future ?

As far as things look: yes at some point.

> 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.

What you've seen here is related to keeping kde-qt updated. That doesn't
necessarily mean this is how its going to work in KDE itself. One reason
this is so "complicated" with Qt is because KDE developers do not want
to depend on a stable release for KDE's HEAD, but instead want the
bleeding edge Qt.

IMHO its very good that in the Qt repository if you don't want "current
stable release" you have to explicitly checkout a branch. In fact except
at the time when KDE switches their Qt requirement, keeping Qt
up-to-date is a simple git pull (assuming you've initially switched to
the currently-needed branch, i.e. 4.6-patched right now). Thats the
equivalent of svn up in qt-copy.

> 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.

We've recently switched to git at work for one of the smaller projects
and while it certainly takes a bit to learn git its by far not as hard
as the initial learning curve of a VCS - IMHO.

And you don't have to track "trees and roots", you'll at most have two
branches to track, one is the development-branch, i.e. bleeding edge.
The other is the release branch. Nothing really changes, in fact it'll
be easier as both will be in the same "checkout".

I also think that anybody who judges git by the commands posted here
should instead just checkout his favourite kde module via git svn and
just try to use git.

Andreas

-- 
You are destined to become the commandant of the fighting men of the
department of transportation.