Basic Git usage: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
(Initial document (NEEDS MORE WORK))
 
 
(12 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Fundamentals =
= Fundamentals =
== Basic operations ==


Initial checkout:
Initial checkout:
  git-clone git://git.mplayerhq.hu/ffmpeg ffmpeg-git
  git-clone git://git.mplayerhq.hu/ffmpeg ffmpeg-git


Update:
And if you want libswscale as well:
cd ffmpeg-git
git-clone git://git.mplayerhq.hu/libswscale
 
Update (this has to be done in ffmpeg-git and in its libswscale subdir as they are currently separate repositories):
  git-pull
  git-pull


Make some changes, revert to head on master branch:
Make some changes, decide they're bad, revert the changes:
  git-reset --hard HEAD
  git-reset --soft <commit>
 
Make some changes, commit them, decide to revert the commit:
git-revert <commit>


Make a branch:
Make a branch:
Line 16: Line 25:
  git-checkout <name of branch>
  git-checkout <name of branch>


Delete a branch:
Delete a branch (must be merged with HEAD of current branch, keeping the history):
git-branch -d <name of branch>
 
Delete a branch (irrespective of merge status, <b>removing</b> the history):
  git-branch -D <name of branch>
  git-branch -D <name of branch>


To "fix" the last commit/commit message:
git-commit --amend
== Specifying revisions ==
The syntax for specifying particular commits from branches in git is a little complex but is covered in the 'SPECIFYING REVISIONS' section of the git-rev-parse man page. [http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html git-rev-parse html man page]
= Guis and helper scripts =
Main article: [[Git Guis]]
Also see git-*.sh at http://www1.mplayerhq.hu/~reimar/


= Working on a series of incremental, dependent patches =
= Working on a series of incremental, dependent patches =
Line 27: Line 50:
  git-commit -a
  git-commit -a
Prepare patches for e-mail submission (this creates the patches numbered and in order for easy submission):
Prepare patches for e-mail submission (this creates the patches numbered and in order for easy submission):
  git-format-patch origin
  git-format-patch <commit>


Generate a diff of branch 2 against branch 1 (i.e. branch 1 + patch = branch 2)
Generate a diff of branch 2 against branch 1 (i.e. branch 1 + patch = branch 2)
  git-diff <name of branch 1> <name of branch 2>
  git-diff <name of branch 1> <name of branch 2>


Apply a git-diff style patch in a working Git tree:
Apply and commit a git-diff style patch in a working Git tree:
  git-am foo.patch
  git-am foo.patch
Apply a git-diff style patch in any working directory containing the correct source files to be patched:
Apply a git-diff style patch in any working directory containing the correct source files to be patched:
  git-apply foo.patch
  git-apply foo.patch
(Note: git-am will create a new commit using the extra metadata for the commit message, etc. whereas git-apply just patches the files)
(Note: git-am will create a new commit using the extra metadata for the commit message, etc. whereas git-apply just patches the files)
Revert the last n (where n is a positive int) commits from the active branch:
git-reset --hard HEAD~n


= WANTED =
When submitting a set of patches to be applied in order, it is common to want to go back and edit one of the intermediate commits depending on feedback for the patches. This process can be easily achieved using the marvellous git-rebase:


When submitting a set of patches, it is common to want to go back and edit one of the intermediate commits depending on feedback for the patches. This process involves something like:
git-rebase -i <commit preceding the ones in which interested>
* Revert to the commit before the one that needs to be edited.
* Apply the patch without committing, edit the code.
* Commit the new code, make a new patch.
* Merge subsequent commits (the patches that followed).


People have suggested using 'quilt' but I wanted to use Git to see if it could handle such a process. it has been suggested that the following approach should work:
(Note: When using git-rebase, it uses the $EDITOR environment variable so make sure it's set to your text editor of choice.)


HEAD is the state of the code after application of all the patches (i.e. when you ran <code>git-format-patches origin</code>) so we want to revert to the commit before the patch that needs to be edited. You could make a new branch at version HEAD - n:
This will display a list of the commits from the one after that specified and HEAD and gives you the opportunity to remove commits, reorder them, edit them and 'squash' a commit into the one preceding it. When you've edited this list accordingly you should be presented with those commits that were requested to be edited, or need editing, in order. Cool, huh? :)
git-branch <name of branch> HEAD~n


Then switch to that branch:
= Get a hack out of the way =
git-checkout <name of branch>
You probably need a fairly new version of git for this feature.


Reapply the patch without committing (using <code>git-apply</code>, not <code>git-am</code>), edit the code appropriately, then commit again. Then we want to merge in (some of?) the subsequent commits. We can cherry pick the HEAD-n th commit from another branch (not preserving history!) as follows:
To quickly get rid of some local, non-committed changes:
  git-cherry-pick <name of branch>~n
  git-stash
(Note: cherry pick can only apply to a clean branch, that is where there are no alterations since the HEAD commit)


Maybe there is a better procedure but this seems to make sense, even if it seems a little cumbersome.
To get them back again:
git-stash apply

Latest revision as of 09:32, 21 May 2008

Fundamentals

Basic operations

Initial checkout:

git-clone git://git.mplayerhq.hu/ffmpeg ffmpeg-git

And if you want libswscale as well:

cd ffmpeg-git
git-clone git://git.mplayerhq.hu/libswscale

Update (this has to be done in ffmpeg-git and in its libswscale subdir as they are currently separate repositories):

git-pull

Make some changes, decide they're bad, revert the changes:

git-reset --soft <commit>

Make some changes, commit them, decide to revert the commit:

git-revert <commit>

Make a branch:

git-branch <name of branch>

Switch to a branch (make it the active branch such that source files reflect the source in that branch):

git-checkout <name of branch>

Delete a branch (must be merged with HEAD of current branch, keeping the history):

git-branch -d <name of branch>

Delete a branch (irrespective of merge status, removing the history):

git-branch -D <name of branch>

To "fix" the last commit/commit message:

git-commit --amend

Specifying revisions

The syntax for specifying particular commits from branches in git is a little complex but is covered in the 'SPECIFYING REVISIONS' section of the git-rev-parse man page. git-rev-parse html man page

Guis and helper scripts

Main article: Git Guis

Also see git-*.sh at http://www1.mplayerhq.hu/~reimar/

Working on a series of incremental, dependent patches

Edit some files making functional changes. Commit changes locally - prompted for a commit message using $EDITOR to write it

git-commit -a

Edit some files making cosmetic changes and commit again.

git-commit -a

Prepare patches for e-mail submission (this creates the patches numbered and in order for easy submission):

git-format-patch <commit>

Generate a diff of branch 2 against branch 1 (i.e. branch 1 + patch = branch 2)

git-diff <name of branch 1> <name of branch 2>

Apply and commit a git-diff style patch in a working Git tree:

git-am foo.patch

Apply a git-diff style patch in any working directory containing the correct source files to be patched:

git-apply foo.patch

(Note: git-am will create a new commit using the extra metadata for the commit message, etc. whereas git-apply just patches the files)

When submitting a set of patches to be applied in order, it is common to want to go back and edit one of the intermediate commits depending on feedback for the patches. This process can be easily achieved using the marvellous git-rebase:

git-rebase -i <commit preceding the ones in which interested>

(Note: When using git-rebase, it uses the $EDITOR environment variable so make sure it's set to your text editor of choice.)

This will display a list of the commits from the one after that specified and HEAD and gives you the opportunity to remove commits, reorder them, edit them and 'squash' a commit into the one preceding it. When you've edited this list accordingly you should be presented with those commits that were requested to be edited, or need editing, in order. Cool, huh? :)

Get a hack out of the way

You probably need a fairly new version of git for this feature.

To quickly get rid of some local, non-committed changes:

git-stash

To get them back again:

git-stash apply