Reputation: 247
We have some wierd situation with our git repository. The intended workflow was to create our own fork of an open source project with some chnages of our own.
The repo was initially created by copying an open source project files without the history and "it worked". When we wanted to update the underlying open source repo, instead of merging we again copied the files and used a diff tool to resolve manually. This was and is a pain that we really want to end.
We want to finally pay the technical debt and start using git in the intended way. What possible ways can we fix it while retaining our history and finally having the underlying open source's history. Note our project is used as a submodule so we can't create a new repository without serious ramifications.
Is this fixable with some secret features of git and lots of cleverness?
Upvotes: 1
Views: 112
Reputation: 40904
I'd proceed like this.
You will likely have to add a few changes after that to make things work on top of current upstream's master. Commit them, too.
Now you have a branch on top of upstream master which can be offered as a pull request. It's guaranteed to merge cleanly (because it's on top of master, not branched from a earlier commit), it has your changes, it has all tests passing (including tests for your changes).
If you want your previous history for reference, there are a few options.
The easiest: keep it in your current (non-upstream) repo. It's not going anywhere, but you have to e.g. pickaxe your changes in a different repo.
Easy but a bit silly: make a new branch in the upstream repo on top of the first commit (see these instructions), and push all your history to that branch. The downside is that your history is now unrelated to that of mainline at all.
A more painful one: identify points where you touched the upstream, and merge if desired.
baseless_branch
). based_branch
).baseless_branch
to based_branch
up to the moment where you copied the files from master again.master
into your based_branch
with master
at the point where you copied the files. It should merge cleanly because the state is the same. (I don't have a good idea how to identify these commits in master.)baseless_branch
; now merge with master
, review and resolve conflicts, add required changes, etc.Now you have your own branch that grows from the right point in history, optionally with intermediate merge points where it matched the master history. That branch is also a good PR material.
Upvotes: 2