Difference between revisions of "Git"
Pdherbemont (talk | contribs) (Using Git to publish your work (for SoC student?)) |
Pdherbemont (talk | contribs) (Need to pull before push.) |
||
Line 100: | Line 100: | ||
And don't forget to publish your changes: | And don't forget to publish your changes: | ||
-- [[User:Pdherbemont]] This part need to be worked out. We should probably add a SoC user or something. And we have to create a git rep or branch for each student. | -- [[User:Pdherbemont]] This part need to be worked out. We should probably add a SoC user or something. And we have to create a git rep or branch for each student. | ||
+ | Make sure you are think with the test push tree: | ||
+ | $ git pull ssh://videolan@altair.videolan.org/home/videolan/gitroot/vlc-push-test/ master | ||
+ | Send your update: | ||
$ git push ssh://videolan@altair.videolan.org/home/videolan/gitroot/vlc-push-test/ master | $ git push ssh://videolan@altair.videolan.org/home/videolan/gitroot/vlc-push-test/ master | ||
Revision as of 09:15, 13 April 2007
Contents
Basic Git usage
Getting VLC source code via Git
git clone git://git.videolan.org/vlc.git
You can also browse the sources via gitweb.
Configure your local git repository
Tell git your name. (used by mostly by git-commit)
$ git repo-config user.name "Your Name" $ git repo-config user.email "me@example.com"
List the local branch
You can now list your local branch by doing
$ git branch
which should ouput
$ git branch * master
Commit
Now you can start to work on your tree. As soon as you feel you've reached a step in developement you can commit locally your work by
$ git commit -a
or
$ git commit <specific files>
List your commits
$ git log
Keeping your local working branch in sync
$ git fetch origin $ git rebase origin
voilà! Your commit will be re-applied on top of the origin (the svn trunk).
Submitting patches to the vlc-devel
If you have been developing on vlc locally and (still) don't have write access, you can submit all your commit in one shot using:
$ git format-patch -o out origin
which will produce the patches for each local commit in the directory "out". You can also use the git-imap-send command:
$ git format-patch --stdout --attach -n origin | git-imap-send
which will directly produces the emails and store them in a imap mail box, provided that you have properly set up git-imap-send.
Advanced usage
Creating a secondary local branch
If you want to work on a specific project that could require a branch of the trunk, create a local branch of the current branch by doing:
$ git branch mywork
and to actually use it do:
$ git checkout mywork
Then do some commit on it... And you can go back to your original master branch by doing:
$ git checkout master
Revert your non-committed local changes
$ git checkout -f
Undo commit
This will undo the last commit
$ git reset HEAD^
which is the same as
$ git reset master^
(if you are checked-out copy of your tree is master) And also the same as
$ git reset a44a594 # note that there is no need to use the full sha id
if you have:
$ git log commit ff7004b70fd239e4120deb160e2991bd5237b8df Author: fkuehne <fkuehne> Date: Thu Apr 12 18:44:47 2007 +0000 * added sanity flags for future darwin releases and potentionally fixed OSX commit a44a594898f981a145cfcace5f16f8973f9eb46f Author: jb <jb> Date: Thu Apr 12 16:24:49 2007 +0000 Qt4 - MouseWheel support - patch by Sergey Volk.
Tracking regression
git has a great tool called git-bisect to help you to track a faulty commit. Imagine you are tracking a bug that is known to appear after v0.8.6 (assuming v0.8.6 is tagged):
$ git bisect start $ git bisect bad # tell git current version has the bug you are tracking $ git bisect good v0.8.6 # tell git v0.8.6 didn't has the bug
And then git will checkout a certain revision, and ask you to test it. And you simply say whether this version has the bug. If it has the bug:
$ git bisect bad
if the bug is not present:
$ git bisect good
And so on by bisection... At the end git will indicate the faulty commit. Most of the time this tool is really efficient to track regression.
If you can provide a script that test the presence of the bug "git bisect run" will be able to track down the regression by itself. See git-bisect Documentation.
Using Git to publish your work (for SoC student?)
First get the official VLC trunk
$ git clone git://git.videolan.org/vlc.git
Do some work and commit it to your master branch.
$ git commit -a
You can also sync with the trunk (origin) as needed
$ git fetch origin $ git rebase origin
And don't forget to publish your changes: -- User:Pdherbemont This part need to be worked out. We should probably add a SoC user or something. And we have to create a git rep or branch for each student. Make sure you are think with the test push tree:
$ git pull ssh://videolan@altair.videolan.org/home/videolan/gitroot/vlc-push-test/ master
Send your update:
$ git push ssh://videolan@altair.videolan.org/home/videolan/gitroot/vlc-push-test/ master