Charles
Charles

Reputation: 11479

How to use git to track changes in another directory?

I'm working on a project where I have access to the code but can't add version control to the source directory itself. (The main developer has his own source control, but it's not accessible/comprehensible/etc. for reasons not relevant here.)

To keep my sanity, as well as to track any changes the other developer makes, I'd like to have some kind of version control system set up. (Git is the only version control system I've used since the dark days of VSS, so that's probably what I'll use.)

My current plan is to mirror the existing codebase and initialize git locally. But I'll need to be able to compare my local copy to the actual source when the other developer makes changes.

My questions:

  1. Is this a reasonable strategy?
  2. If so, should I set it up with git init --bare or just git init?
  3. How should I compare my local copy with the actual source? diff -qNr source/ local-source/? git diff --no-index source/ local-source/? Something else?

Upvotes: 2

Views: 1637

Answers (2)

janos
janos

Reputation: 124646

First, a bit of background.

In Git, these concepts are cleanly separated:

  • the Git repository: contains Git's data
  • the work tree: the directory tree in your filesystem where you actually work

When you create a local Git repository with git init /some/path, it creates a Git repository at /some/path/.git, and when you run Git commands inside /some/path and below, Git finds the repository, and assumes the work tree at /some/path.

Now on to your situation:

I'm working on a project where I have access to the code but can't add version control to the source directory itself.

An interesting option for you can be to create a Git repository outside the source directory itself, and set the GIT_DIR (the repo) and GIT_WORK_TREE (the work tree) variables accordingly. For example, if the source directory is at /srv/project, you could do this:

git init --bare /my/projects/repo.git
export GIT_TREE=/my/projects/repo.git
export GIT_WORK_TREE=/srv/project

Then you can cd /srv/project and run Git commands, as if you had a regular Git project in /srv/project (with a Git repository in /srv/project/.git). You can use Git commands as usual, and all the repository operations will be done to /my/projects/repo.git.

In your real Git repository you could use this other repo as a remote, and use Git operations to make comparisons with your own branches.

I hope this helps.

Upvotes: 3

torek
torek

Reputation: 488143

The standard solution to this problem is to treat the incoming code as a "vendor branch". Simply create the vendor branch (as an orphan, unrelated branch with no code in it, or in a separate repository), add the initial version and commit. When you get an update, put that in the vendor branch (or vendor repository) and commit as usual.

To treat the vendor version as a separate repository, you can use submodules (this is actually their intended use case, as far as I can tell).

Upvotes: 2

Related Questions