Menu
I've just started using git, and am impressed with the workflow differences from SVN, but I've run into one structural/setup question that the documentation doesn't seem to intuitively explain how to set up, and I'm wondering if it's even possible.
My setup is that I have several computers I do development from (desktop and laptop), so, to more easily keep in sync and provide backup for the git repository, I set up a "public" bare repository on my home Linux server that I can ssh into from both desktop and laptop. It's not really public, since it requires SSH access to the box to get to.
My problem comes when I do changes on my desktop, I can easily push changes to the server repository (I have the mirror flag set for the origin remote on that repository), and using gitx I can see that the local and remote states look identical, and each of my individual commits has been logged to the server.
The question is when I switch to my laptop, which I use rather infrequently, the git repository there is likely several commits behind the server version and needs to be updated. I started using git pull to get those changes local, but rather than duplicate all the individual commits on the server to the local repository, it adds one new 'merge' commit to the local repository, and gitx shows merging in the remote repository branch at that point.
Is there a command/workflow that would let me update the local repository to the exact state of the remote repository (such that if I do a git push --mirror no data would be lost)? Would I have to delete my local repository each time and git clone it again each time?
Currently no one else would need access to this repository, though in the future it might become a public repository for people to pull from, so answers that don't destroy that possibility would be appreciated.
Edit: My commits do include rebasing branches off of the master branch; could that be what's triggering the git pull command to show as a merge? Is the --rebase flag what I need then?
Solution Explanation: It turns out I had done the following to set up my repositories:
Because of that one extra commit that was an unintentional newb mistake, it led me to think that it would always be a merge. On Xentac's suggestion, I went back and found on the laptop that I had made a merge that wasn't pushed to the server, which was the culprit, and once I got all three really in sync, git pull --ff (forcing only fast-forward merges) works just fine, and warns me if something is out of sync before doing the merge.
684
Because you have commits in your laptop's master branch that aren't in your server's master branch, every time the server changes, the laptop can't just update the master branch pointer. That's why you're creating merge commits.
If you want to continue having changes that aren't stored on your server but just stored on your laptop, you'll want to git fetch and then git rebase origin/master. The fetch will download the commits from the server but not change your local branches and the rebase will recreate your laptop's master branch changes on top of the server's master branch (origin/master).
It'd probably be better to not have those commits dangling around though. Can't they be integrated into the whole codebase to just have one common history?
188
I was going to suggest using the --ff flag, but it the man page says that is the default behaviour. You could try git pull --ff and see if it makes a difference.
If you're getting a merge commit, it would suggest that you've got commits on your laptop that aren't on the server.
Is your laptop set up as a mirror of the server, like your desktop is?
21
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
