On Tue, 26 May 2015 23:43:43 +0530
Kalpa Welivitigoda <callka...@gmail.com> wrote:
[...]
> >> Following is the output of $ git log --all --graph --decorate
> >> --oneline
> >>
> >> * 9c97cd4 (HEAD, master) Merge tag 'tags/Bdir12'
> >> |\
> >> | * af56821 (tag: Bdir12) updating dir1-2
> >> | * d0b8f8a adding dir1-2
> >> * 2f4b0ae adding dir1
> >> * 854521c adding dir1/dir1-3
> >> * 6f54cfb adding dir1/dir1-1
> >> * 2ff6f17 adding dir2
> >> * 0710523 init commit
[...]
> Extremely sorry for the confusion made. Let me explain,
>
> In repoB,
>
> $ git log --oneline dir1-2/
> 43b1361 updating dir1-2
> e68c343 adding dir1-2
>
> In repoA,
> $ git log --oneline dir1/dir1-2/
> 9c97cd4 Merge tag 'tags/Bdir12'
>
> My question is, shouldn't both of them return the same outcome (it is
> ok not to have the same hash, but the commits in repoB should be there
> in repoA, aren't they?) ?
Ah, I think I understand now, thanks.
The reason for this, apparently, is that tree objects referenced
by commits af56821 and d0b8f8a do not actually "hang off" dir1 prefix
as `git subtree split` did not know about it (and apparently there's no
way to artifically make it think it's there).
To spell it in other words, the first (and only) commit in repoB which
has "dir1-2" under "dir1" is the merge commit 9c97cd4.
The commits in the chain produced by `git subtree split` do not even
know about "dir1-2" (you can verify this by running
`git ls-tree --name-only -r af56821`) as they refer to tree object
that merely contain *the contents* of "dir1-2".
Well, I'm not sure what to do now...
Do running
$ git log --follow dir1/dir1-2
work for you -- descending into the history to the right side of the
merge commit 9c97cd4? If yes, I'd stop here.
If not, I'm afraid, some sort of `git filter-branch` mumbo-jumbo will
be required on the chain produced by `git subtree split`: the idea is
to rewrite each commit on that artifical branch with sort of the same
commit but with all its files moved under the "dir1/dir1-2" directory
so that both names actually exist in the produced tree objects attached
to the commits in the rewritten branch. Basically something along these
lines (untested):
$ cd repoA
$ git branch Bdir12 $(git subtree split dir1-2)
$ git filter-branch --tree-filter 'mkdir -p ./dir1/dir1-2 &&
find . -mindepth 1 -path ./dir -prune -o -print |
xargs mv -t ./dir/dir1-2' Bdir12
$ cd repoB
$ git fetch ..\repoA Bdir12
... and continue as before
The script passed to `git filter-branch --tree-filter` is run once
for each commit in the history of the branch being rewritten and will
operate on the work tree of that commit checked out. The script
creates the target directory hierarchy, then finds, recursively, all the
files and directories in the work tree, except the newly created
directory, and then moves them under that directory.
The new commit produced by filter-branch will have all the files under
dir1/dir1-2.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
