top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Multiple clones of the same remote repo of Git

+1 vote
518 views

Does git get confused if I have multiple clones of the same remote repo? What I mean is that in one clone I've made commits (and pushes), and the other clone hasn't seen them. I seem to have some problems pulling to the clone that hasn't been used for commits/pushes.On the other hand, the pull reports a lots of conflicts, but fetch says it's up to date.

I've been using Windows, and trying out two clients: SourdeTree for the other clone (with commits/pushes) and Giteye with theclone for the pull/fetch problems.

I just wondered if the same username with clones both having and missing commits could confuse Git.

posted Sep 2, 2013 by Anderson

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote
 
Best answer
Does git get confused if I have multiple clones of the same remote repo?

No.
The essense of a DVCS system (Git is a DVCS) is that all repositories are independent and self-contained. Despite this, in many cases it's convenient to make a repository possess some extra knowledge of the other repositories it contacts -- and Git has support for this -- but this does not create any dependencies between the repositories which have such knowledge about each other.

Specifically, a repo which has been cloned records no fact this had happened. Conversely, Git makes every clone "know" what repository it has been created from -- this is to ease the common case where you're likely to contact that same repo again from the clone. But this knowledge is very easy to remove completely, and any repository is able to "know" about any number of repositories, not just about a single one.

What I mean is that in one clone I've made commits (and pushes), and the other clone hasn't seen them.

It's unclear if you're just stating a fact or are actually wondering why this happened. If that took you by surprise then again you have to clearly understand that all Git repositories are independent from each other and new commits only ever appear in them at the discretion of their users -- either when they record new commits or when they fetch (and possibly merge or rebase). In other words, to get new data into a
repository you must either create it by yourself (commits) or fetch it from somewhere else (git fetch / git push).

I seem to have some problems pulling to the clone that hasn't been used for commits/pushes.
On the other hand, the pull reports a lots of conflicts, but fetch says it's up todate.

This is because git pull is git fetch followed
by git merge which is performed against the branch which is currently checked out. So either you have
a wrong branch checked out when doing git pull or you have local modifications, so Git is unable to reconcile these changes with those it is about to bring in when attempting a merge.

Since you have provided exactly zero information about how exactly it went wrong, it's hard to judge more precicely. In a cases like this, it's best to drop into a shell and perform the necessary commands by
hand: this allows you to just copy-and-paste whay you entered and what Git output.

I just wondered if the same username with clones both having and missing commits could confuse Git.

Definitely not.
1. Well, techincally it's possible to "script" a repository using the so-called "hooks" so that a record of some form is done when another Git instance fetches data from this repository. But this would be a
a non-standard setup, and Git itself would not be able to make any use of this anyway.
2. Again, technically a repo might be armed with special hooks which would push changes into another repo after a push happened. Certain mirroring schemes are implemented this way. But again, this is a non-standard setup (which is also pretty complicated to get right).

answer Sep 2, 2013 by Satish Mishra
Similar Questions
0 votes

I work on some files and push/merge them to the remote server. Sometimes I get merge conflicts on those files and have to fix them. That's completely fine. I get that.

What I don't understand is that sometimes during this process I will get merge conflicts in files _I have never touched_. In fact they are in a completely different series of directories to the one I am working on and someone else project entirely. How am I meant to know how to fix these? I dont know what the other developer wanted to do and if they have done it right.

I thought git only merged/pushed the files you have changed? If someone else has changed Group A files on the remote repo, why must I change my local Group A files when I am _pushing _completely different set of Group B files?

Sure, Id understand if I were pulling files down to my local and had to resolve merge conflicts then, but this isn't happening when I push the files up.

Any help or advice is much appreciated. Sorry if I sound frustrated - I am really trying hard to get my head round this whole git thing but its just so weird.

+3 votes

My company is upgrading the laptops and so, they're selling the old ones. The problem is, we've been using the old laptops to access remote git repos and the employer would like to clean all possible traces of repo URLs that have been accessed in these laptops. How do I do this? We used Git Bash and Conemu. Will uninstalling Git Bash and Conemu be enough to delete all repo URL history in the laptops? or are these repo URL never been saved to local disk in the first place?

0 votes

I have a problem with an already committed file into my repo. This git repo was converted from svn to git some years ago. Last week I have change some lines in a file and I saw in the diff that it is marked as binary (it's a simple .cpp file). I think on the first commit it was detected as an utf-16 file (on windows). But no matter what I do I can't get it back to a "normal text" text file (git does not detect that), but I is now only utf-8. I also replace the whole content of the file with just 'a' and git say it's binary.

Is the only way to get it back to text-mode?:
* copy a utf-8 version of the original file
* delete the file
* make a commit
* add the old file as a new one

I think that will work but it will also break my history.

Is there a better way to get these behavior without losing history?

0 votes

I'm about to move the git repository directory from current one: /opt/git to new one: /passdev/git. And I got some question regards how to perform this?

First I will Shut down git and I tried to search online but I can't find any links on how to shutdown git? could you let me know what is the commands on how to shutdown the git?

Next is Copy /opt/git to /passdev/git? Is this the correct way to move the whole installation directory? Next Bring up git, what is the commands to bring up? and also I had find out this link: http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/ is for move the folders on one repository to another repository, so I was wondering since I'm going to move the whole repository folder into different location, so should I using git filter-branch --subdirectory-filter -- --all to move each dirctory in one repo, or I can just using unix commands cp to move the whole repository folder?

...