Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Coffee corner » GIT
Re: GIT essentials [message #24345 is a reply to message #24343] Mon, 11 January 2010 17:19 Go to previous messageGo to previous message
mr_ped is currently offline  mr_ped
Messages: 826
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
Well, the problem is that cloning(branching) with GIT is cheap, while with SVN it will take those 5+min. That's not good.
Then again as almost all U++ devs have limited access to SVN, and only very few people change the core of it (most of them used to old non-SVN way of syncing), they rarely run into conflicts or need of branches. Rest of us work mostly in Bazaar, which are reasonably small projects to rarely need a branch during development, and even then we would more likely create package_2 in bazaar in the very same trunk, mimicking branch behavior.
So I don't think right now there's huge benefit from using GIT.

If Mirek and other core developers have some spare time, it would probably make sense to try it out. If U++ core contributors will grow more in the future, the benefit from switch may be even greater. But right now I personally don't see this as big priority (then again I'm not core dev and rarely contributing even into bazaar, so who cares what I think Smile ).

Also I think if you are proposing this, you should maybe try also design the work-flow model, i.e. how Mirek will remain the master of U++, yet other contributors will submit patches with GIT to him. So once he will want to try it out, he can read some ideas how it should work in U++ community. (because GIT allows many ways of cooperation)


What's puzzling *me* as non-user of git is the "pull". I understand anyone can clone repo, do his changes, prepare public commit (patch) and tell maintainer of project it's really great improvement and he should adopt it. Then comes the "pull" by maintainer from the contributor's repo? So everyone's personal repository has to be on public IP? (I find this unlikely with current U++ contributors)
I know this can be worked around by submitting patches for example trough e-mail, or by letting contributor to instead push into central repo, I'm just asking if I understand this part correctly. I think for really democratic/decentralized development (I'm NOT saying the U++ needs this, I think current way works quite ok right now, maybe in future we will need change, but not yet?) everyone should have his own repo and basically Mirek as site owner will use very likely his own repo to create official distribution, so if he does like something from somebody else, he will pull it and add to official U++. I wonder how well that works in current age of IPv4 and NATs. Maybe I misunderstood something important about DVCS/GIT?
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message icon3.gif
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Very nice icon set collection
Next Topic: Running Linux in a browser
Goto Forum:
  


Current Time: Sun Apr 27 21:38:41 CEST 2025

Total time taken to generate the page: 0.03035 seconds