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

Trace Compass/Rebase Patch From Linux Tools

< Trace Compass
Revision as of 13:06, 22 October 2014 by Alexmonthy.efficios.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This page explains how to "port" an existing patch from the Linux Tools / TMF git tree to the Trace Compass one. Since package names and directories have all changed, a git rebase is not sufficient - almost everything will conflict. Fortunately, there is a way that may save you some time, using git filter-branch.

Some things to keep in mind

If you only modified existing files

You're in luck! The method below should work as-is, correctly renaming the files and such. Make sure you try to compile it afterwards, some imports may be wrong or missing.

If you added completely new files

The new files will not get picked up by the rebase, and will keep their old location and file name. You will have to move them from a org.eclipse.linuxtools.* directory the corresponding org.eclipse.tracecompass.* one.

The process

First checkout the branch with your patch(es) in your local Linux Tools git. Make sure that branch is rebased at least on commit dafacb73e. From here we'll create a second branch on which we will run the filter:

$ cd /path/to/linuxtools/git
$ git checkout mybranch
$ git rebase dafacb73e
$ git checkout -b mybranch-tracecompass

Then we'll run the filter-branch command that was used to create the original Trace Compass git tree:

$ git filter-branch --subdirectory-filter lttng/ -d /run/shm/git -f

(Note that the '-d' part is optional. It allows specifying a temporary working directory. Since the filter-branch operation is heavy on I/O, pointing it to a ramdisk makes it run faster.)

This should have created a completely new branch in your git which should be compatible with the initial commit in the Trace Compass git tree. You can push this directly to your local Trace Compass git:

$ git push file:///path/to/tracecompass/git mybranch-tracecompass

or if you prefer, you can use git format-patch to generate patch files, and git am to apply them.

Now the fun part, cd to your Trace Compass git tree and attempt to rebase it to its master:

$ cd /path/to/tracecompass/git
$ git checkout master && git pull // making sure your local master is up to date!
$ git checkout mybranch-tracecompass
$ git rebase master

You may get some merge conflicts here and there. They may be simple enough to fix during the rebase. If you get a lot of complicated conflicts, it could be easier to just rewrite the patch from scratch on top of the latest master. No matter the result, remember to always double-check the contents of your new patches (and test them!) before pushing them to the Trace Compass Gerrit. Some weird git artifacts can slip in sometimes.

Most common conflicts / tips when rebasing

This section explains how to solve the most common conflicts you'll get from rebasing. If a patch both adds new code and modifies existing, first deal with the new code, with the files with less dependency first, then go on to modify existing code.

New code files

As mentioned above, new files will not be renamed during the rebase. You will have to do that manually. One method to do that is first to move to their new location using

$ git mv org.eclipse.linuxtools.<rest of the path> org.eclipse.traceompass.<rest of the path>

Refreshing the workspace in Eclipse will show those files in their new locations. There will be errors to fix:

  • The package location at the top of the file
  • The import files. Just delete them all and Ctrl-Shift-O should resolve them all to their new tracecompass locations.
  • META/MANIFEST.MF may need to be updated if new packages were added.

Make sure you correct all the other errors before committing, but there shouldn't be much left after that.

Conflicts in existing files

When modifying existing files, there usually is no conflicts, except if new imports were added. In that case, many lines of import are in conflit. Deleting the whole conflicting part (both versions) and doing and Ctrl-Shift-O in Eclipse usually solves the problem.

If you are completely stuck, contact us, we may be able to suggest something. Happy rebasing!

Back to the top