[Kde-games-devel] GIT Conversion status

[Ian Wadham]

Hi Viranch,

On 11/05/2012, at 5:46 PM, Viranch Mehta wrote:
> Is there some progress with this? I've been trying to convert KBreakout to git
> myself but required too much time for first-timers. I'm also running out of time
> on GSoC work. So I was thinking what if I do the following:
> 
> Take the latest code out of SVN and put it in a scratch git repo, do my work
> there on, and then when kbreakout is ready with its git repo, I'd push all the
> commits from scratch repo to a separate branch in the converted git repo,
> and after its reviewed, it can be merged to master.
> 
> The only doubt I have is whether it would be possible to push commits from
> one git repo to some branch in another git repo. If the above is possible, I'd
> really like to start working.

On 26 April, on this thread, this is what Stefan said should be done:

"1. We import the source tree of KBreakout and KDiamond into two
      scratch repos, without any history. The initial commit will also patch
      the build system as required.
 2. The students then push their work to these repos.
 3. When kdegames is converted to Git, the students can easily move to
      the new origin repositories using a three-point rebase. (I'm familiar
      with this process and can post a detailed explanation once this
      becomes relevant."

There was some discussion about using playground, which was resolved
in favour of Stefan's method.  Stefan said he would go ahead and do the
above on 1 May as you quoted below, but either he did not do it or he did
not tell anybody.

So it is time to apply the "British Navy doctrine".  If a ship's captain was facing
a situation in some part of the world far from the UK, he was obliged to ask
headquarters in the UK for instructions.  If he did not receive any within
48 hours, he was entitled to make a decision himself and proceed on his
own initiative.

So I think you should proceed with steps 1 and 2 above, for KBreakout.
Note: No history in your initial scratch repo.  But please tell us and your
mentors where it is … :-)

At some point, I hope Stefan will reveal the mysteries of a "three-point
rebase", whatever that is, and we will be able to merge your work back into
mainstream KBreakout.  Please work with this future merge in mind.

We do NOT want a fork of KBreakout, just two ways to CMake the code: into an
app using QML or an app structured as it is now.

@Avnee: You might need to do the same as Viranch, when you need to start
coding some QML, but with KDiamond and a different repo, obviously.

All the best, Ian W.

> On Tue, May 1, 2012 at 2:33 AM, Ian Wadham <iandw.au at gmail.com> wrote:
> On 01/05/2012, at 3:30 AM, Stefan Majewsky wrote:
> > On Thu, Apr 26, 2012 at 5:04 AM, Ian Wadham <iandw.au at gmail.com> wrote:
> >> Hmmmm … I was proposing, on the "deliverables" thread, that the QML
> >> students should work in playground/games or the GIT equivalent. Isn't
> >> that where new contributions usually go?  I would not like to see QML
> >> code and C++ code intermixed in the release stream until we are ready
> >> to start releasing QML games.
> >
> > playground/games is great for new apps, but not quite for feature
> > work. In the SVN-only era, the correct place would have been
> > branches/work IMO. Since the Git move is already anticipated, working
> > in a Git feature branch is the natural solution to me.
> >
> > You do not need to be concerned about the possibility that the Git
> > move might be delayed: In this case, one can easily rebase the commits
> > stored in Git into a Git-SVN repo to commit to SVN then. I'm relying
> > on such a workflow since over two years, as do at least Parker and
> > Wolfgang.
> >
> > If no one objects, I'll set up two repos tomorrow. (Tomorrow is a
> > holiday in Germany, and I have quite some household and kdegames tasks
> > in my backlog.)
> 
> Yes.  Go for it, Stefan!
> 
> Playground is ruled out for reasons discussed in this thread on 29/30 April.
> 
> Have a good day, Ian W.