4

We end up with 2 different repo with different history as two people started their own repo and now time to merge.

Start code is same and just two different git init and remote.

so condition is Developer D1 started and his repo is:

start-> A->B->C->

Developer D2 started and his repo is:

start->Z->Y->X->

Now, It is desired to have common branch for both repo to pull that they can merge their own branch for new work.

Their work is mostly separate with small conflicts which can be resolve manually.

What command or process should be best?

coder007
  • 317
  • 1
  • 5
  • 12
  • Possible duplicate of [How do you merge two Git repositories?](https://stackoverflow.com/questions/1425892/how-do-you-merge-two-git-repositories) – kowsky Aug 30 '17 at 03:52
  • no its different Question. initial SDK is same here. Both desire to have branch which is common and they can merge locally and then push to common branch. – coder007 Aug 30 '17 at 11:05
  • Possible duplicate of [Merge two git repositories of same project](https://stackoverflow.com/questions/33669726/merge-two-git-repositories-of-same-project) – phd Aug 30 '17 at 12:34
  • Have you get the answer which help you solve the problem? – Marina Liu Aug 31 '17 at 05:39

2 Answers2

11

My suggestion:
It can be done in D1's repo or D2's repo:

For D2's side

git remote add [name-for-D1-repo] [D1-repo-url]
git fetch --all
git merge [name-for-D1-repo]/[D1-working-branch] --allow-unrelated-histories
David Guan
  • 4,180
  • 1
  • 25
  • 32
  • 1
    Mostly-trivial typo: that's `git fetch --all`. The `--allow-unrelated-histories` flag is new-ish; if `git merge` rejects it, you simply have an older Git that assumes the flag at all times. – torek Aug 30 '17 at 05:07
0

My suggestion is just to get one of the repo as principal (let's said first-repo), create a branch there (lets said the-other-repo), then dump/copy (no git command, just a plain copy) the tip of the-other-repo in the working directory of the first-repo being the the-other-repo as HEAD, commit the changes, and the merge the-other-repo branch into the HEAD of the "master" branch of the first-repo.

If want to keep the commits history, you could do a rebase.

  • 1
    Yes, that make it working but point here is both want to have history and if possible do not want to get new repo. they just want to continue if possible with their own git. – coder007 Aug 30 '17 at 02:38
  • 1
    Actually you *can* merge two commits with no common base. Git used to do this without warning; now you need `--allow-unrelated-histories` (see [David Guan's answer](https://stackoverflow.com/a/45951036/1256452)). In either case what Git uses as the "common base" is actually the empty tree, so that both branch tips (compared to this synthetic merge base) consist entirely of "add all files". That's sometimes what you want, and sometimes not. – torek Aug 30 '17 at 05:04
  • You are right, I edited my answer to remove that statement ;) Thanks. –  Aug 30 '17 at 05:11