Let us say there is a project A, and i came across a project EA which extends the project. The problem is project A is not available under version control, it is only available as tarball releases.

The project EA extends A by creating a new github repository and adding new functionality, most of the changes are concentrated in a new subfolder but some rare changes exist in original code of A as well.

Now there is a version 2 tarball release for project A and i want to implement the same extension of EA for the new version.

What is the best gitflow for doing this? If the developer of EA had used submodules i could have just added that, but as is, he is making some changes (Albeit rarely) in the original code (From project A).

I am new to vcs but have read up on the basics of git and submodules, but the only way i can see doing this is create a separate repo, merge changes from EA and manually manage changes whenever EA is changed by it's developer.

  • 1
    This isn't going to help your situation, but the first failure lies with the authors of EA. They should have imported the A releases into a tracking branch into their repository and developed their own EA as a branch off of that. Whenever a new A release comes out, they import the release into the tracking branch, basically as one very big commit, and then merge or rebase (probably the former, since the branches have likely diverged significantly, and the coarse granularity of the tracking "commits" makes automatic rebasing hard). Dec 22, 2016 at 17:05
  • @JörgWMittag Yeah, i was worried that might be the case, i mean i could do it myself, but it is a big project and i really liked the way he was implementing the new additions. Anyway they are not planning on extending to new versions of A, they just probably decided that they will do it for that one version, it was I who wanted to do it for version 2. Dec 22, 2016 at 17:34

1 Answer 1


First, create a new git repository to track A as it is published by A's developers.

Start with the earliest tarball that is relevant to EA, unpack it, and add everything to your repository.

Then for each subsequent tarball until the present, unpack it and add it as a new commit to your repository. You'll now have a branch that tracks the "official" releases of A.

When you've done that, add the repository of EA as a remote to your repository:

git remote add EA <EA github URL>

Fetch from this remote:

git fetch EA

You will now have a single repository with two "branch roots"; one for A and one for EA; you'll have a local branch "master" tracking A and a remote branch EA/master

Create a new branch "mybranch" from your A master at the commit corresponding to the version of A used as the basis of EA:

git checkout -b mybranch some_commit_id

The next step is the important one: you are going to create a merge commit on mybranch merging the tip of EA with the basis version of A.

git merge --strategy=theirs EA/master

After this, mybranch will be identical to the tip of EA but git will know that it comes from applying a set of changes to that version of A.

At this point, you can update to the latest version of A in your repository by merging master into mybranch.

You can track later changes to EA with fetch, and commit subsequent tarballs of A into your master branch. You can then merge them into mybranch again and git should do the right thing.

  • Thanks this seems to be a really great solution, but correct me if i am wrong, i read somewhere that master is supposed to be my main branch, with the latest code, so shouldn't the role of mybranch and master be reversed? Dec 22, 2016 at 21:30
  • @VikashB - You might name the branch tracking A A_track or tarball or something more descriptive, and then you could use master for the name of the merged branch.
    – antlersoft
    Dec 22, 2016 at 21:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.