Re: [patch] datetime_overview.txt

Werner wrote:
> Hi,
>
> On 2/24/2015 13:55, [email protected] wrote:
>> On 2015-02-24 13:34 Werner <[email protected]> wrote:
>>> - create a github account
>>> - fork...
>> I have git local on my machine!
>> In my understandings git is more simpler and easier to use than
>> CVS and SVN.
> It is especially when you have to do 'merge' and friends.
>
> I'll try to start a wiki page, so just short answers below.
>>
>> So I don't understand why do I have such a complex task just to submit
>> a patch? To much work for such simple task. I a little bit shocked
>> about that.
>>
>> Why a fork?
> You need to push to a public repo so git can do a PR.

For the record, PRs are a GitHub concept and feature.  The fork is also 
primarily GitHub. Git itself is designed around pulling and pushing 
changesets from one repository to another, and if you do not have write 
access to the repository you want to push to, then it makes it possible 
to send collections of changesets via email to the owner of the other 
repository, or some other mechanisms to share changes IIRC.  It's that 
last part that the PR system was meant to simplify and automate, and I 
think it has done very well.

>> What is 'origin'?
> When you clone 'origin' is where this clone comes from.
>> 2 pull requests for one patch?
> One PR should be for one 'thing'. Have a look at some of the PR's, some
> contain a one line change, others have changes in many files which where
> done with many commits.
>> ...?
>>
>> I would wonder if git doesn't offer a simpler way. And I don't want to
>> click around on any git-portal. That is not how Mr. Torvalds thougt
>> about using git. It should make the dev process simpler to focus on
>> the real important things.
> It does, but the learning curve is much higher then with SVN or CVS. I
> have used both for my own stuff and it was not a nice experience, with
> git or hg/mercurial ones you have things set up it is easy and much much
> more powerful/flexible.
>>
>> I would offer diff- or patch-files against the original repository like
>> I done in the past with CVS/SVN reps.
>>

Keep in mind that Git (and Mercurial and others) is not a centralized 
version control system like CVS and SVN.  Each and every clone is a 
separate, complete and independent repository.  In fact, in the early 
days of DVCS it was expected that there would seldom ever be a 
centralized "master" repository but rather all developers on a project 
would share all changes with each other directly.  As Werner said, this 
is highly complex but also very flexible and powerful.  GitHub and other 
services have come along and made the idea of having a centralized 
master have some traction again, but because of the flexibility and the 
power of Git it is able to solve some of the tougher problems and add 
even more power to how Git can be used with distributed team members. 
(For example I don't have to give you SSH access to the machine my Git 
repository resides on in order for you to give me changes. Etc.)

Here's another thing that using a DVCS like Git gives me.  I have half a 
dozen or more separate Phoenix clones on my LAN, for different 
development platforms, environments, VMs, etc.  In the past with SVN if 
I made changes on one platform and wanted to test it on another I would 
have to do something like copy changed files from one machine to another 
(error prone), or perhaps use a shared filesystem and and have all the 
machines/VMs access the source tree from there (too slow and I can only 
work on one thing at a time on all platforms), or check-in the partially 
tested/completed files on the one machine so I can check them out on the 
others (that's a Bad Idea for many reasons.)  Instead with Git I can 
make and commit changes on each clone as needed, push branches to other 
machines for testing, commit more changes to it there, push the on the 
branch back to the original machine, and so forth.  When the change is 
finally ready to be made public I push all of the commits on the branch 
to the repo at GitHub.  Or if some experimental thing doesn't work out I 
can just delete my local branches and those changes don't clutter up the 
public repo at all.

>> This wall is to high to make participation of "little devs" possible.
>> That is not what a open project should be.
> I am a little dev, just doing all this as a hobby and it took a bit to
> learn but I wouldn't go back to SVN/CVS for my own stuff.

You might be a little surprised to hear that on another project it was 
decided that we should host it on GitHub because the barrier to entry 
was much lower there than some other tools we were considering, because 
so many people (or at least those we were hoping would contribute) are 
already familiar with GitHub and feel comfortable with the PR process. 
So quit dragging your feet and dive in! ;-)


-- 
Robin Dunn
Software Craftsman
http://wxPython.org

-- 
You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.