What is GIT

GIT is a distributed source code managemenent tool, written by Linus Torvalds to maintain Linux kernel code. It differs from other since every commit is done locally, and the changes are then pushed on the remote repository.

Start with GIT

Set some variables

You got to set and export some variable, if not, your commit information will be taken from environmental info (like local used and email address):

GIT_AUTHOR_NAME="Sandro Tosi"
GIT_AUTHOR_EMAIL="morph@debian.org"
GIT_COMMITTER_NAME="Sandro Tosi"
GIT_COMMITTER_EMAIL="morph@debian.org"

Of course, customize at your needings.

Create the local repository

  1. extract the upstream sources
  2. git init
  3. git add .
  4. or git add *
  5. git commit
  6. git branch upstream
  7. git tag upstream/revision
  8. and then add the debian directory (in the master branch)
  9. having the upstream sources in the repository makes things really easy, but they should be in a branch on their own

Use an existing repository

It's as simple as

git clone git://server/path/to/code.git

if you use ssh to connect to remove repository, then go with

git clone git+ssh://<username>@server/path/to/code.git

Usually you need to checkout even the upstream branch:

git-checkout -b upstream origin/upstream

(taken from here).

Update the local repository with the remote one

git pull

Update the remote repository with local commit

git push

after a "git commit";

 ??? git push target branch ??? 

Tag

To tag the branch, in plain git you can

git tag

the option -s allows you to sign the tag.

If you use git-bp, then simply

git-buildpackage --git-tag --git-tag-only

(the second switch is optional) and the schema is: <deb version> for the master branch (where the debanization is) and "upsteam/<version>" for the upstream branch.

Note that tags needs to be pushed separately:

git push --tags

Common task maintaining a package with GIT

git-buildpackage

git-buildpackage is the principal tool you'd like to start managing your packages in git: it has a lot of helper tools to archive that task, like for example:

Tips & Tricks

Long commit messages

In case you want a long commit message, write one line as summary then an empty line and then write the long message.

The summary will be shown on shortlog on web summary, and will go into the subject if you create patch mails

Adding file before commit

Before committing (locally) you have to add file to the temporary list of files changes. to do so, you use "git add" and you can pass as paameter the file names (to selectively add some files) or all the changes file with:

git add .
git commit

The above 2 commands are equivalent to:

git-commit -a

that commit all changed files.

Keep debian/changelog in the commit message

With git-bp you can avoid to keep debian/changelog up to date: just keep the git changeset titles informative and run git-dch to create the debian/changelog (right then when the package is ready).

GUI available

use git

4. git diff > patch;

that create a patch to be sent to upstream author; this is the preferred way, anyhow, you can even do:

1. clone
2. edit files & commit,
3. <repeat previous step until you are done>
4. publish your repository somewhere and inform the dpatch maintainer of your repo and ask him/her to pull from yours.

update local working copy

from within the local working dir

$ git pull
Already up-to-date.

TODO: Site references

TO MERGE

<kaeso> morph_: hai già letto http://wiki.debian.org/Alioth/Git ?

<kaeso> se ometti il branch mi pare che pushi tutto (diciamo che io lo uso sempre così, ma non ricordo se è una configurazione particolare qui)
<morph_> kaeso: mh, e target e branch icche' sarebbero? 
<kaeso> morph_: branch è un ramo, di quelli visibili con git branch
<kaeso> morph_: target è una destinazione associata a quel repo
<kaeso> morph_: quando nel wiki fa git remote add alioth ssh:...
<kaeso> alioth è il target, che è un'etichetta per la destinazione ssh


<morph_> kaeso: e l'etichetta come la specifica?

<kaeso> morph_: git remote add <etichetta> <destinazione>

<kaeso> morph_: lì è alioth l'etichetta target




<morph_> kaeso: mh, perfetto; direi che grosso modo quello che mi serve per gestire un pacchetto te l'ho chiesto? qualceh consiglio/trucco?
<kaeso> morph_: i vari target vengono memorizzati in .git/config

<kaeso> morph_: per un riscontro grafico puoi usare gitk
<kaeso> oppure giggle che è più figo

<morph_> kaeso: si', mi pare che ci sia una sola .git per tutto il progetto, nella home, al contrario di altri tool ceh hanno dir in ogni sottodir,giusto?

<kaeso> morph_: e http://wiki.debian.org/PackagingWithGit ?

<bzed> http://madduck.net/blog/2007.10.03:packaging-with-git/ is confusing but interesting at some points, http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html is also nice to read

<bzed> use git-remote to add this as location for 'origin'
<bzed> now you can use git-remote to add the remote url for 'origin' (that's the default remote target)
<bzed> and then try git push origin master
<bzed> if that works, git-push --tags origin upstream

As far as I understand it, git seems to work as follows,


 * pull/some tag you start with
 * commit
 * commit
 * commit
 * pull from server
 * commit
 * tag release
 * push to server with tag

And the tag is the only thing that is actually crypto signed and commits
are local, only pull/pull moves repository changes to the server -
alioth in our case. Commits are to your local system until a push to server.

In light of this, the best way to work may be to have lots of small
commits and when you are done for the day, and checking there is nothing
conflicting on the server, to tag your day's work as
tosi/debian_version-X, where X is some increasing number, and push
changes to server. I'll do the same with majer/debian_version-X tags.
But if the changes you are doing are just trivial, (like my additional
bug reference number in changelog after last upload), then don't bother
with tagging, just push if you are not going to do more changes for the day.

 * lots of work => crypto tag with tosi/deb_version-X and push
 * tiny total amount of changes => just push.

Pulling from server before doing work may be a good idea too.


Secondly, if you would like to do something radical to the package,
create a new branch and do the work there. Then we'll see how it pans
out in the end and if it good, it just gets merged into master.

git-remote add origin git+ssh://morph-guest@git.debian.org/git/collab-maint/sitecopy.git
git push --all