Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "CDO/Git"
(New page: = 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...) |
|||
| (12 intermediate revisions by 2 users 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 == | |
| − | + | 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. | |
| + | <br> | ||
| − | + | With Git, you can apply a patch by invoking Git as follows: | |
| − | + | <pre>~/my/git/repo# git apply /path/to/mypatch.txt | |
| − | + | </pre> | |
| − | + | <br> Or you can apply it with GNU patch as follows:<br> | |
<pre>~/my/git/repo# patch -p1 < /path/to/mypatch.txt | <pre>~/my/git/repo# patch -p1 < /path/to/mypatch.txt | ||
| − | </pre> | + | </pre> |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
<br> | <br> | ||
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