All of lore.kernel.org
 help / color / mirror / Atom feed
* Git: Having trouble merging two repositories by interweaving their histories
@ 2013-09-09 21:26 THILLOSEN Andreas
  2013-09-09 23:06 ` Andreas Schwab
  0 siblings, 1 reply; 3+ messages in thread
From: THILLOSEN Andreas @ 2013-09-09 21:26 UTC (permalink / raw)
  To: git

Hi,

I recently stumbled over problems, while trying to merge two
repositories (RepA and RepB) into a single one (RepM).
I must mention that indexed files in RepA are totally distinct from
indexed files in RepB, thus no conflict shall appear.
The problem is that I never manage to get the exact result I'm hoping for:

1] RepM should have the entire commit histories of both RepA and RepB.
2] In RepM, indexed files should be separated in two directories:  DirA
(for files associated to RepA), and DirB (for files associated to RepB).
3] I should be able to bissect easily within the history of RepM, even
for old commits. It implies that if I checkout a particular commit
(initially associated to RepA), indexed files initially associated to
RepA and RepB should get updated (and not only files associed to RepA).
It implies "interweaving" their histories, so that I can get a "state"
of both RepA and RepB around a same time period of time.

For my scenario, I used these kinds of commands (from a git bash
launched within an initialized repository RepM):

git remote add RepA /path/RepA
git fetch RepA
git checkout -b RepA/master
git merge -s recursive -Xsubtree=DirA RepA/master

git remote add RepB /path/RepB
git fetch RepB
git checkout -b RepB/master
git merge -s recursive -Xsubtree=DirB RepB/master

With these commands, only my first point 1] is satisfied (I can see the
full history associated to RepA and RepB).

If I checkout RepM to an old commit, the files indexed by RepA or RepB
are updated by ignoring the directories DirA and DirB (point 2] is not
satisfied).

Moreover, only files associated to either RepA or RepB (depending on the
origin of the commit) get updated (point 3] is not satisfied).
In history, commits from RepA are all appearing at the beginning, and
commits from RepB are appearing at the end (they are clearly being
separated).
Should "rebase" help me to solve this? With what kind of parameters?

Greetings,

Andreas THILLOSEN.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Git: Having trouble merging two repositories by interweaving their histories
  2013-09-09 21:26 Git: Having trouble merging two repositories by interweaving their histories THILLOSEN Andreas
@ 2013-09-09 23:06 ` Andreas Schwab
  2013-09-10  0:19   ` THILLOSEN Andreas
  0 siblings, 1 reply; 3+ messages in thread
From: Andreas Schwab @ 2013-09-09 23:06 UTC (permalink / raw)
  To: THILLOSEN Andreas; +Cc: git

THILLOSEN Andreas <thillosen@free.fr> writes:

> It implies "interweaving" their histories, so that I can get a "state"
> of both RepA and RepB around a same time period of time.

This is only possible by rewriting every commit to point to a new tree
containing the combined trees of the two repositories.  To get a
meaningful result this requires that both repositories have a completely
linear history.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Git: Having trouble merging two repositories by interweaving their histories
  2013-09-09 23:06 ` Andreas Schwab
@ 2013-09-10  0:19   ` THILLOSEN Andreas
  0 siblings, 0 replies; 3+ messages in thread
From: THILLOSEN Andreas @ 2013-09-10  0:19 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: git

Le 09/10/13 01:06, Andreas Schwab a écrit :
> THILLOSEN Andreas <thillosen@free.fr> writes:
> 
>> It implies "interweaving" their histories, so that I can get a "state"
>> of both RepA and RepB around a same time period of time.
> 
> This is only possible by rewriting every commit to point to a new tree
> containing the combined trees of the two repositories.  To get a
> meaningful result this requires that both repositories have a completely
> linear history.
> 
> Andreas.
> 

Thanks for your answer...

I searched a little more around the web, and found some trick called
"grafting repositories".
But examples were all of the same kind: They supposed that all commits
in RepA were done before commits in RepB. For instance:

http://stackoverflow.com/questions/2428137/how-to-rebase-one-git-repository-onto-another-one

This is not my case, because I had work done in parallel in both
repositories.
So I'm not really sure that "grafting" could help in my particular case...

To make the graft permanent, they use git filter-branch, which rewrites
history (all SHA1s are changed etc.)... but as long as dates could be
kept, it would not annoy me that much.

I also found a script called git-stitch-repo in CPAN... I have not yet
tested it, but it is reported that it only works on repositories with
linear history (no merges):
http://search.cpan.org/~book/Git-FastExport-0.09/script/git-stitch-repo

This is also not my case: Merges have been done regularly on my two
repositories...

There is also this tool: CombineRepo... no idea how reliable it is, or
what limitations it entails:
https://github.com/geppo12/GitCombineRepo

So... if I understand correctly, there will be no real practical way to
merge my two repositories, in order to get an interweaving history? (not
criticizing, I only want to know where I am heading now!)

Greetings,

Andreas THILLOSEN.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-09-10  0:20 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-09 21:26 Git: Having trouble merging two repositories by interweaving their histories THILLOSEN Andreas
2013-09-09 23:06 ` Andreas Schwab
2013-09-10  0:19   ` THILLOSEN Andreas

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.