You can consider, for now, the git repo to be read-only: you can download from it, and when I post code updates to it you can sync the code changes and it will ask what you want and how you want to merge, but it's not an open repo that anyone can commit to.

It's about making it easier to maintain forks that stay in sync (as well as having the ability to submit patches more easily); it's not and wasn't intended to be a free-for-all

Just a big "thanks for all your work" from me.After using git for some days now to fork your code, add mine, merge your changes back and push everything with ftp on my life server I'm really impressed how easy everything works. I'm still new to versioning and all this "real" programmer-stuff, but it's not that hard to understand and the workflow is great.

I've staged and committed my fixes to profile.php. But how do I send you the "pull request"?

The progit.org/book in chapter 2 said it would talk about pushes and pulls but really only talked about pushes. I'll be getting into chapter 3 next, but figured someone might be able to give me a quick tip on how to do it.

It's not enough to pull kestas code to your local harddrive, but you need to setup a fork of the code on githup.Than you can push your changes to your repo on githup and generate a pull request.

Step by Step.1. fork the webdip code on github2. setup your local install to use your fork instead of kestas code.3. pull the code from your fork4. apply all your changes5. commit them6. Push them to githup7. Generate a pull-request on githup

Thanks, that makes a lot more sense and matches what I'm used to doing at work with IBM Rational ClearCase but with different terminology. In ClearCase you create a dev stream (fork) off of the integration stream (Kesta's repo), check out files, make changes, and check them back into the dev stream (commit) as an activity, and then send an email to the ClearCase librarian to deliver the activity to the integration stream (pull-request). Of course in this case Kestas also gets to decide whether or not he wants the changes.

So how does that work if Kestas doesn't want a change and then I make other changes that he does want? In ClearCase they would just be separate activities and as long as there were no common files there would be no dependencies. For example, maybe I make a change to one program under one activity but then that project gets bumped to a later release and I have to make another change to a different program, I could still send that second activity in to be accepted with the first activity being ignored. If there was some overlap of files between the two then it would take a bit of work to juggle things around but still doable.

From the git reading I've done so far it seems like I might need to do branches for each activity and only move the side branch into my main branch if Kestas has accepted it. Does that sound right?

I'm not sure Alderian, I think you can sync with anyone else's git repo at any time and it'll just prompt you if there are conflicting changes. I use team foundation at work so it's an adjustment for me too, but I think it does have to work differently when things need to branch but still stay in sync

So how does that work if Kestas doesn't want a change and then I make other changes that he does want? In ClearCase they would just be separate activities and as long as there were no common files there would be no dependencies. For example, maybe I make a change to one program under one activity but then that project gets bumped to a later release and I have to make another change to a different program, I could still send that second activity in to be accepted with the first activity being ignored. If there was some overlap of files between the two then it would take a bit of work to juggle things around but still doable.

From the git reading I've done so far it seems like I might need to do branches for each activity and only move the side branch into my main branch if Kestas has accepted it. Does that sound right?

That's how I've read this too.And sadly because it's a real pain for me to develop changes with the "old" webdip-code, and merge them later with my own code and baecause most of my changes won't get in the main webdipcode anyway I stopped creating separate branches for each improvement. That means my features are hard to get back in the main code, but at least for me it's easy to get my install easy updated to kestas new code.

I was actually curious about what changes you had made and was going to download a copy of yours and use kdiff3 to compare it with Kestas' code. In particular how the PM notification was done versus how I was doing it.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum