1

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?

Omer Rosler
  • 237
  • 1
  • 10

1 Answers1

2

I'd proceed like this.

  • Clone the upstream repo as normal, with history and all.
  • Create a branch in it on top of the master branch.
  • For each separate commit you have to export (likely only the top commit unless you have a useful recent history):
    • Check out that commit in your repo;
    • Copy it to the upstream repo's tree, just as files;
    • Review the change, revert unneeded parts;
    • Make tests pass, etc;
    • Commit the change.

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.

  • Do as above to make a branch with your history in the upstream repo (baseless_branch).
  • Identify the commit where you started your development, and make a new branch on top of it (based_branch).
  • Cherry-pick the range of commits from baseless_branch to based_branch up to the moment where you copied the files from master again.
  • (Optional.) Upon achieving "copied the files" point, merge 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.)
  • Continue cherry-picking (and merging) until you hit the top of 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.

9000
  • 39,899
  • 9
  • 66
  • 104