git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Andry <andry@inbox.ru>
To: git@vger.kernel.org
Subject: issue: "git subtree split" vs "git svn fetch" consequences
Date: Sun, 4 Jun 2017 02:36:31 +0300	[thread overview]
Message-ID: <1187166615.20170604023631@inbox.ru> (raw)

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.


                 reply	other threads:[~2017-06-03 23:41 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1187166615.20170604023631@inbox.ru \
    --to=andry@inbox.ru \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).