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

[Julian Bäume]

Am Donnerstag, 16. September 2010, 15:50:18 schrieb 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.

It should be possible. These are mainly branch and merge operations. These 
should be supported. There is no deep git cli magic involved. I hope, all this 
will get even more easy with the next KDevelop version, that will ship a git 
plugin ;) At least reviewing the patches will be really cool.

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

I thought about that, too. I thought, the best place would be in your repo, 
but in a branch, you are not working on, so it won’t ever disturb your work. 
But on the other hand, you could just pull from my repo, too. There is not 
much difference. I sync my repo more ofter, than I do with yours, so I 
thought, it would be a good idea, to push directly into your repo to draw your 
attention. Another option would be to push these branches into our own repos 
or into the master repo. May be, our own would be the best location. There it 
doesn’t hurt to much, if something bad (tm) happens ;) I didn’t think about 
that, because I feel comfortable with git and know what to do.

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

Well a basic implementation with my approach won’t be much longer. Just have a 
look into the 3rd patch and there you can see, what is possilble when using a 
sub-class instead of a macro. Also keep in mind, that I implement both 
factories needed for the plugin in one class. May be, there can even be a 
better solution for the createOrRegister-hack ;) I haven’t put to much thought 
into this. I don’t think, it’s such a big deal to use this method in the 
factories. We won’t have this many plugins in the future, and some of them 
might even not use the generic approach but implement their own versions of 
the interface.


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

that sounds pretty cool :) i’m looking forward to see, how this approach will 
work out :)

bye then
julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20100917/7604e366/attachment.sig>