Skip to main content
Jump to: navigation, search

PTP/environment setup/git

< PTP‎ | environment setup
Revision as of 16:46, 3 January 2012 by Tibbitts.us.ibm.com (Talk | contribs) (Documentation)

The transition is currently being planned in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=349695

Documentation

  1. http://www.youtube.com/user/cdtdoug (CDT screencasts - last 7 videos are about GIT)
  2. Working with CDT and git -- How to check out the CDT source code with git
  3. http://wiki.eclipse.org/EGit/User_Guide
  4. http://wiki.eclipse.org/Git
  5. http://wiki.eclipse.org/Platform-releng/Git_Workflows
  6. http://veerasundar.com/blog/2011/06/git-tutorial-getting-started/ - nice beginning tutorial esp. describing local vs. remote repository and a nice diagram of Git Data Transport Commands

Things I Used To Be Able To Do Using CVS

Here are some things that I used to be able to do using CVS, but are either difficult or I can't work out how to do them using Git/EGit

Managing Two Branches

Say I had two branches A and B. If I added a new file (plugin, whatever) to branch A, I'd just commit it then switch over to branch B (I might have two workspaces set up, one with branch A and one with branch B). The I'd use Team>Compare With>Another Branch or Version... and add/replace any changes. Then I'd commit to branch B.

Using EGit, I need to show the history view in branch B then cherry pick the change from branch A I want (assuming it shows in the view, which sometimes it doesn't seem to). The problem with this it that you need the file to exist in the target branch before you can show it in the history view. How do you do it when a new file is added?

Answer: Select the folder or package that should contain the new file and select the history view. In the history view, select "Show All Branches and Tags" (blue arrow icon at top right) and cherry pick as usual.

Creating Patches

If I had some uncommitted changes in my workspace, I could just say Team>Create Patch... to save a patch of the changes. In EGit, it seems you have to commit the changes first. How do I create a patch without committing changes?

Answer: It seems you cannot. I would suggest to commit the change in a temporary/feature branch. Team->Switch To->New Branch Team->Commit

Reverting Changes

If I had a changed file in the workspace, I could just revert it using Replace With... For EGit I don't always get the option? What gives?

Feedback: In what cases does it not work?

Other Questions I Have About EGit

Comparing

I try to compare my local copy of branch A using Compare With>Branch, Tag, or Reference... then selecting origin/branch B from Remote Tracking. However it doesn't show all the changes even though I know they are there. Why is that?

Answer: The most likely reason is that you didn't push (for local changes) or pull (for remote changes). If these changes were made locally and you have committed them but not pushed yet than the changes are only in the local branch B not the remote tracking branch B. In that case you should compare to the local branch B or push before you compare. If the changes were done remote (in a different repository) you need to pull (or fetch) to update the remote tracking branch to the new version. The history view helps visualizing to which version each branch points.

Cherry Picking

If I cherry pick some changes from one branch to another, do I need to commit it? Or is it just done? How do I revert it if need to?

How do I only apply some of the changes from a particular commit? Cherry picking only seems to apply them all.

Answer: Cherry picking a commit automatically commits it to the destination branch (adds a commit with the same commit message). So reverting this commit is the same as reverting any other commit (see below).

Applying only part of a commit is more difficult. In this case, you will need to either apply the changes without cherry picking or cherry pick and reverse the changes not needed. (Note that git works best if commits are small and frequent, with each commit representing a single "logical" change, which may span any number of files.)

After cherry picking, you can right-click on the project and select 'Compare With...' -> 'Previous Revision' to open a Git Tree Compare view and undo any unwanted changes. Then commit these changes with "Amend Previous Commit" selected, so that the cherry pick and these changes are all contained in a single commit.

Reverting Commits

There are two ways to revert commits in git. You can either add a new commit that reverts a previous commit, or you can tell git to reset the branch to a prior commit. The former is much safer, since it functions like any other commit and does not change the revision history prior to the commit. Also, this will only revert the selected commit. The latter operation, however, will erase all trace of all commits after a selected commit. This can be useful for commits that were made in error. However, you should never reset commits that are already pushed to remote. Only use this for recent commits made in your local workspace. Otherwise, you will not be able to push your changes to remote, since our remote server is configured to not allow modifications to history.

To undo commits, select a commit in the history view and right-click. Selecting 'Revert Commit' does the safer option described above. Selecting 'Reset' -> 'Hard' does the unsafe method and will erase all commits after the selected commit.

Merging

For committing changes to both ptp_5_0 and master we use the following policy:

  • All changes which should go both into ptp_5_0 and master should be first committed to ptp_5_0
  • All changes in ptp_5_0 are regularly merged into master (Team->Merge)
  • Any change in ptp_5_0 which should not go into master has to be reverted in master. This should be done immediately to not be forgotten. First ptp_5_0 has to be merged into master and then the one commit, which should not go into master, has to be reverted (using History View->Right Click->Revert Commit)
  • Cherry pick can be used if either a change has been accidentally first pushed to master, or if a commit should also go into ptp_4_1 (whether first committing it to 4_1 or 5_0 doesn't matter)

How to merge changes from a different branch when using a different workspace for each?

Answer: The easiest option is to push from one workspace and pull from the other. It is also possible to setup the other workspace repository as a remote repository to be able to directly fetch.

More information about the merging strategy:

External information to do the individual steps:

Other questions:

If I cherry pick some changes my local workspace seems to be in some kind of merged state (e.g. [org.eclipse.ptp|Merged master]). If I commit, EGit forces me to commit all changes in the workspace, not just the ones I select. I may have changes that I don't want to commit right now. What do I do?

Answer: A merge conflict can occur if both the current branch and the cherry-picked branch have made conflicting changes since they diverged (since their last common commit). This can be resolved using the merge tool, as described in the EGit User Guide.

You should avoid cherry-picking into a branch that has been changed since its last commit, because you then will have to deal with changes coming from two difference sources (the original changes and the changes introduced by the cherry pick). The "git stash" command is useful for handling this case, but it is not yet available in EGit. It allows you to set aside work that has not yet been committed. From the command line, "git stash" will "stash" all changes since the previous commit. You can then work on a different commit, such as cherry picking from another branch. Once you have committed those changes, the command "git stash pop" restores the previous changes.

Yes, it seems that once a merge conflict is resolved, EGit no longer allows you to select individual files to commit. More details to follow...

Notes

  1. In CVS, HEAD means the 'branch' that is the latest most recent main work
    • In GIT, HEAD is the endpoint of a branch. 'master' is the 'branch' that is the latest most recent main work
      • So, there is a HEAD revision of each branch, which is the endpoint (last change).
      • E.g. there is the HEAD of master and the HEAD of ptp_5_0
  2. 'Origin' is the default name of the remote repository on eclipse.org

Back to the top