Bugzilla – Full Text Bug Listing
| Summary: | [releng] stitch ui.workbench fork back into main | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Paul Webster <pwebster> |
| Component: | UI | Assignee: | Paul Webster <pwebster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | aniefer, bokowski, emoffatt, jamesblackburn+eclipse, john.arthorne, kim.moir, remy.suen |
| Version: | 4.1 | ||
| Target Milestone: | 4.1.1 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 349150 | ||
| Bug Blocks: | 328935 | ||
|
Description
Paul Webster
After the Git migration? I think after we've converted both o.e.ui.workbenches to git, as it probably would be easier to stitch them together then. PW This is pretty straight-forward to do, Paul's comment 2 is right. 1) Import both of them into git 2) push --mirror the e4 repo into the the 3.x repo 3) If the SHA-1's at the fork point are identical, you're done! 4) If not (though brownian motion, package rename, etc.) create a graft of from the first commit in e4 back to the parent commit in 3.x. 5) Fast export and re-import to make the graft permanent: git fast-export --all | (mkdir ../repo2 && cd ../repo2 && git init && git fast-import) I did this back in the e4 core.resources days for generating patches to bring e4 head back into line. If at various points 3.x changes have been merged into e4 then you can graft the merge from 3.x into the e4 branch in the git history. The other neat thing you can do is fix-up history where content has been committed into another repository (without moving the ,v files). In CDT, for example, we had a couple wholesale commits to CDT HEAD of code originating from DSF. In the git migration I've grafted the original history back in so that blame and log can help developers see the full context of the migrated code! (In reply to comment #3) > The other neat thing you can do is fix-up history where content has been > committed into another repository (without moving the ,v files). Sounds cool - bringing back the history from "before the mist of time", which in our case is the RCP split that happened for 3.0. Probably too much work for too little benefit though. For now I've created a temp repo containing only our fork: git://git.eclipse.org/e4/eclipse.platform.ui.compat.git We'll experiment with trying to suck this into a branch off of the 3.5 workbench when we forked, or simply pulling it in its own branch and then merging into the 4.2 stream. PW (In reply to comment #5) > For now I've created a temp repo containing only our fork: > git://git.eclipse.org/e4/eclipse.platform.ui.compat.git git://git.eclipse.org/gitroot/e4/eclipse.platform.ui.compat.git James, once I get the compat repo into my platform repo, I have a branch point on master and I have the first commit of my fork. When you say create a graft, do mean like this: http://ben.straubnet.net/post/939181602/git-grafting-repositories PW (In reply to comment #7) > James, once I get the compat repo into my platform repo, I have a branch point > on master and I have the first commit of my fork. If you see a branch point in the DAG then there's nothing more to do. Right. So if the SHA-1's of your e4 repo don't correspond to the SHAs of equivalent commits in the platform, then you can use a graft to change the edges in the graph so that: 3.x repo: ... -> X1 -> Fork_Point -> X2 -> ... e4 repo: ... -> Y1 -> Fork_Point -> Y2 -> ... Where X1 and Y1 have the same content but different hashes due to the import process. becomes ... -> X1 -> Fork_Point -> X2 -> ... 3.x/master branch \-> Y2 -> e4 branch If the repository already looks like the latter (which it will do if the hashes match) then there's nothing more to do. You should probably also check that there aren't any collisions in the date tagging between the e4 and 3.x repo... As git is just a DAG of commits, and all operation operate on this DAG (there's no additional metadata about history - a merge is just a tree-state/commit with >1 parent...), you can use grafts to re-draw the graph between the commits. So you can splice in history in (like we did in CDT), or re-parent a branch from another repo. See also: https://git.wiki.kernel.org/index.php/GraftPoint We should try and graft at 2 points. 2009-12-17 and 2010-03-02 PW (In reply to comment #3) > 5) Fast export and re-import to make the graft permanent: > git fast-export --all | (mkdir ../repo2 && cd ../repo2 && git init && git > fast-import) James, if I make the graft permanent will it effect the content of the commits in that branch? Or is it just changing the parent and the hash? PW (In reply to comment #10) > James, if I make the graft permanent will it effect the content of the commits > in that branch? Or is it just changing the parent and the hash? The answer is it doesn't appear to effect the tree PW I've included org.eclipse.ui.workbench with the eclipse.platform.ui.e4 graduated bundles. I've decided against grafting the history. PW Done with bug 351489 PW |