Difference between revisions of "Git"

From Biowikifarm Metawiki
Jump to: navigation, search
Line 1: Line 1:
 
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
 
* 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 27: Line 25:
 
TO CONTINUE HERE WITH TESTING!
 
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
 +
 +
-----------------
  
 
* Server: Location of binary is /usr/bin/git. Repo location is /var/lib/git/
 
* Server: Location of binary is /usr/bin/git. Repo location is /var/lib/git/
 
* Clients:
 
* 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.  
 
** 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
+
** 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...
 +
 
  
 
'''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.
 
'''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.
  
 +
Some intros to git:
 +
* http://www.mediawiki.org/wiki/Git (see further links there)
 +
* http://git.or.cz/course/svn.html looks good
  
 
----
 
----

Revision as of 22:54, 22 September 2012

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


TO CONTINUE HERE WITH TESTING!

The next decisions are to be:


  • Server: Location of binary is /usr/bin/git. Repo location is /var/lib/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.

Some intros to git:



New mediawiki git notes - LATER MOVE TO MW Maintenance!

Main source: mediawiki.org: Download from Git. See also overview of wikimedia projects in Git.

IMPORTANT CHANGE in comparison to earlier subversion setup: we directly clone all extensions into the /extension folder, instead of cloning elsewhere and then symlinking.

# checkout = cloned with:
cd /usr/share; mkdir mediawiki20; cd mediawiki20
# the normal clone would be named "core" but we purposely rename to phase3; many of our symlinks use "phase3" back from 1.10 to 1.18
git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git phase3
cd /usr/share/mediawiki20/phase3 
rm extensions -r
git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions.git
cd 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
cd /usr/share/mediawiki20/; cd phase3; sudo git pull; cd ../extensions; sudo git pull; sudo git submodule update --init