[Kde-scm-interest] Git roadmap

[Johannes Sixt]

Paolo Capriotti schrieb:
> On Tuesday 18 September 2007 13:09:06 Johannes Sixt wrote:
>>>> I think there's a third possibility: actual copies with history across
>>>> modules.
>>> more input, please.
>> filter-branch --subdirectory followed by git merge -s subtree.
>> See my other posts.
> 
> I did some tests, and this doesn't seem to work well, at least afaict. I'm no 
> git expert, so please excuse me if I'm missing something obvious.
> There are two problems:
> 1) When I do a git-merge -s subtree of a branch, git tries to guess how to 
> shift the branch tree to fit in the current head, but inevitably fails if 
> this is the first merge, i.e. the directory is not yet in the target 
> repository. Since we just want to do the move (we don't need to merge further 
> from the source branch) this means that the subtree strategy is not the right 
> tool to use. Instead, following the git-gui merge thread on the git mailing 
> list, I've found a neat trick to do such a move.
> Suppose you want to move kapp from kdereview (where it is a submodule) to 
> kdebase. You can do, inside the kdebase repository:
> git remote add kapp /path/to/kapp/repo
> git fetch kapp
> git read-tree --prefix=kapp/ kapp/master
> git checkout kapp
> git rev-parse kapp/master > .git/MERGE_HEAD
> git commit
> If I understand it correctly, this should be more or less a manual merge where 
> we overwrite kapp's content into the current head (no problem, because we're 
> doing it on an empty dir). However, this way we can specify the target 
> directory.

You are right; thanks for correcting me. merge-subtree works only after this 
was already done once.

> 2) git-rev-list doesn't seem to follow changes to files in the merged subtree. 
> If I do a "git rev-list HEAD -- kapp/main.cpp" I only get the subtree merge 
> commit. What's the reason for this?

The reason is that in the commits that you have grafted in this way main.cpp 
  appeared at the top level, not below kapp. Hence, git rev-list does not 
find them. You have created this history with two independent roots:

o--o--o--o--M--o--o  <- kdebase, main.cpp is in kapp/
            /
x--x--x--X           <- inherited history, main.cpp is at top-level

You should see this also if you look at the diff from X to M (eg. in gitk): 
All files in kapp should be listed as renamed like main.cpp -> kapp/main.cpp

You could paint over this glitch by using git-filter-branch on the inherited 
history in such a way that the directory kapp/ is inserted at the top of 
each path. (I think there's even a recipe in the documentation of 
git-filter-branch how to do this most efficiently.)

-- Hannes