4

Before anyone says this is a duplicate, most answers tell me to first clone the remote repository, which means that on Machine2, I should not have had the project in the first place.

What I did in the first place was - from Machine1 containing Project X: git init, git commit -am "Initial Commit", (setting up remote not shown for brevity), then git push -u origin master.

However, on Machine2, I have the exact same Project X, except without the .git files and folders. Now, I want to set up Machine2://Project X to also pull and push to the same remote repository. Should I set up git on Machine2, then commit, then pull? I'm not sure what the right thing to do is for what I'm asking.

Here's what I've done, which I think works, but is tedious, or possibly wrong. I want a shorter and better way.

  • git init, git -am "Initial Commit Machine2"

  • git pull [remote repo url]

When I typed git log --oneline, I noticed that there's the most recent commit called "Merge [remote repo url]", then the commit I created, "Initial Commit Machine2", then the repo's commits in the expected descending order. I didn't want to include the Machine 2 commits, so,

  • git reset --hard [SHA of the latest commit from the remote repo as obtained]
  • made some code changes (like adding comments for testing)
  • git commit -am "Adds clearer comments on classX.cs"
  • git remote add origin [remote repo url]
  • git push -u origin master

From Machine1, I was able to pull the changes committed/pushed from Machine2, which is what I want.

This just seems so tedious especially that I have quite a few repositories to sync between the two machines.

Mouloud85
  • 3,826
  • 5
  • 22
  • 42
Mickael Caruso
  • 8,721
  • 11
  • 40
  • 72
  • Can you just copy and paste all source files and directories from Machine 1 into Machine 2? In doing so, it will also copy the hidden .git directory (which is where the repo history is stored) and you'll be up and running right away. You'll just need to make sure that Machine 2 has either an SSH key to connect to the repo server, or a valid user/pass. – trnelson Oct 25 '14 at 04:56
  • I read your post 5 times and I am still not sure how any answer other than "first clone the remote repository" is correct. – Andrew C Oct 25 '14 at 05:04

3 Answers3

2

I had a similar situation: all the source except the .git directory. This worked for me:

git init
git remote add origin ssh://...
git fetch
git add .
git checkout master

This way, there is no commit required.

Also, instead of reset, you can

git checkout -f master
Peter J. Hart
  • 367
  • 2
  • 7
1

Maybe an shorter version could work on Machine2:

cd project2
git init .
git remote add origin /url/of/remote/bare/repo
git fetch
git symbolic-ref HEAD refs/heads/master
git status

The git symbolic-ref HEAD refs/heads/master is for "swithing branch without checkout", in order to not mess with the potential local modifications you might have on Machine2.

Then the git status can tell you how your current working tree (which is untouched at this point) differs from the index.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1
git init
git add
git commit
git remote add origin [remote repo url]
git pull --rebase origin master
git push --set-upstream origin master

This will give you the message:

Branch master set up to track remote branch master from origin.
Everything up-to-date

And no history will be sent! (Like the merge history you are seeing)

Note that git pull is actually git fetch; git merge in one command for convenience. You do not want to merge, so you need to pick the rebase strategy git pull --rebase which is actually git fetch; git rebase.

Now you should be up to date. Any changes you now want to make you can make by standard convention.

Note: there is not really a "more convenient" way to do this, as well, this sort of violates the purpose of git. And if Machine B has an exact copy of Machine A, whats the harm of just removing all the files, then doing a clone?

Nick Humrich
  • 14,905
  • 8
  • 62
  • 85