Hi, git folks!
I think i've found something about inconsistency between "git subtree split"
and "git svn fetch".
First of all, "git subtree split" ignores commits with 0 changed files, when
the "git svn fetch" is not.
For example, it could be an svn commit where only properties has changed, but
no file changes.
Second, seems "git subtree split" and "git svn fetch" produces different commit
hashes for the same commits.
Experiment:
For instance, we have SVN repo: repoA with project in subdirectory, say repoA/B.
If try to make "git svn clone repoA A.git" and "git svn clone repoA/B B.git",
then you will get totally different commit's hash list:
>cd A.git
>git log --pretty=oneline master
<GUID_A1> (HEAD -> master, git-svn) A1
<GUID_B1x> B1
<GUID_A2> A2
<GUID_B2x> B2
...
<GUID_AN> AN
<GUID_BNx> BN
>cd ../B.git
>git log --pretty=oneline master
<GUID_B1> (HEAD -> master, git-svn) B1
<GUID_B2> B2
...
<GUID_BN> BN
,where <GUID_Bk> not equal to the same commit <GUID_Bkx>, where k=1..N.
I beleave git does create a commit hash using eigher distance to the root, or
previous commit hash in a commit chain.
Anyway, whatever it does this all leads to unavailability to synchronize such
working copies which has been made through the "git svn clone repoA"+"git
subtree split --prefix=B"+"git clone repoB.git"
with the SVN repository referenced by next call to the "git svn init repoA/B".
In another words, say we already have a git repository made from "git subtree
split" - repoB.git.
Now, this set of commands looks resonable:
>git clone repoB.git B.git
Cloning into 'B.git'...
remote: Counting objects: 931, done.
remote: Compressing objects: 100% (395/395), done.
remote: Total 931 (delta 517), reused 931 (delta 517), pack-reused 0
Receiving objects: 100% (931/931), 10.15 MiB | 475.00 KiB/s, done.
Resolving deltas: 100% (517/517), done.
>cd B.git
>git log --pretty=online --grep=git-svn-id: master
<GUID_B1> (HEAD -> master, git-svn) B1
<GUID_B2> B2
...
<GUID_BN> BN
>git svn init repoA/B
>git update-ref refs/remotes/git-svn <GUID_B1>
(This one is important here, otherwise the next "git svn fetch" will retake
whole svn repository from 0, which is might be too long if there is hundreds of
revisions.)
(take a notice, the problem goes from here, see details below)
>git svn fetch
Rebuilding .git/svn/refs/remotes/git-svn/.rev_map.<A_GUID> ...
r4 = <GUID_BN>
r6 = <GUID_BN-1>
r12 = <GUID_BN-2>
...
rM-1 = <GUID_B2>
rM = <GUID_B1>
Done rebuilding .git/svn/refs/remotes/git-svn/.rev_map.<A_GUID>
<some taken files here>
rNEW = <GUID_NEW> (refs/remotes/git-svn)
>git svn rebase
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/git-svn.
>git push origin master
Counting objects: 3, done.
Delta compression using up to 6 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 375 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To repoB.git
<GUID_B1>..<GUID_NEW> master -> master
And it seems is all ok, but for one exception. The repoB.git is not the subtree
splitted repository.
This is repository directly cloned from the SVN repoA/B just before rNEW commit
has made into the SVN repository which is made in turn after the clone.
The real output is this:
>git svn fetch
Rebuilding .git/svn/refs/remotes/git-svn/.rev_map.<A_GUID> ...
Done rebuilding .git/svn/refs/remotes/git-svn/.rev_map.<A_GUID>
Rebuilding .git/svn/refs/remotes/git-svn/.rev_map.<A_GUID> ...
Done rebuilding .git/svn/refs/remotes/git-svn/.rev_map.<A_GUID>
Rebuilding .git/svn/refs/remotes/git-svn/.rev_map.<A_GUID> ...
Done rebuilding .git/svn/refs/remotes/git-svn/.rev_map.<A_GUID>
Index mismatch: <GUID_X> != <GUID_Y>
rereading <GUID_Z>
<some taken files here>
W: -empty_dir: blabla1
W: -empty_dir: blabla2
...
W: -empty_dir: blablaL
Last fetched revision of refs/remotes/git-svn was r92, but we are about to
fetch: r4!
I googled the whole internet inside out, but there is just no any solution for
it.
It's broken and nothing about it.
The only solution i see here is just throw "git subtree split" as a hindering
garbage for the sake of git-svn synchronization.
