Difference between revisions of "Git"
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): | ||
− | + | <syntaxhighlight lang="bash"> | |
− | + | ||
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! | ||
− | + | <syntaxhighlight lang="bash"> | |
− | + | 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 | ||
− | + | 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... | ||
− | + | ==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. | |
Line 39: | Line 92: | ||
− | + | See also [[Mediawiki subversion (SVN) to git migration]] | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + |
Latest revision as of 19:15, 6 January 2016
Contents
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:
- 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.:
- 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
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 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...
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.