1

I have the same folder structure relatively on two different machines.

For instance, I have on machine 1: "c:\user\tryer\myprojects\file.cpp"

and on machine 2: "e:\user\tryer\myprojects\file.cpp" (Note different absolute paths to the same file.)

These two paths refer to the same file of the same project that I sometimes work on from machine 1 and some other time from machine 2.

I synch these two folders over the web via google drive running on both machines independently so that changes to one are automatically synched at the other.

Now, I would like to create a common online source control for this file via github (say http://github.com/tryer/myprojects.git) so that I can use git on either machine. That is, any update on machine 1 to file.cpp should be able to be committed to the online repo, and subsequently any other future update to file.cpp should also be able to be committed to the same common online repo.

From what I have been able to read thus far, while it seems possible to have two different local repositories share the same common online repository, it seems to require to clone afresh from the online repository to machine 2 the initial commit from machine 1, say. But I don't want to do this. I do not want to delete any file or folder locally on any machine, but still have the same online repository that is shared and common and accessible from either machine.

Is there a way to accomplish this? My worry is that if I do the first commit from machine 1, then something with an absolute address for machine 1 or something specific to machine 1 is stored online, and hence creates a conflict later when updating the online repo from machine 2 which has a different absolute address for the same file.

Tryer
  • 3,580
  • 1
  • 26
  • 49

1 Answers1

1

You don't have to delete anything on machine 2, provided your online repo only include that one file.
On machine2 (save your local file just to be safe)

cd /path/to/local/file
git init .
git remote add origin https://github.com/<me>/<CommonProject>
git fetch
git switch -c master

The OP Tryer reports in the comments seeing an error on the last step (fatal: a branch named master already exists), but that is because the folder from machine 1 and 2 was synchronized, a practice I have often advised against.

Once the folder on machine 2 is initialized, you can then push back to GitHub, and pull from machine1.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Let me try this out. Actually, I simplified the situation a bit in my OP. I actually have an entire folder with project files. `":\user\tryer\myprojects\\"` Do the steps have to be different if it is just a file versus a folder with multiple files in it ? – Tryer Sep 16 '20 at 04:58
  • That would checkout all the files of the repository in that folder. – VonC Sep 16 '20 at 05:11
  • hmm. on machine 2, when I do the last step, I get `fatal: a branch named master already exists` – Tryer Sep 16 '20 at 10:06
  • That would happen only if you had an existing repository. But anyway, try `git switch master` – VonC Sep 16 '20 at 10:17
  • Yes, that "works" in the sense that it does not give any errors. It gives a bunch a files and says Already on 'master'. Should I be worried however that not all files in the initial commit were reported when I did `git switch master`. Have I now simultaneously checked out on both Machine 1 and Machine 2? Now, on machine 2, if I make any changes and commit it, should I repeat the above steps on machine 1 so that I am now working on the checked out version of the stuff that was committed from machine 2? Thanks for your help in getting me to understand exactly what is going on! – Tryer Sep 16 '20 at 10:31
  • Can I have your thoughts on " Git isolates fetched content from existing local content; it has absolutely no effect on your local development work. " from https://www.atlassian.com/git/tutorials/syncing/git-fetch ? I thought by doing the steps above, I am actually working on the local stuff on machine 2 that is "live" (in the sense that it is in the actual project subfolder) and not a copy fetched into some other subfolder. – Tryer Sep 16 '20 at 10:34
  • @Tryer "Now, on machine 2, if I make any changes and commit it, should I repeat the above steps on machine" : you should push to the remote GitHub repo from machine2 and pull from machine1: that will be enough to get changes from 2 to 1. – VonC Sep 16 '20 at 11:48
  • @Tryer "Git isolates fetched content from existing local content;": it just means you can do a `git fetch` at any time: it won't changes your local files. It will only update remote tracking branches, not your current master branch. A `pull` would change files, because a `pull` fetches *and* merges (or rebases) files from the updated remote tracking branch to your current `master` (for instance) branch. – VonC Sep 16 '20 at 11:51
  • Thank you. I think I figured out why on the last step git complained that the master branch already exists. I pushed from machine 1. That creates a .git folder at the pwd. Then, my google drive automatically synched both machines so that there was a .git in machine 2 itself even though I had not issued a `git init` there yet. I think I am all set now. Thanks for your help. – Tryer Sep 16 '20 at 11:57
  • @Tryer Great, well done! I have still recently advocated *against* syncing git repositories, as in https://stackoverflow.com/a/63772464/6309 (3 days ago), https://stackoverflow.com/a/9030201/6309 (8 years ago), https://stackoverflow.com/a/3633346/6309 (10 years ago). – VonC Sep 16 '20 at 11:59
  • I will look them over. Thanks for your time -- you being one of the members of the rarified group of elites here -- and also a humble one! – Tryer Sep 16 '20 at 12:04
  • @Tryer You are welcome. Thank you for your kind words. I have edited the answer to include the conclusion from those comments. – VonC Sep 16 '20 at 12:26