合并来自git存储库外部的更改

Question

I'm working with another developer on the other side of the country who is the lead on our project, and isn't using a formal version control system. On my end, I'm tracking all of my code in git. I've recently started contributing to the main project, and would like to be able to track updates from the other developer as well.

When I receive his updated code, it's usually in the form of a zip file. If I simply unzip the file into my git working folder, git believes that every file has changed, presumably because the stat info has changed.

What I'd like to see is a way that I can unzip the new code alongside my working copy, and merge in only the changes. What's the best way to do this? As it's a Powerbuilder project, most of the files are binaries.

Thanks!

Answer 1

The binaries, if stored in Git, are bound to create a new version (ie to be taken into account at the next commit).
So: do you need those binaries, or can you rebuild them ?

As for the sources, in Git, SHA1 is king , and since the date of the file (timestamps) is involved in its calculation , since the external set of files can be fairly different in its content (more files, temporary files, files that should be ignored, ...), it would be best to:

• unzip in a separate directory
• use a tool like WinMerge to detect changes based on the content, merge them, and then commit only the files that have actually evolved.
  You just compare the two set of directories and files: the one where you have unzipped the development of your far-away colleague, and the one in which you are currently working.

---

Thanks to rq for pointing out that timestamps are not part of SHA1 computation. Only the:

• type
• size
• content of a blob

are part of SHA1 computation :
_{(source: alexgirard.com )}

However, when importing large set of files externally managed into a git repository, you risk adding new files into git-managed directories, changing their content, hence their SHA1 key, even though old git-managed files have not changed.
That means a lot of changes in tree are artificial if those new files are just temporary files or files that should be ignored/recreated/regenerated anyway.

_{(source: alexgirard.com )}

The above process just ensure an external way to detect what has changed between an external set of files and a git-managed set of file and judge if it has to be part of the git working directory or not.

Answer 2

this, altho not entirely sure a good idea, is what i'm thinking of doing in almost the same situation:

what about basically maintaining a repo for them?

any changes you receive get placed in their repo and committed. then merge their repo, which would be a tracked remote, into yours when you need to?

Answer 3

检查contrib/fast-import/import-zips.py是否contrib/fast-import/import-zips.py您的需求。