How to sync two different Git repos without making a commit?

2018-06-15 22:06:05

I was able to sync files from one RepoA to RepoB using 'fetch' and 'checkout' to my master and handling the conflicts (if any). but this approach caused me to make a 'merge-commit' on RepoB.

Is there any way to do it without that commit id being generated? I wanted to schedule all the commits and then sync then on a regular basis through chron-task.

I also looked into git-daemon and post-commit hooks. If this can be done please provide an example.

Initial state of Repos:
Repos的初始状态

After applying merge:
应用合并后

After resetting to last commit (Create File02.txt):
重置为上次提交后（创建File02.txt）

Because of the way git stores and addresses data, a given commit ID can only possibly store one particular tree - which is to say, one set of directories with one set of files with one specific set of content in each file.

(Technically you can argue that this is not true, but realistically it will never happen that two commits with different trees have the same commit hash.)

So when you merge, whether you resolve a conflict or not, unless the result of the merge is exactly the same as one of the original commits (which generally only happens when one commit was an ancestor of the other and fast-forward is allowed), a new commit has to be created.

So when you sync two repos, if that includes syncing branches in which each repo contains changes that the other hasn't yet seen, it is not possible to avoid creating a new commit.

UPDATE - In the comments, a follow-up question was raised: "Can rebase help to alter the commit history in order to conclude with the last commit instead of the final merge-commit?"

While that question could be interpreted a couple ways, the answer is in any case "no". Setting aside warnings about using rebase if any of the repositories involved are shared with other users, it won't do what you seem to be asking of it.

First, understand that rebase does not change the order of commits. It is impossible to change the order of commits. When you do an interactive rebase and change the order of the to-do list, what happens is that completely new commits are created (with a new commit id for each) in order to apply the same changes in a different order.

In fact, by default you might not notice this, but the original commits are still left right where they were before the rebase. (Try tagging HEAD before doing this type of rebase and then run something like gitk --all to see the results.)

The reason you can't reorder commits is similar to the reason you can't merge in changes without creating a new commit ID. Everything about the commit is encoded in the commit ID. That includes its tree as I noted before; it also includes the ID of the parent commit (and so, transitively, the entire lineage of commits that led up to the current commit).

So in general:

If you have a repo and you incorporate new changes into it that previously it did not contian, then every commit that reflects those changes will have a new ID not previously seen in the repo.

If you have two repos, and each of them contains changes that are not in the other, then every commit that reflects the merged changes from both will be a new commit with a new ID not previously seen in either repo.

You can use git pull --rebase , which will rebase your local commits on top of the remote head. You may of course encounter other conflicts you have to fix, but still you won't have any additional merge-commits. You can also git config pull.rebase true in order to always achieve this via git pull . Be aware of a rebase 's consequences though, eg you shouldn't have push ed anything rebase d before.