[Commons Wiki] Update of "UsingGIT" by LucMaisonobe

[Apache Wiki <wi...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Commons Wiki] Update of "UsingGIT" by LucMaisonobe

[Bernd <ec...@zusammenkunft.net>]

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" <wi...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>