1

System: git Bash on Windows 10.

For a series of reasons, I have two different GitHub repositories (with the same name) for the same project, from two different users of two different organizations (let's call them John and Doe). I need to incorporate the modifications done by Doe, into John's code. I'm pretty sure merging would work fine and without conflicts:

  • the two repositories have the same directory tree, with identically named files in the same subfolders
  • I haven't thoroughly checked each file (how do you/can you diff two different repositories?), but I'm nearly sure that all modifications made by Doe are successive to the last one from John. Thus there shouldn't be any conflicts, because there shouldn't be any files which have been modified in different ways by John and Doe.

I've never been in a situation where I need to merge the code from repositories of different users: I can't add Doe as a contributor to John's repo, but I can clone both repositories in two different folders on my machine. I would like to make as less modifications as possible, and avoid rebase if I can. I thought of two solutions:

Overwrite only the modified files (preferred)

If there's a way to see which files are different between the two repositories, I will only overwrite the different files in John's repository with the modified files from Doe's repository, add and commit changes, and push to John's repository. This is the solution I'd prefer, but I don't know how to find which files differ in repositories from different users. It would be great if I could write the paths of the different files to a file - this way I could write a script to overwrite those files automatically, instead than having to copy them by hand.

Overwrite all John's files with Doe's file (brute-force solution)

If it's not feasible and/or practical to find which files are different between two repositories, I can just copy all folders (except for the .git folder) from Doe's repository into John's repository. Since folders and files are identically named, all files (even the identical ones) will be overwritten, and when committing changes I guess git will identify all files as modified. This works, but I don't like it: a third person looking at the commit history will have the impression that all files have been modified because of this commit, while actually very few files have.

I can't think of anything else, but I'm open to other solutions, of course.

DeltaIV
  • 4,773
  • 12
  • 39
  • 86
  • 1
    Why haven't you tried both first? For the first option, a tool like Beyond Compare would be ideal. For the second, overwriting a file with a file with the same contents isn't registered as a change, because Git only records the filename and the contents, no other attributes. Or better even, if there were no other changes, create a patch from the commits done to the first repo and apply it to the other. – CodeCaster Mar 15 '18 at 10:22
  • @CodeCaster thanks for the tip! I haven't tried them because I'm not familiar with Git (I don't even know what's this patch you're talking about :-) and I was afraid I could only find out if all files had been changed at push time... one thing I know for sure is that once you push, eliminating a commit from the remote folder is impossible (or simply too hard for me). If Git is smart enough to recognize files that have identical contents, then solution 2 is the simplest & fastest! Will do right now – DeltaIV Mar 15 '18 at 10:28
  • 1
    You can always do a `git status` to see what's changed and `git reset --hard` to lose all (!) changes since the last commit. Or better even, if you're unsure, test all this on a copy of the repo first. – CodeCaster Mar 15 '18 at 10:30
  • 1
    Fantastic! It worked! And thanks for `git status` - I owe you a beer :-) – DeltaIV Mar 15 '18 at 10:35

0 Answers0