Beruflich Dokumente
Kultur Dokumente
☰
WineHQ (https://www.winehq.org/)
Wiki (http://wiki.winehq.org/)
AppDB (//appdb.winehq.org/)
Bugzilla (//bugs.winehq.org/)
Forums (//forums.winehq.org/)
(https://www.winehq.org/)
(https://www.winehq.org/)
Search
Page (/Git_Wine_Tutorial)
Discussion (/index.php?title=Talk:Git_Wine_Tutorial&action=edit&redlink=1)
View source (/index.php?title=Git_Wine_Tutorial&action=edit)
History (/index.php?title=Git_Wine_Tutorial&action=history)
Contents
1 Tutorials and guides
2 Set up your Git repository
2.1 Downloading and installing Git
2.2 Cloning the Wine Git repository
2.3 Further configuration
3 Glossary
4 Managing your changes - the simple way
4.1 Committing a change into your local tree
4.2 Seeing where you are and what you've done
4.3 Reverting changes in your working copy
4.4 Undoing commits
4.5 Editing commits
4.6 Editing commits the hard way
4.7 Removing trailing whitespace
4.8 Keeping up to date with WineHQ
4.9 Resolving merge conflicts
4.10 Sending patches: generating a patchset
4.10.1 Adding a cover letter
4.10.2 Updated versions of a patch
4.10.3 Sending the patches using SMTP
4.10.4 Sending the patches using IMAP
5 Managing branches
5.1 Creating a branch
5.2 Navigating branches
5.3 Merging and rebasing branches
5.4 Deleting branches
5.5 Advanced branching
6 Other useful operations
6.1 Picking patches from another branch
6.2 Getting rid of timestamp changes
6.3 Regression testing
6.4 Committer statistics
6.5 Finding who changed what
7 Working with GitHub
7.1 Introduction
7.2 Once you have forked
7.3 Useful morsels
8 Patch stack
9 Annoyances
10 Other Git repositories
https://wiki.winehq.org/Git_Wine_Tutorial#Reverting_changes_in_your_working_copy 1/7
5/13/2018 Git Wine Tutorial - WineHQ Wiki
Jeff Garzik's Git tutorial (http://linux.yyz.us/git-howto.html) (Aug 2008).
A very comprehensive guide to advanced git usage ("branch wizardry and git grandmastery") called Git Magic (http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html) available; despite
the name it also addresses Basic Trickery (http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html) for the beginner's needs.
On git.or.cz, there is a Git crash course for SVN users (http://git.or.cz/course/svn.html) (Sep 2008).
LWN's article on Branching and merging with git (https://lwn.net/Articles/210045/) (Nov 2006 - which is a bit old, but detailed).
Git for Computer Scientists (http://eagain.net/articles/git-for-computer-scientists/), a "quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph" (Jul
2009).
The Git Parable (http://tom.preston-werner.com/2009/05/19/the-git-parable.html) "will take you on a journey through the creation of a Git-like system from the ground up" (May 2009).
Note: To get documentation on a Git command, use git help or man . For example, the following two commands are equivalent:
There is a GitHub mirror at [1] (https://github.com/wine-mirror/wine.git). This may be used to get around an uncooperative firewall, and may also provide faster download speeds anyway (although it is
slightly slower to update).
The clone operation transfers around 500 MiB of data. If all goes well, the output of git config remote.origin.url should be:
and you will have a single branch named "master", which can be revealed by running git branch (https://www.kernel.org/pub/software/scm/git/docs/git-branch.html).
If you don't need/want the entire history, you can use the --depth option (e.g. --depth 1) to limit the number of commits checked out.
Further configuration
If you plan on sharing or committing any patches at all, you should set your name and email address using:
A useful feature of Git is its ability to color the output of various commands (diff, status, branch, etc). To enable colors in all commands that support it, when running them from a terminal:
Particularly useful is the colored output of the git diff (https://www.kernel.org/pub/software/scm/git/docs/git-diff.html) command, as it also highlights trailing whitespace in patches.
Glossary
See also the official Git glossary (https://www.kernel.org/pub/software/scm/git/docs/gitglossary.html).
A commit (or changeset, or revision) is a snapshot of a codebase. Each commit has a name -- its commit id -- which is a SHA1 hash. Commits can have other names (tags, etc). See the
"Specifying revisions" section of the git rev-parse page (https://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html#_specifying_revisions) for details on how refer to commits. The verb
to commit means to create a commit.
A diff is a file describing the differences between two sets of files. They are created with the command git diff (https://www.kernel.org/pub/software/scm/git/docs/git-diff.html). If you have code in
the "before" state, you can apply the patch (with git apply (https://www.kernel.org/pub/software/scm/git/docs/git-apply.html)) and you end up with code in the "after" state.
A patch is a file that includes authorship information, a description, and a diff. They are created with git format-patch (https://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html) and
committed with git am (https://www.kernel.org/pub/software/scm/git/docs/git-am.html). This similar to applying a patch, but it also creates a commit that preserves the original description and
authorship information.
The HEAD (or tip) of a branch is the most recent commit. On its own, HEAD means the tip of the current branch.
master is the main branch. SVN/CVS calls this "trunk".
The parent of a commit is the one before it in the history. (Commits can technically have more than one parent, but the Wine repo avoids using this feature, preferring a linear history.) Given a
commit abcde , its parent is referred to as abcde^ , and its great-grandparent is referred to as abcde^^^ or abcde~3 .
A repository (or repo) is a database storing the source code of every available version of a program, and the author of every change.
A tree is a git technical term meaning "directory" (sort of), and sometimes means the whole codebase of a project ("the Wine tree").
The working copy or working tree refers to the files and directories on your file system, the ones you can see and change with the file manager. The git status
(https://www.kernel.org/pub/software/scm/git/docs/git-status.html) command will refer to changes to these files as "Changed but not updated".
git status
git diff
To then commit all changed files to your local tree, use the git commit (https://www.kernel.org/pub/software/scm/git/docs/git-commit.html) command with the -a option:
git commit -a
https://wiki.winehq.org/Git_Wine_Tutorial#Reverting_changes_in_your_working_copy 2/7
5/13/2018 Git Wine Tutorial - WineHQ Wiki
or:
Commit early, commit often: Your local Git tree is yours. You should feel free to commit patches frequently, as it's not until you mail them in that they have a chance of being committed upstream.
git whatchanged # list of commits, which shows what files were altered
git log # list of commits
git log --decorate # list of commits, with the last upstream commit marked
git log --stat # list of commits, with diffstats
git log --stat -p # list of commits, with diffstats and patches
You can get a list of files that you have changed but have not yet committed using git status (https://www.kernel.org/pub/software/scm/git/docs/git-status.html):
There's a nice tool to view your Git repository named gitk (https://www.kernel.org/pub/software/scm/git/docs/gitk.html), written in tcl/tk. AJ suggests using something like gitk wine-1.0.. to make it
go faster (please note that the trailing .. is important). gitk visualizes both committed and uncommitted changes.
qgit (https://sourceforge.net/projects/qgit/) also provides similar functionality, but in a Qt based interface. It appears to be faster than gitk and has additional features such as an annotation facility to
identify which change introduced each line of a file.
If you prefer using your terminal, "git lol" and "git lola" (https://lwn.net/Articles/390701/) are useful aliases you can add to your ~/.gitconfig file:
[alias]
lol = log --graph --decorate --pretty=oneline --abbrev-commit
lola = log --graph --decorate --pretty=oneline --abbrev-commit --all
If you have a webserver running, git instaweb allows you to view your local tree in your web browser.
Undoing commits
If you want to undo your most recent commit, you can use the git reset (https://www.kernel.org/pub/software/scm/git/docs/git-reset.html) command:
git reset HEAD^ # undo commit, but keep changes to working files
git reset --hard HEAD^ # undo commit, and reset working files as well
git reset --hard HEAD~5 # undo 5 commits
git reset --hard origin # scrap all changes and start all over again
Editing commits
To edit the most recent commit:
To edit earlier commits (or reorder or delete them) use the -i (aka --interactive) option to git rebase (https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html). So if you are interested in altering
the 5 most recent commits use:
This will open your editor, with a list of commits prefixed with pick. To delete a commit, just remove its line. To reorder them, just rearrange the lines. To edit commits, change pick to edit.
Be sure to follow the instructions carefully when doing git rebase -i . Specifically, when you are editing a commit (that you explicitly requested to edit) and are satisfied with the changes, you must
use:
However, when git-rebase -i asks you to edit a commit that you have not requested to edit (e.g. there is a conflict), you must use:
This is quite important - not following this carefully will result in merged patches.
https://wiki.winehq.org/Git_Wine_Tutorial#Reverting_changes_in_your_working_copy 3/7
5/13/2018 Git Wine Tutorial - WineHQ Wiki
Where there are a number of files to amend you are probably better off using:
Where the commit is not the most recent one, but say 5th from the top and you wish to insert a new commit, then you can:
Likewise if you want to delete a commit that is not the most recent one, then you can:
and the commit is gone. You need to checkout all the changed files though and the rebase may throw some errors for you to resolve as it applies later commits.
"It fixes whitespace on all the commits that you've made. I think it's pretty good about merge conflicts due to whitespace as well. I don't know of a way of doing this at commit time though."
This is essential for submitting your patches to the Wine project. Please see this post for more information: https://www.winehq.org/pipermail/wine-devel/2010-July/084870.html
(https://www.winehq.org/pipermail/wine-devel/2010-July/084870.html)
Trailing whitespace is highlighted in the output of the git diff (https://www.kernel.org/pub/software/scm/git/docs/git-diff.html) command when colored output is enabled (more about this in the Further
configuration section).
git fetch
git rebase origin
git fetch (https://www.kernel.org/pub/software/scm/git/docs/git-fetch.html) retrieves new files from the WineHQ Git repository; this should always be a safe operation as it does not change your local file
system.
git rebase (https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html) origin reapplies any local commits you have made onto the latest WineHQ branch. (Technically, it creates a new branch on
'origin', reapplies all the patches in your current HEAD to the new branch, then changes HEAD to the new branch.) Patches already applied upstream will not be reapplied.
A common mistake is to use git fetch by itself. It will only download updates but will not apply them. Another common problem is trying to rebase while having uncommitted changes. One way to fix
this is to:
When you send patches, inevitably, some of your patches will be rejected, while others will be accepted. If you have written a series of patches, but only some of those are rejected, it can be annoying
to reorder them, fix one or two problems and resubmit. The main git tools that you can use to help solve this problem are git rebase (https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html)
and git cherry-pick (https://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html). See here (https://www.kernel.org/pub/software/scm/git/docs/howto/rebase-from-internal-branch.txt) for a
discussion on the Git mailing list about rebasing on local branches.
Applying <patchname>
error: patch failed: <file>:<line>
error: <file>: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merged <file>
CONFLICT (content): Merge conflict in <file>
Failed to merge in the changes.
Patch failed at <msgnum>.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
There are two choices now: resolve the conflict or skip the patch. The file in question will contain conflict markers where the patch failed:
<<<<<<<
[code that caused patch not to be applied]
=======
[what would have been here if the patch had been applied]
>>>>>>>
To resolve the conflict you have to manually merge the code between the conflict markers, leaving the file in a compilable state. After that, run
https://wiki.winehq.org/Git_Wine_Tutorial#Reverting_changes_in_your_working_copy 4/7
5/13/2018 Git Wine Tutorial - WineHQ Wiki
to remove the merge-conflict state and continue with the operation.
Patches can be skipped as follows:
"origin" is short for "origin/master", the default name of the upstream WineHQ branch. One file per patch will be created in the current directory. You can change the output directory with -o
<directory> , for example -o out to save the patches in the out directory.
Important: If you have not read it already, please read Submitting Patches (/Submitting_Patches).
[sendemail]
smtpencryption = tls
smtpserver = smtp.gmail.com
smtpuser = yourname@gmail.com
smtpserverport = 587
If you want to check your patches first (e.g. to alter the subject line), just use the --annotate option to git send-email .
Set up the IMAP server by editing wine/.git/config and adding entries something like this:
[user]
name = "Your Name Here"
email = "your@email.here.com"
[imap]
folder = "INBOX.Drafts"
tunnel = "ssh -C -q user@imapserver.net /usr/bin/imapd ./Maildir 2> /dev/null"
[format]
headers = "To: wine-devel <wine-devel@winehq.org>\n"
The above works for Courier IMAP; for Dovecot, change the [imap] section to something like this:
[imap]
host = dummy
folder = "Drafts"
tunnel = "ssh user@dovecotserver.net /usr/libexec/dovecot/imap 2> /dev/null"
If you would like to send patches directly to your Drafts folder on gmail, change the [imap] section to something like the following:
[imap]
folder = "[Gmail]/Drafts"
host = imaps://imap.gmail.com
user = user
pass = pass
port = 993
sslverify = false
Using Mozilla, sending patches is then just a matter of clicking on "Edit Draft", reviewing the mail and then clicking "Send". If you're using Evolution, you can drag and drop the .patch files into your
drafts folder. Patches in the Drafts folder will have the date and time of the timestamp of the commit, hence if you generate multiple times you will have many copies of the same patch with the same
date and time. This will be the case until you amend the commit and get a new commit timestamp.
Important: Many email clients will alter your email in ways that will prevent them from applying. For example, Thunderbird will wrap emails and send them with 'format=flowed', which will make them
unusable by Git. For Thunderbird, you can follow these instructions (http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email) to send patches. If all else fails, you can add -
-attach to the git format-patch command to send the emails as attachments. Setting up ssh simplifies the patch generation by removing the need to enter a password. Use ssh-keygen to create
your keys and copy ~/.ssh/id_rsa.pub to ~/.ssh/authorized_keys to allow the tunnel to be created without entering a password.
Using local Thunderbird folders, you can use the following approach to add your patches to the Drafts folder (without using IMAP):
Note: Sometimes you have to rebuild the index of the Drafts folder in Thunderbird to see the mails added this way.
Using local KMail folders, you can use the following approach:
Assuming you don't already use procmail to sort your email, you can use the following .procmailrc
:0
/home/username/.maildir/
https://wiki.winehq.org/Git_Wine_Tutorial#Reverting_changes_in_your_working_copy 5/7
5/13/2018 Git Wine Tutorial - WineHQ Wiki
Now, all you need to do is to set up a new receiving account in KMail that collects mail from /home/username/.maildir and filter emails coming in on that account to your drafts folder.
Managing branches
Git branches (https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging) can be useful if you are working on a lot of bugs at the same time. However, they are completely optional
and overkill if you are only working on one thing.
Creating a branch
To create a branch, use git checkout (https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html) with the -b option. For example:
This winds back the working directory to HEAD~5, and forks the history there, creating the branch new-branch. The new branch becomes the current branch.
Navigating branches
Use git branch (https://www.kernel.org/pub/software/scm/git/docs/git-branch.html) to list all branches.
Deleting branches
git branch -D new-branch
Advanced branching
For more information on managing branches in git, see the Git Branches page.
This will create a new commit, but with authorship information from the original patch.
git reset
Regression testing
Regression testing is really easy with Git. It's done with the help of git bisect (https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html) that does all the magic. So all that's left to do is to
compile and test. Even non-developers can do it. See Regression Testing (/Regression_Testing) for instructions.
Committer statistics
To see a list of committers in the last 5 years, sorted by number of commits:
git@github.com:username/wine.git
First, you must check out your new repository. To do so, type:
https://wiki.winehq.org/Git_Wine_Tutorial#Reverting_changes_in_your_working_copy 6/7
5/13/2018 Git Wine Tutorial - WineHQ Wiki
It is advantageous to add the WineHQ Git repository as an upstream repository, rather than the !GitHub mirror. Additionally, we will rebase with this repository to ensure that the HEAD of our repository
is up to date with WineHQ. To do this, use the following commands:
Finally, to update your local branch to match your !GitHub repository, use:
Useful morsels
Output all your patches in the directory out:
Save all your patches as one big file (for your own easy reference/viewing):
Count the number of patches in your repository but not in upstream Wine (useful for keeping track of any disappearing patches):
Finally, if you would like to force commits onto !GitHub (e.g. edited patches), use:
Personally, I (MishaKoshelev) use the following each time I have some new patches that I would like to send to my !GitHub repository. This ensures that all patches are forced, and trailing whitespace
is removed:
git fetch
git rebase --whitespace=fix upstream/master
git push -f origin master
Patch stack
Stacked Git (https://gna.org/projects/stgit) is similar to Quilt (https://savannah.nongnu.org/projects/quilt), just on top of Git. It manages a stack of applied and unapplied patches on top of a Git branch.
Patches can be pushed on the applied stack or popped off the applied stack onto the unapplied stack. The topmost applied patch can be edited and the stack can be rebased onto an updated branch.
This makes keeping around and refining local changesets (changeset->patch) until they are applied upstream much easier. The history of changes to a patch are also kept in Git.
Annoyances
It can be quite hard to get a real understanding of the underlying concepts of Git, and if you are a git newb you are almost certain to run into in a situation where things break and you have no idea how
to get out of the mess. At this point: don't panic! You might be tempted to just trash your repository and manually remerge your patches, but it is very probable you will run into the same situation again
so you'd be better off making sure you have understood how Git works. Look through the list of tutorials at the top of this page.
Hosted By (https://www.codeweavers.com/)
https://wiki.winehq.org/Git_Wine_Tutorial#Reverting_changes_in_your_working_copy 7/7