0

The git repository for an existing open source library looks something like this:

A/              B/              C/
D/              E.txt           F.txt

I need to create a new repository for a new library, beginning with a copy of a subset of this code. For example, I might want my repository to contain:

A/              B/              E.txt

That is, I want the new repo to contain the A and B directories (with their contents) and E.txt unchanged. The new library has no need for C, D or F.txt.

I can see two ways to do this:

  1. git clone the existing repository, then git rm C, D and F.txt.

  2. git init a new repository, then git add the latest versions of A, B and E.txt.

The problem with the first approach is that there will be significant history in the repository for the items which have been removed. This history is irrelevant for the new library. OTOH, the second approach leads to a repository with no history at all!

Which of these approaches is preferable?

Might it be better to create my new repository that contains only the relevant files and only the history for those files? Can this be done (perhaps with git filter-branch)? Would this indeed be better than either of the above approaches?

1
  • My 2 cents: without some of the files, part of the commit history wouldn't make so much sense anymore. I would go with the first option. But I also see this question as primarily opinion-based (at least the first part of the question).
    – Zimm i48
    Dec 28, 2016 at 11:03

1 Answer 1

2

Version history is incredibly useful; I would never throw that away unless forced to, and thus would always start with a clone.

As you say, you can do some heavy rebasing (with filter-branch or otherwise) to remove the other components from the repository. I wouldn't do this for a couple of reasons:

  1. It makes it much harder to pull in updates from upstream.
  2. It makes it harder to contribute patches upstream.
  3. I rarely just browse through the history directly. I usually am looking through the history of a particular file to see why a certain piece of code is the way it is, and if a commit that contains a change there also contains changes to other files no longer in the repo, that's useful context; if it doesn't, then it's just the same as if you had pruned the history.

The only exception I would make is if the parts you don't need make the repository itself much larger, for instance by including a bunch of binary files. In that case it might be a worthwhile trade-off.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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