Difference between revisions of "Git"

From Biowikifarm Metawiki
Jump to: navigation, search
m (Cloning)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
__TOC__
 +
 
Installed through (git-doc not really necessary):   
 
Installed through (git-doc not really necessary):   
* using http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
+
<syntaxhighlight lang="bash">
* http://www.howtoforge.com/how-to-install-a-public-git-repository-on-a-debian-server
+
 
  sudo apt-get install git-core gitweb
 
  sudo apt-get install git-core gitweb
 
  cd /var/lib; sudo mkdir git; # NOT /var/cache/git/ as in some instructions!
 
  cd /var/lib; sudo mkdir git; # NOT /var/cache/git/ as in some instructions!
Line 17: Line 18:
 
  sudo nano /etc/gitweb.conf
 
  sudo nano /etc/gitweb.conf
 
  # to edit: add /git/ in front of gitweb.css etc.
 
  # to edit: add /git/ in front of gitweb.css etc.
 +
</syntaxhighlight>
  
 
Note: git has not access control, i.e. anyone can clone and commit to a repo. Gitosis is no longer recommended, but apt-get gitolite might be working well.
 
Note: git has not access control, i.e. anyone can clone and commit to a repo. Gitosis is no longer recommended, but apt-get gitolite might be working well.
  
 
Note: as of Jan 2012, nginx is not up to serving git directly, the nginx web-dav implementation being incomplete (http://nilvec.com/nginx-and-git-via-http/). We therefore proxy the git directory to apache and setup git for apache. Note that the config is set to share the same apache passwd file between svn and git!
 
Note: as of Jan 2012, nginx is not up to serving git directly, the nginx web-dav implementation being incomplete (http://nilvec.com/nginx-and-git-via-http/). We therefore proxy the git directory to apache and setup git for apache. Note that the config is set to share the same apache passwd file between svn and git!
nano /etc/apache2/conf.d/gitweb
+
<syntaxhighlight lang="bash">
a2enmod dav_fs; /etc/init.d/apache2 restart
+
nano /etc/apache2/conf.d/gitweb
 +
a2enmod dav_fs; /etc/init.d/apache2 restart
 +
</syntaxhighlight>
 +
 
 +
== Git ==
 +
=== Information Commands ===
 +
 
 +
Commands about local or remote git clone or repository:
 +
<syntaxhighlight lang="bash">
 +
cd /usr/share/mw-wmf-clone/core; # path to a git clone
 +
# generally describe local clone
 +
git describe --help
 +
git describe --all # show present checkout
 +
# info about last commit
 +
git show --help
 +
git show --pretty=fuller # one of --pretty=oneline, short, medium, full, fuller, email, raw
 +
# remote infos
 +
git remote --help
 +
git remote show origin # info about remote «origin» (so-called “tree-ish”) from the remote repo
 +
# list local branches (branch is a form of so-called “tree-ish”)
 +
git branch --remotes | sort --version-sort
 +
# list local tags (tag is another form of so-called “tree-ish”)
 +
git tag --list | sort --version-sort
 +
</syntaxhighlight>
 +
 
 +
=== Cloning ===
 +
 
 +
<syntaxhighlight lang="bash">
 +
# get only a single Version with a shallow clone of the history (depth 1) into folder ./mediawiki.1.27.0-wmf.9
 +
git clone --depth 1 --branch wmf/1.27.0-wmf.9 https://gerrit.wikimedia.org/r/p/mediawiki/core.git ./mediawiki.1.27.0-wmf.9
 +
</syntaxhighlight>
 +
 
 +
==TO CONTINUE HERE WITH TESTING:==
 +
 
 +
The next decisions are to be:
 +
* how to set up the server
 +
** through web-dav and apache? many instructions. Most argue against this. First attempt did not work yet. Instructions e.g.:
 +
*** http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
 +
*** http://www.howtoforge.com/how-to-install-a-public-git-repository-on-a-debian-server
 +
** Using gitolite? https://wiki.archlinux.org/index.php/Gitolite http://wiki.dreamhost.com/Gitolite
 +
** Using git-http-backend ? Highly recommended. Needs investigation how to secure user access und nginx. http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
 +
 
 +
-----------------
 +
 
 +
==Infos==
 +
 
 +
Server: binary is /usr/bin/git. Repo location is /var/lib/git/
  
 +
Some intros to git:
 +
* http://www.mediawiki.org/wiki/Git (see further links there)
 +
* http://git.or.cz/course/svn.html looks good
  
TO CONTINUE HERE WITH TESTING!
+
Clients:
 +
* LINUX: /usr/bin/git is the main command. Do ''man git'' to see a list of many git utilities whose names start with ''git-''.  The [http://www.vogella.de/articles/Git/article.html Vogella tutorial] should convince you that most people can get most of their work done with just the main ''git'' command on the command line.
 +
* Windows:
 +
** http://code.google.com/p/msysgit/downloads/list PLUS http://code.google.com/p/tortoisegit/downloads/list '''DID NOT WORK (Sept. 2012, Windows 7)
 +
** Same problem with: http://code.google.com/p/gitextensions/ (which includes installs for msysgit) -- both installs try to write directly into the user folder, like on a unix system. However, under our permissions, the user folder itself cannot be written to (only subfolders like C:\Users\USERNAME\* , but not C:\Users\USERNAME).
 +
** No solution found...
  
  
* Server: Location of binary is /usr/bin/git. Repo location is /var/lib/git/
+
==Managing git users==
* Clients:
+
** LINUX: /usr/bin/git is the main command. Do ''man git'' to see a list of many git utilities whose names start with ''git-''.  The [http://www.vogella.de/articles/Git/article.html Vogella tutorial] should convince you that most people can get most of their work done with just the main ''git'' command on the command line.
+
** Windows: http://code.google.com/p/msysgit/downloads/list PLUS http://code.google.com/p/tortoisegit/downloads/list
+
  
'''Managing git users:''' git is like svn and cvs in many respects. However, every git project actually contains its own repository, and git permits users to synchronize their repositories typically with others that start as a ''clone'' of it, or one it is cloned from. Generally collaboration takes place by synchronizing to a git repository containing one of the clones designated as a master.  This could take place on a single machine via the file system, but the most convenient way is to set up, or use an existing, ''git hub''. Popular public hubs are [https://github.com/ github] which permits only public git repositories, and  [https://bitbucket.org/ bitbucket], which provides for public and limited private hubs. Whether we deploy a hub for biowikifarm  will need some discussion about a number of things, e.g. what is the nature of the resources we mean to collaborate on, will those collaborations typically take place on the collaborator's own machines and need an easy way to synchronize to a master on a biowiki machine, etc.  The latter is the closest analogy to the way svn works, but where git shines is in keeping each users revision tracking in their own local repository (very roughly analogous to an svn checkout), but with complete version tracking of that user's work, later synchronized to another repo, e.g. one on the hub). If all of the projects are meant to be fully publicly readable throughout development, it may make more sense to have masters on github or another public hosting service and have no hub maintenance on biowikifarm. In that scenario, if the resource is meant to be available on the biowikifarm, there would be a biowikifarm git repo on biowikfarm which would be synchronized to the master and if necessary built and deployed on biowikifarm.
+
git is like svn and cvs in many respects. However, every git project actually contains its own repository, and git permits users to synchronize their repositories typically with others that start as a ''clone'' of it, or one it is cloned from. Generally collaboration takes place by synchronizing to a git repository containing one of the clones designated as a master.  This could take place on a single machine via the file system, but the most convenient way is to set up, or use an existing, ''git hub''. Popular public hubs are [https://github.com/ github] which permits only public git repositories, and  [https://bitbucket.org/ bitbucket], which provides for public and limited private hubs. Whether we deploy a hub for biowikifarm  will need some discussion about a number of things, e.g. what is the nature of the resources we mean to collaborate on, will those collaborations typically take place on the collaborator's own machines and need an easy way to synchronize to a master on a biowiki machine, etc.  The latter is the closest analogy to the way svn works, but where git shines is in keeping each users revision tracking in their own local repository (very roughly analogous to an svn checkout), but with complete version tracking of that user's work, later synchronized to another repo, e.g. one on the hub). If all of the projects are meant to be fully publicly readable throughout development, it may make more sense to have masters on github or another public hosting service and have no hub maintenance on biowikifarm. In that scenario, if the resource is meant to be available on the biowikifarm, there would be a biowikifarm git repo on biowikfarm which would be synchronized to the master and if necessary built and deployed on biowikifarm.
  
  
Line 39: Line 92:
  
  
==New mediawiki git notes - LATER MOVE TO MW Maintenance!==
+
See also [[Mediawiki subversion (SVN) to git migration]]
Main source: [http://www.mediawiki.org/wiki/Download_from_Git mediawiki.org: Download from Git]. See also [https://gerrit.wikimedia.org/r/#/admin/projects/ overview of wikimedia projects in Git].
+
# checkout = cloned with:
+
cd /usr/share; mkdir mediawiki20; cd mediawiki20
+
# the normal clone would be named "core" but we purposely rename to phase3; our symlinks use phase3
+
git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git phase3
+
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions.git
+
cd /usr/share/mediawiki20/extensions; git submodule update --init
+
To update do:
+
cd /usr/share/mediawiki20/; cd phase3; sudo git pull; cd ../extensions; sudo git pull; sudo git submodule update --init
+

Latest revision as of 19:15, 6 January 2016

Installed through (git-doc not really necessary):

 sudo apt-get install git-core gitweb
 cd /var/lib; sudo mkdir git; # NOT /var/cache/git/ as in some instructions!
 cd /var/lib/git/; sudo mkdir biowikifarm.git; cd biowikifarm.git; sudo git init; sudo echo "biowikifarm git repository" > .git/description
 sudo git config --global user.name "DEBIANUSERNAME"; sudo git config --global user.email "THENAME@gmail.com"; 
 git config -l ## only to verify, output should be correct name and email
 echo "First test content" > test.txt; sudo git add .; sudo git commit -a
 # change owner so www-data can access:
 cd /var/lib/git; chown -R www-data.www-data .
 cd /var/www/; sudo mkdir git # linking repos into this
 cd /var/www/git; sudo ln -s /var/lib/git/biowikifarm.git biowikifarm
 # copy gitweb.cgi, logo and css files into /var/www/git:
 sudo cp /usr/share/gitweb/* /var/www/git; sudo cp /usr/lib/cgi-bin/gitweb.cgi /var/www/git
 # change /etc/gitweb.conf:
 sudo nano /etc/gitweb.conf
 # to edit: add /git/ in front of gitweb.css etc.

Note: git has not access control, i.e. anyone can clone and commit to a repo. Gitosis is no longer recommended, but apt-get gitolite might be working well.

Note: as of Jan 2012, nginx is not up to serving git directly, the nginx web-dav implementation being incomplete (http://nilvec.com/nginx-and-git-via-http/). We therefore proxy the git directory to apache and setup git for apache. Note that the config is set to share the same apache passwd file between svn and git!

nano /etc/apache2/conf.d/gitweb
a2enmod dav_fs; /etc/init.d/apache2 restart

Git

Information Commands

Commands about local or remote git clone or repository:

cd /usr/share/mw-wmf-clone/core; # path to a git clone
# generally describe local clone
git describe --help
git describe --all # show present checkout
# info about last commit
git show --help
git show --pretty=fuller # one of --pretty=oneline, short, medium, full, fuller, email, raw
# remote infos
git remote --help
git remote show origin # info about remote «origin» (so-called “tree-ish”) from the remote repo
# list local branches (branch is a form of so-called “tree-ish”)
git branch --remotes | sort --version-sort
# list local tags (tag is another form of so-called “tree-ish”)
git tag --list | sort --version-sort

Cloning

# get only a single Version with a shallow clone of the history (depth 1) into folder ./mediawiki.1.27.0-wmf.9
git clone --depth 1 --branch wmf/1.27.0-wmf.9 https://gerrit.wikimedia.org/r/p/mediawiki/core.git ./mediawiki.1.27.0-wmf.9

TO CONTINUE HERE WITH TESTING:

The next decisions are to be:


Infos

Server: binary is /usr/bin/git. Repo location is /var/lib/git/

Some intros to git:

Clients:


Managing git users

git is like svn and cvs in many respects. However, every git project actually contains its own repository, and git permits users to synchronize their repositories typically with others that start as a clone of it, or one it is cloned from. Generally collaboration takes place by synchronizing to a git repository containing one of the clones designated as a master. This could take place on a single machine via the file system, but the most convenient way is to set up, or use an existing, git hub. Popular public hubs are github which permits only public git repositories, and bitbucket, which provides for public and limited private hubs. Whether we deploy a hub for biowikifarm will need some discussion about a number of things, e.g. what is the nature of the resources we mean to collaborate on, will those collaborations typically take place on the collaborator's own machines and need an easy way to synchronize to a master on a biowiki machine, etc. The latter is the closest analogy to the way svn works, but where git shines is in keeping each users revision tracking in their own local repository (very roughly analogous to an svn checkout), but with complete version tracking of that user's work, later synchronized to another repo, e.g. one on the hub). If all of the projects are meant to be fully publicly readable throughout development, it may make more sense to have masters on github or another public hosting service and have no hub maintenance on biowikifarm. In that scenario, if the resource is meant to be available on the biowikifarm, there would be a biowikifarm git repo on biowikfarm which would be synchronized to the master and if necessary built and deployed on biowikifarm.




See also Mediawiki subversion (SVN) to git migration