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="email@example.com" GIT_COMMITTER_NAME="Sandro Tosi" GIT_COMMITTER_EMAIL="firstname.lastname@example.org"
Of course, customize at your needings.
Create the local repository
- extract the upstream sources
- git init
- git add .
- or git add *
- git commit
- git branch upstream
- git tag upstream/revision
- and then add the debian directory (in the master branch)
- 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
Update the remote repository with local commit
after a "git commit";
??? git push target branch ???
To tag the branch, in plain git you can
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 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:
git-import-* to import packages already existing in a git local repo
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:
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).
http://blog.madduck.net/debian/2007.10.03_packaging-with-git SEEMS REALLY GOOD
http://hoth.entp.com/output/git_for_designers.html (alrady read)
link to read to better understand the play
links to view/integrate
http://git.or.cz/course/svn.html git for svn users
http://grigio.org/tag/git (italian, sorry)
http://www.luthi.eu/blog/2008/06/git-for-debian-packaging (basic pkg handling with 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
upstream website: http://git.or.cz/
<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://email@example.com/git/collab-maint/sitecopy.git git push --all