Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "CDO/Git"

< CDO
 
Line 1: Line 1:
 
'''This page is deprecated!'''
 
'''This page is deprecated!'''
 +
 
Please refer to [[CDO_Source_Installation]]...
 
Please refer to [[CDO_Source_Installation]]...
 
----
 
----

Latest revision as of 12:05, 1 November 2016

This page is deprecated!

Please refer to CDO_Source_Installation...




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:

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.


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:

  1. Develop on a local development branch, committing as often as you like
  2. Merge origin/master into your development branch whenever you want, but at least once, right before you create your patch.
  3. Commit the merge, if it wasn't committed automatically. (Git's default behavior is to commit automatically if there are no conflicts.)
  4. 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


Back to the top