| So, the script now seems to be working, and I added a few commits to my branch to make the build work again (it builds both the new code and the legacy code). The Elasticsearch 2 build will fail, obviously, since the Search 6 POC targets ES 5 and has no support for dialects yet, but that's just temporary. In order for the merge to be clean, there is more to do, most notably merge the dependency management from legacy/pom.xml to pom.xml, convert the distribution module to include all artifacts (new and legacy code) and merge the two versions of the "shared-test-resources" modules.
But at least it works, and we can play around. In short, the script will:
- prepare the two branches, most notably by renaming packages in the Search 6 POC branch to not mention the "v6poc" package
- move most code to the legacy/ directory in the Search 5 branch
- merge the Search 6 POC code into the Search 5 branch
There are two methods available to do this, both producing the exact same file tree, but a different git history:
- By default (mainly because it's much faster), no history rewriting will be performed, even on the Search 6 POC branch. We will append commits to each branch to prepare it for the merge. This means in particular we will add a massive commit to perform the removal of the "v6poc" package in the Search 6 POC branch, moving every single Java file to a different directory.
- With the "-r" option, history rewriting will be used as necessary on the Search 6 POC branch. This means in particular that the package changes will be applied to the whole history (resulting in a history where the "v6poc" package never existed), and that the Search 6 POC branch will be rebased on top of the Search 5 branch before merging.
In case it's not obvious: the Search 5 history will *never* be rewritten. This history is public, has been for a long time, and we don't want to mess with existing clones and forks. Both methods will involve file moves (be it only because we will have to merge back Search 5 files into Search 6).
This means the full history of a particular moved file will only be visible when using "git log --follow – <file>",
or "git log – <file>' with the right configuration option: "git config --global log.follow 1".
IDEs (at least IDEA) enable the "--follow" option by default when looking at the history of a file. However, the methods differ subtly in how history will look like after the merge. Comparison of the two methods Pros of the "rewritten history" method:
- Preserves history for files copied from Search 5 to the POC: with "--follow", most files in Search 6
that were copied from Search 5 will have Search 5 commits in their history ("git log").
- Does not involve any file renaming commit for files created in the POC:
their full history will be visible even without "--follow".
Pros of the "appended commit" method:
- It's much faster, so it's ideal when testing.
- It doesn't change the commit IDs.
Topology of the resulting Git history Essentially, the "appended commit" method will result in this history:
But the rewritten history method will result in this history:
See for yourself You can find the result of executing the merge with each method on my repo:
In a few commands:
cd <your local clone of hibernate-search (not the POC)>
git remote add yrodiere git@github.com:yrodiere/hibernate-search.git
git fetch
git checkout HSEARCH-3179
git checkout HSEARCH-3179-norewrite
The result is best viewed in your own local copy, with git log --graph or a tool such as tig (press "G" to enable the graph mode). In particular, compare the output of this command on each branch:
git log --follow backend-elasticsearch/src/main/java/org/hibernate/search/backend/elasticsearch/client/impl/DefaultElasticsearchClient.java
In one case you'll have the full history, including Search 5 commits, but in the other you will only have Search 6 commits. |
