Hello Luc, Is the git clone url intentional with http? If thats a developer connection I guess it should be protected. (Does it acceot passwords anyway on http?)
Gruss Bernd Am 06.01.2015 22:17 schrieb "Apache Wiki" <wikidi...@apache.org>: > Dear Wiki user, > > You have subscribed to a wiki page or wiki category on "Commons Wiki" for > change notification. > > The "UsingGIT" page has been changed by LucMaisonobe: > https://wiki.apache.org/commons/UsingGIT > > Comment: > Page creation > > New page: > = Overview = > Some of the Apache Commons components use [http://git-scm.com/ GIT] > Source Code Management System instead of [http://subversion.apache.org > Subversion]. > > Both systems allow collaborative development and both systems maintain an > history of file changes. There are however several differences. > > = Distributed Version Control = > Git is a distributed version control system. This means that instead of a > single central repository holding the full history of project > files and numerous clients connecting to it to check out some versions, > Git uses a symetrical view were everyone connecting to the > repository clones the full history and from then on could (at least > theoretically) act as a new server that another user could clone > and so on. Each repository is created by cloning an ''origin'' repository. > Once cloned, the ''origin'' repository is the first > ''remote'' repository known to the clone. It is possible to add later on > several other ''remote'', so a complete web of repositories > can be created. Of course, for collaborative development, some policy has > to be decided and modifications made by one user on its own > cloned repository must be ''pushed'' back to a public repository. > > At Apache, the policy is that the official reference is the one hold by > Apache servers (for example > http://git-wip-us.apache.org/repos/asf/commons-math.git). > Therefore, all users who want to get the latest version known this is were > they should point at to retrieve it, > and developers who have commit access must push their modifications back > to this repository for official publication. > > Distributed version control allow some additional features. > > A first use case is a user who do not have commit access but would like to > contribute something to the project. This user would clone > the Apache ''origin'' repository on a publicly accessible computer where > he would have commit access, then he would commit his changes > there. Once the features are complete, the user would propose to the > project that they import his changes back to the official > Apache repository. In order to do so, he would make his repository > available (even read-only). Then an Apache committer willing to > review the work would declare this repository as a remote for his own > working clone and would ''pull'' the proposed changes. He could > review everything on his computer, and if satisfied could ''push'' the to > the Apache ''origin'' repository, as he has write access > to it. In a way, the Apache committer acts here as a proxy for the > contributor, and makes sure everything is good to include. > > A second use case is an Apache committer working either on a long > experimental stuff not yet ready for publication or working > without internet access for some time (typically during a business trip). > In both cases, the committer would simply commit > his work on his laptop, using the full features of the source code > management system (branches, version comparisons, commits, ...). > Once the experiment is completed or internet access is recovered, the > committer would push his work from the past few hours, days > or week back to official repository, with all independent commits > preserved instead of being forced to push a big blob representing > a tremendous work all at once, which would be impossible for his peer > committers to review. > > A third use case is a user who do not have commit access (and don't want > to), but needs to maintain some local changes. This user > would clone the Apache ''origin'' repository on a private computer, use > Git on this computer to manage his local changes, and from > time to time will merge changes from origin into his clone. This user > would never push anything back. > > = Git References = > > There are numerous references available online for Git. The first one is > the official [http://git-scm.com/book/en/ Pro Git book]. > An Apache specific page is [https://git-wip-us.apache.org/ here] > There is also a wiki at kernel.org: [https://git.wiki.kernel.org/ Git > Wiki Homepage] > > = Comparison with subversion commands = > > We first list a subversion command, and after that the equivalent git > command. > > One of the most important difference from a user point of view is that > since there is always one ''local'' repository and > one or several ''remote'' repositories, there is a distinction in git > between saving some work only locally on a private > computer and making it available to other people who see only public > remote computers. The first action is called ''commit'', > and it is therefore completely different from a subversion commit. The > second action is called ''push''. The equivalent > to svn commit is therefore a pair of two commands, git commit followed by > git push. It is possible to perform several > git commit without doing any git push, which is impossible to do with > subversion. > > * svn checkout <repo-url> > git clone http://git-wip-us.apache.org/repos/asf/commons-math.git > > * svn diff > git diff > > * svn update > git pull > > * svn commit > git commit, followed by git push > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
