[Ktechlab-devel] let’s test some git workflow

[P Zoltan]

On Thu, 16 Sep 2010 15:08:01 +0300, Julian Bäume <julian at svg4all.de> wrote:

> hi there,
> i just read through the latest commits in zoltan’s master branch. I saw  
> that
> he hard-coded the pin ids into the element’s code. Some time ago, I had a
> similar problem with the SVG-files. Now, I know, that these also contain  
> the
> pin ids. So I added a feature to share this information. Now I want  
> Zoltan to
> use my new code in the future, so I need him to integrate this, somehow.  
> Here
> is, how it should be done:
>
> ------- SNIP --------------
>
> I branch zoltan/master to create the patches on top of his branch.
>
> git branch -b merge zoltan/master
>
> Then I implement the patch and commit it.
> I ran the tests to verify everything still is fine.
>
> I check for changes in zoltan/master:
>
> git pull --rebase
>
> I push the changes into a new branch into zoltan/-repository:
>
> git push zoltan merge:merge
>
> If there is already a branch called merge, I change the line to:
>
> git push zoltan merge:mergeXX
>
> for the first free value of XX.
>
> I tell Zoltan to have a look at my changes and ask him for comments.
>
> This step can be done 0 to n times (for any fixed number n):
> Zoltan asks me to change something, because he doesn’t like the patch,  
> as it
> is. I create another patch, commit and push the changes and ping Zoltan.
>
> Zoltan merges my changes and delets the branch:
>
> git merge origin/merge[XX]
> git push origin :merge[XX]
>
> ------- snap -----------
>
> ok, that’s for the workflow.

I will have to look into these later. Is there an easy way to do this with  
'git gui' ? I like that frontend more than the command-line.

Generally, I like the idea to send parts of code that should be merged,  
but I'm not sure if it's a good idea to push a branch in other people's  
repository. But I think I can live with it.

> now for the content ;)
>
> I haven’t finished the complete patch, yet. There is still some work  
> todo on
> my side. But I want you to have a look at the first 2 commits. The first  
> one
> fixes something I mentioned some time ago on the ML.

Yes, I've fixed the test cases, and not the main application. This is  
trivial.

> The second one is another
> approach to implement a generic element factory. This is IMHO a little  
> more
> C++-ish.

IMHO the macro-styled was easier/simpler to use. In 3 lines of code, one  
could get a factory with one supported element. Also the  
createOrRegister() method is an internal hack, it shouldn't be exposed in  
other parts of the program. I wanted to change the macros, in order to  
allow registering a class with different ID than its own name. I don't  
know what to do about the new class.

>
> If you like it, you could cherry-pick these 2 (or only one of them). And  
> leave
> the rest as is, until I finished it. I just needed to publish it,  
> because this
> mail was half-done since nearly a day, now ;) and I wanted it marked  
> “done” on
> my TODO.
>
> bye then
> julian
>


> PS: i noticed your minimal_simulator branch. nice idea! :)

I wanted to write an email about that branch earlier, but I'm writing  
about it now.

There I have taken the latest SVN version, and now trying to compile and  
run the old simulator alone, without any GUI code. Now it compiles and  
does nothing (at least it doesn't crash).

The elements need no change, in order to be Qt4 compatible, but the  
components contain GUI code, so that has to be changed. Also the  
GPSimProcessor class is currently disabled, because it has some GUI  
dependencies.

Currently I'm trying to figure out how to add pins to elements and how to  
connect elements in a circuit. If that's done, I'd like to create some  
test circuits, in order to verify the code; after that I'd like to make  
the logic parts work. Maybe Alan can help with this.

  These are the news,

   Zoltan