Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "CDO/Git"
(10 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | + | '''This page is deprecated!''' | |
− | + | Please refer to [[CDO_Source_Installation]]... | |
+ | ---- | ||
− | |||
− | + | __TOC__<br> | |
− | + | = Configuration = | |
− | + | == Line Endings == | |
− | + | ||
− | + | ||
+ | Make sure your Git system settings contain the property <code>core.autocrlf=true</code>. This is very important so that neither you nor other developers (or the Hudson build) ends up with lots of changed files directly after checkout or, even worse, commit/push wrong line endings. If you don't know how to set this property do not ignore it, ask an expert! Here's a screenshot of the setting in EGit: | ||
− | + | [[Image:autocrlf.png]] | |
− | + | = Common Tasks = | |
− | + | == How to create a patch == | |
− | + | EGit can only create patches describing a single commit. This is inadequate, because it's highly likely that you'll commit many times onto a local branch before you're ready to create a single patch covering that series of changes.<br> | |
+ | <br> | ||
+ | Fortunately Git itself makes patch creation very easy. The most versatile format of its diff command is: | ||
+ | <pre># git diff <commit1> <commit2> > mypatch.txt | ||
+ | </pre> | ||
+ | <br> Where <commit1> and <commit2> can be anything identifying a commit, e.g. a branch name, a tag name, | ||
+ | a SHA1 commit-ID, or 'HEAD'. This creates a patch 'mypatch.txt' describing the differences between commit1 and commit2. (Remember that in Git a commit is a ''snapshot'', not a changeset. Therefore, any two commits can be compared.) There are other ways of using git diff, but this is the most generic way of invoking it.<br> | ||
− | + | <br> | |
− | + | If you're creating a patch for review, then the patch should apply cleanly against ''origin/master''. | |
− | #Develop on a local development branch, committing as often as you like<br> | + | This suggests the following workflow: |
− | #Merge origin/master into your development branch whenever you want, but at least once, right before you create your patch. | + | |
− | #Commit the merge, if it wasn't committed automatically. (Git's default behavior is to commit automatically if there are no conflicts.) | + | #Develop on a local development branch, committing as often as you like<br> |
+ | #Merge ''origin/master'' into your development branch whenever you want, but at least once, right before you create your patch. | ||
+ | #Commit the merge, if it wasn't committed automatically. (Git's default behavior is to commit automatically if there are no conflicts.) | ||
#Run 'git diff' as follows: git diff origin/master HEAD (assuming that your dev branch is checked out, which makes HEAD reference it) | #Run 'git diff' as follows: git diff origin/master HEAD (assuming that your dev branch is checked out, which makes HEAD reference it) | ||
+ | |||
<br> | <br> | ||
− | = How to apply a patch = | + | |
+ | == How to apply a patch == | ||
A patch created by 'git diff' is in the ''unified diff'' format, basically the same as the output format of 'diff -c' | A patch created by 'git diff' is in the ''unified diff'' format, basically the same as the output format of 'diff -c' |
Latest revision as of 12:05, 1 November 2016
This page is deprecated!
Please refer to CDO_Source_Installation...
Contents
Configuration
Line Endings
Make sure your Git system settings contain the property core.autocrlf=true
. This is very important so that neither you nor other developers (or the Hudson build) ends up with lots of changed files directly after checkout or, even worse, commit/push wrong line endings. If you don't know how to set this property do not ignore it, ask an expert! Here's a screenshot of the setting in EGit:
Common Tasks
How to create a patch
EGit can only create patches describing a single commit. This is inadequate, because it's highly likely that you'll commit many times onto a local branch before you're ready to create a single patch covering that series of changes.
Fortunately Git itself makes patch creation very easy. The most versatile format of its diff command is:
# git diff <commit1> <commit2> > mypatch.txt
Where <commit1> and <commit2> can be anything identifying a commit, e.g. a branch name, a tag name,
a SHA1 commit-ID, or 'HEAD'. This creates a patch 'mypatch.txt' describing the differences between commit1 and commit2. (Remember that in Git a commit is a snapshot, not a changeset. Therefore, any two commits can be compared.) There are other ways of using git diff, but this is the most generic way of invoking it.
If you're creating a patch for review, then the patch should apply cleanly against origin/master.
This suggests the following workflow:
- Develop on a local development branch, committing as often as you like
- Merge origin/master into your development branch whenever you want, but at least once, right before you create your patch.
- Commit the merge, if it wasn't committed automatically. (Git's default behavior is to commit automatically if there are no conflicts.)
- Run 'git diff' as follows: git diff origin/master HEAD (assuming that your dev branch is checked out, which makes HEAD reference it)
How to apply a patch
A patch created by 'git diff' is in the unified diff format, basically the same as the output format of 'diff -c'
on a *Nix platform. Eclipse cannot apply such a patch. You'll have to use a "real" patch processor, such
as Git itself, or GNU patch.
With Git, you can apply a patch by invoking Git as follows:
~/my/git/repo# git apply /path/to/mypatch.txt
Or you can apply it with GNU patch as follows:
~/my/git/repo# patch -p1 < /path/to/mypatch.txt