On Nov 15, 2007 8:28 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > 1. move submodule subB outside > > mv subB /newpath/to/subB > > git-commit subB > > Strictly speaking, you do not have to move it outside. Hmm, you're right. I can just just remove it after fetch subB as a branch of superA. > > > 2. git-filter-branch to rename all files in subA repository to subB > > directory (say subB/subB). > > > > cd newpath/to/subB && > > git filter-branch --index-filter \ > > 'git ls-files -s | sed "s-\t-&subB/-" | > > GIT_INDEX_FILE=$GIT_INDEX_FILE.new \ > > git update-index --index-info && > > mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD > > No need to play games with GIT_INDEX_FILE, as far as I can tell. I just follow the example of git-filter-branch manual page. If not using GIT_INDEX_FILE.new, the GIT_INDEX_FILE will be read and wirtten at the same time since it is read and writtern at the same in a pipe. Will this be ok? > > > 3. in directory of super project superA, git-fetch repository subB to > > branch subB > > cd path/to/superA && git-fetch /newpath/to/subB master:subB > > If you plan to do away with subB, you do not need to specify it... Just > use FETCH_HEAD, directly after the fetch. Hmm, using FETCH_HEAD is really better. > The git-cherry call is not really necessary, right? The two repos have no > common history (not even common patches). > > Besides, I think that what you did is just a complicated way of doing a > rebase. I tried rebase, wonderful! > > Ciao, > Dscho > > -- Ping Yin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
