[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Version mismatch when building trunk
From:       Michael Jansen <kde () michael-jansen ! biz>
Date:       2009-10-17 17:52:08
Message-ID: 200910171952.09005.kde () michael-jansen ! biz
[Download RAW message or body]

> > I didn't claim that it is perfect, but it beats rebuilding Qt and
> >  kdesupport twice because updating Qt did not actually update it.
> >
> > As I said I do a clean build (including prior removal of build and
> > install dirs) whenever updating Qt so the time needed for getting these
> > 170MB don't add that much overhead.
> 
> I'm talking about the load on the server.
> 
> And why do you want to download 170 MB again when those two commands I gave
> you allow you to do with less than 1% of that?
> 

Just a short ... maybe dumb ... question. Is it worth the trouble to not track 
all remote branches. I mean instead of

 bash : 1015 ] $ git config --get-all remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*

having

[ bash : 1018 ] $ git config --get-all remote.origin.fetch
+refs/heads/4.6-stable-patched:refs/remotes/origin/4.6-stable-patched

I know that means i have even more maintenance to do on version switches.

The question is if this really saves bandwith? And i don't necessarily mean 
only in the context of kdeqt. But for example the real qt repository.

Mike


[prev in list] [next in list] [prev in thread] [next in thread]