Git maintainer tasks

From Dcmf

{ Git | Git Setup | Git tasks | Git maintainer tasks }

Compiling Git

The easiest way to get git it to use git itself to get git.
git clone git://git.kernel.org/pub/scm/git/git.git
The existing version in /bglhome/jratt/install-sles10 is built use these commands:
make CURLDIR=/bglhome/jratt/install-sles10 prefix=/bglhome/jratt/install-sles10
make CURLDIR=/bglhome/jratt/install-sles10 prefix=/bglhome/jratt/install-sles10 install
The curl devel stuff isn't installed by default, so I had to install it.

Creating new repositories

Creating a personal work repository

Simply choose a directory and run

git init

git init

Creating a hosted (bare) repository

Personal

This is the sort of repository to create if only one person will be adding, but you expect others to pull. To create the repository store, use one of these commands:

git --bare init        # This will create an empty store into which you can push
git clone --bare <url> # This will clone of the url

No, the differences in "--bare" is not a typo. Neither version will have a working directory for the files, which is perfect for a storage/sharing repository.

git

Shared

It is really beyond the scope of this document to describe all possible ways to create a shared public repository—it's not something we will spend a lot of time on. I will document what I do when I do it.

Create a shared public repository

System Setup
The system must have a number of items set up correctly to get the expected results.

which git-shell >> /etc/shells # Ensure that the restricted git shell will work
groupadd git         # Create the git group to own git repos
usermod -G git jratt # add the existing user to the git group
# Add a new user:
useradd -g git -s `which git-shell` -c "Real Name" -m joe

Repository setup
It would appear that changing the default group is a pain. Therefore, I recommend these commands.

cd <dir>
git --bare init --shared=all
chgrp -R git .
find . -type d | xargs chmod g+s
find .         | xargs chmod g+w

Playing along with other SCMs

Importing CVS into Git

This will create/augment a git repository in the current directory. The same command is used for the first time and for updates. It appears to do a good job creating all the branches, but of course merges do not show up. After the import, it is probably a good idea to delete the crufty branches.

Note: make sure that cvsps from /bglhome/jratt/install-sles10/bin is in your path.

git cvsimport -v -d :ext:#USER@cvs02.rchland.ibm.com:/BGP/CVS -k -a bgp/comm

git cvsimport

SVN compatability

There are commands to work with Subversion, but I have not tried them. I understand they work well.

Repository management

Grafting two branches together

It is possible to give two branches a fake common history, even when they are completely disjoint. An example use of this would be to post-facto create branches for vendor-release versions of software such as GA, ARMCI, and MPICH2. If we create the branches now, the changes will not correctly be the descendants of one of the releases. This is shown here.

After setting the graft file with this info, we get a new view.

$ cat .git/info/grafts
    #<commit sha1> <parent sha1> [<parent sha1>]*
    #MPICH2 1.0.4 + mods                     MPICH2 1.0.4
    2a12bd18281e0940565204f9daab2818851c0b69 92f146988d51c63625696f55bbbd435c1fa084df

Given that, we could merge in "MPICH2 1.0.7"

git checkout master
git merge MPICH2

Creating and using submodules

This is, in some ways, a more advanced form of grafting. However these grafts deal with the directory tree and not the history of the project development. It is complicated, but I've rather gotten the hang of it. That being said, it is best to learn by reading these documents, experimenting, and possibly even reading the sh source of git-submodule

Release Management

Creating CSETs

This is my favorite command to create CSET output

git log --numstat --date=local --pretty=fuller --summary --decorate --ignore-space-change --ignore-space-at-eol -M -C start..end

These options are described well on the manual page:

git log