Difference between revisions of "Git"

From VideoLAN Wiki
Jump to navigation Jump to search
(More about diff-ing.)
(v0.8.6->0.8.6 as our tag follow this naming scheme.)
Line 110: Line 110:
  
 
== Tracking regression ==
 
== Tracking regression ==
git has a great tool called [http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html 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 has a great tool called [http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html git-bisect] to help you to track a faulty commit. Imagine you are tracking a bug that is known to appear after 0.8.6 (assuming 0.8.6 is tagged):
 
  $ git bisect start
 
  $ git bisect start
 
  $ git bisect bad # tell git current version has the bug you are tracking
 
  $ 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
+
  $ git bisect good 0.8.6 # tell git 0.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.
 
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:
 
If it has the bug:

Revision as of 12:11, 13 April 2007

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.

Diff-ing

  • You can diff between two branches using
$ git diff branch1 branch2
  • You can diff between the previous 10th commit and current using
$ git diff HEAD~10 HEAD
  • You can diff between the previous 10th commit and current of the branch "mywork" using
$ git diff mywork~10 mywork
  • Imagine that git log is like
$ git log
commit e0394f269305edd09843257e7c1d1a66aaf48ab3
Author: jb <jb>
Date:   Fri Apr 13 07:14:48 2007 +0000
   qt4 - Mousewheel (2)
commit e80b339081aa6755f67c9bd8e2aacf93a9a79d95
[..]
commit ff7004b70fd239e4120deb160e2991bd5237b8df
[..]
commit a44a594898f981a145cfcace5f16f8973f9eb46f
[..]
commit 690df705c963cf6bf6f5746d54bc97a85ff91919
[..]
commit 679f8b1c3e0baa469efa970588b95a625c595d64
[..]
$ git diff a44a594898f981a145cfcace5f16f8973f9eb46f~2 e80b339081aa6755f67c9bd8e2aacf93a9a79d95

Will be equivalent to:

$ git diff ff7004b70fd239e4120deb160e2991bd5237b8df e80b339081aa6755f67c9bd8e2aacf93a9a79d95

And to:

$ git diff HEAD~4 HEAD^
  • Remember that to produce a patch you should rather use git-format-patch than git-diff most of the time.

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 0.8.6 (assuming 0.8.6 is tagged):

$ git bisect start
$ git bisect bad # tell git current version has the bug you are tracking
$ git bisect good 0.8.6 # tell git 0.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 Soc trunk

$ git clone git://git.videolan.org/vlc-soc.git
$ cd vlc-soc

Ask for write access to a branch (called your_name_branch). Now we will make git now that you want to publish on this branch

$ git config remote.my_soc_public_branch.url ssh://videolan@altair.videolan.org/home/videolan/gitroot/vlc-soc.git
$ git config remote.my_soc_public_branch.push +your_name_branch # the "+" will tell git to force update ignoring conflicts

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:

$ git push my_soc_public_branch master # tells git to publish branch master to my_soc_public_branch

Now you should be able to see your latest changes in your branch via gitweb.

Documentation about git