Re: Merging changes from branches where file paths have changed

[Johannes Sixt <j6t@kdbg.org>]

Am 14.04.2012 21:36, schrieb Thomas Adam:
> Hello,
> 
> On 14 April 2012 20:21, Johannes Sixt <j6t@kdbg.org> wrote:
>> You have these histories
>>
>>
>>  A--o--B--C--o--o--D--o--E   <- RepoA
>>
>>  A'----B'-C'                 <- RepoB
>>
>> and you want to cherry-pick D and E to RepoB. Right?
> 
> Yes, that's about right.
> 
>> I suggest that you install a graft in RepoB, then cherry-pick D and E:
>>
>>  echo $(git rev-parse C' C) >> .git/info/grafts
> 
> Can you elaborate on this a little more please?  Or point me towards
> some documentation.  Note that due to the way git-filter-branch works,
> although the history between RepoA and RepoB are common, the commit
> IDs between the two are completely different; presumably
> git-filter-branch uses patch-id at some level to reform commits.
> Nevertheless, if I'm understanding superficially what this graft is
> supposed to do, I do not see how getting a list of commits from C' to
> C is going to help in repoB when neither RepoA or RepoB have any
> ancestry in common?

There is no "list of commits from C' to C". Look carefully: it's
rev-parse, not rev-list. The command above only states that the (only)
parent of C' is C, i.e., it fakes this history:

  A--o--B--C--o--o--D--o--E   <- RepoA
            \
             C'               <- RepoB

and then the two repositories have history in common.

And BTW:

1. C' must be the top-most commit that was derived from RepoA.

2. If D or E add new paths, they will not be moved to the root by the
cherry-pick. Be sure to check the result.

3. If you have additional commits in RepoB that were not derived from
RepoA, it may not work out as smoothly, if the changes are so large that
rename detection does not kick in anymore.

-- Hannes