GitPhraseBook: Difference between revisions
No edit summary |
No edit summary |
||
Line 11: | Line 11: | ||
* [http://eagain.net/articles/git-for-computer-scientists/ Git For Computer Scientists] | * [http://eagain.net/articles/git-for-computer-scientists/ Git For Computer Scientists] | ||
* [http://www.google.com/search?q=git+documentation&ie=utf-8&oe=utf-8&aq=t Google Search] | * [http://www.google.com/search?q=git+documentation&ie=utf-8&oe=utf-8&aq=t Google Search] | ||
== Setup == | |||
== Getting the data == | === Getting the data === | ||
git clone git://git.openembedded.net/FIXME openembedded.git | git clone git://git.openembedded.net/FIXME openembedded.git | ||
== Upgrading your data (lurking) == | === Upgrading your data (lurking) === | ||
git pull --rebase | git pull --rebase | ||
Line 25: | Line 27: | ||
ssh-keygen -t rsa -- send the resulting link to koen, mickeyl and zecke | ssh-keygen -t rsa -- send the resulting link to koen, mickeyl and zecke | ||
=== Checking out a branch === | === Checking out a branch === |
Revision as of 15:40, 8 October 2008
Git Phrase Book
NOTE: For increased pleasure use git 1.5 or later.
Pointers
There are plenty of good git tutorials on the net. A small collection of links can be seen below:
Setup
Getting the data
git clone git://git.openembedded.net/FIXME openembedded.git
Upgrading your data (lurking)
git pull --rebase
This command will fetch new objects from the server, and try to put your local changes on top of the newly fetched revisions for your current branch. If you have no local revisions you will still be updated.
Generating a ssh key
To be able to push to the OpenEmbedded git server you will need to have the right permissions. This starts with having your public ssh key on the server. Generate a key and send it to the right developers.
ssh-keygen -t rsa -- send the resulting link to koen, mickeyl and zecke
Checking out a branch
git branch -a -- See which branches are available git checkout -b local origin/remote -- In theory create a branch and sswitch git checkout -b org.openembedded.dreambox origin/org.openembedded.dreambox -- you will now be in the dreambox branch and track this.
Configuring your tree for commits
git config user.name "Your Name" git config user.mail "you@name"
Doing things with git
Making your changes (old way)
git add your/new/file -- if you have new files git commit -a -- Commit everything
Making your changes (better way)
git add your/changed/files git commit
Making your changes (a cool way)
git add -i git commit
Ammending to your changes
You forgot something, no big deal, change the commit
git add your/others/changes git commit --amend
Commiting someones else work
git commit --author "Other One <other@one>"
Interesting commands
git fetch -- fetch new revisions from all remote repositories git branch -- show you local branches and which branch you are in git branch -a -- show you all branches git checkout -b MYNAME origin/THEIRNAME -- create a branch and switch to it git push origin org.openembedded.dev -- upgrade a branch
When you are committing someone elses work verbatim:
mtn pull mtn update mtn commit <files> --author <email of original author>
The commit message has to follow this layout:
<package name> <version>| <package category> | <configfile/class name>: <summary> { - <detail 1>
- <detail 2>}*
Example 1:
vi packages/gaim/gaim.inc mtn pull mtn update mtn commit packages/gaim/gaim.inc
should have a log message like this:
gaim: make sure do_install does its job in gaim.inc
- install lib to ${libdir} instead of /usr/lib
- remove executable bits from docs
Example 2:
diff /tmp/foo.c /oe/work/gtk+-2.8.4-r0/gtk+-2.8.4/src/foo.c > gtk-2.8.4/fix-foo.patch vi gtk+_2.8.4.bb mtn add gtk-2.8.4/fix-foo.patch mtn pull mtn update mtn commit gtk-2.8.4/fix-foo.patch gtk+_2.8.4.bb
should have a log message like this:
gtk+ 2.8.4: add patch for buffer overflow
Note: Make sure you do 'mtn update' before 'mtn commit' since this reduces the possibility of multiple heads.
Backing out the commit you've made: (You'll need to find the revision ID for this. Use mtn log|less)
This will remove all changes you've done, returning the file(s) to the state they were before you edited them.
mtn --db=OE.mtn --branch=org.openembedded.<branchname> disapprove 5c1a5813e0f66a0d10515ba6fecafbebfe679c7f
Updating
It is assumed that the database is in the current directory and named OE.mtn and the checkout tree is in the org.openembedded.dev in the same directory. Specifying the server name is optional after the initial pull.
mtn --db=OE.mtn pull monotone.openembedded.org org.openembedded.dev cd org.openembedded.dev
The database now contains all upstream changes. You can review the incoming changes as follows:
mtn diff -r `mtn automate get_base_revision_id` -r `mtn automate heads`
Update your local checkout:
mtn update
Pushing your changes upstream:
cd org.openembedded.dev mtn pull mtn merge mtn push
Set default branch and server on push (this is especially needed if you download the database snapshot and want pushing to monotone.openembedded.org):
mtn push --set-default <server> org.openembedded.dev
http://www.venge.net/monotone/docs/Tutorial.html contains lots of useful examples. Working on multiple branches
If you have checked-out different branches, the default settings (set on first checkout) stored in your database may not fit for other branches. You may need to reset vars in order to be able to pull updates in other branches' local copies. For instance, to continue work on org.openembedded.oz354x instead of org.openembedded.dev :
mtn set database default-include-pattern org.openembedded.oz354x
You can check default settings with :
mtn list vars
Some additional guidelines:
* If you have multiple trees / databases, make sure you synchronize them with the upstream tree before pushing or we'll end up with multiple branch heads * Don't forget to update your working copies after pulling * If you are responsible for multiple branch heads, feel responsible to merge them using 'mtn merge' * Install 'meld' of 'kdiff3' on your PC, this eases 2-way and 3-way merging