Git Sync Failed with 000000000000000 Reference

[AaronKOG]

This sync seems to be failing on a specific revision. It isn't clear to me why this would happen. I've attached an image of the fail dialog. I also have logs for the current running instance of Plastic and the Previous run of plastic where the git sync succeeded. I'm happy to send them directly to someone for support via email or some other private manner. Please let me know if you need anything else to sort this out.

Thanks,

Aaron

 

[AaronKOG]

A notable excerpt From the plastic.relevant.log.txt :

2020-01-15 07:51:44,844 MAIN-DEV\<username_redacted> INFO  sync - Changes to pull (Id:a42a7dc7be2de36a74c66b50beb4c59a4077078e Comment:'Merge branch 'master-dev' of https://github.com/<repo_path_redacted> into master-dev
'):
2020-01-15 07:51:44,931 MAIN-DEV\<username_redacted> INFO  Git - The commit 'd3a70b82e750ec7f64af586c51971cb07772755a' was already imported.
2020-01-15 07:51:44,931 MAIN-DEV\<username_redacted> INFO  Git - Going to pull commit 'b338b36bedf074f6c33ca16444ae8eeb2db4204b' (1/33)
2020-01-15 07:51:56,305 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 11266 ms
2020-01-15 07:51:56,307 MAIN-DEV\<username_redacted> WARN  filters - PathValueMatcher: Error parsing line:       # Fichero de extensiones de Plastic SCM. Sintaxis: <expresión>:<tipo>.
2020-01-15 07:51:56,307 MAIN-DEV\<username_redacted> WARN  filters - PathValueMatcher: Error parsing line:       # El tipo puede ser 'txt' o 'bin'.
2020-01-15 07:51:56,307 MAIN-DEV\<username_redacted> WARN  filters - PathValueMatcher: Error parsing line:       # Ejemplos:
2020-01-15 07:51:56,308 MAIN-DEV\<username_redacted> WARN  filters - PathValueMatcher: Error parsing line:     
2020-01-15 07:51:56,409 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 0 ms
2020-01-15 07:51:56,501 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 0 ms
2020-01-15 07:51:56,588 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 0 ms
2020-01-15 07:51:56,689 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 0 ms
2020-01-15 07:51:56,776 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 0 ms
2020-01-15 07:51:56,870 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 0 ms
2020-01-15 07:51:56,875 MAIN-DEV\<username_redacted> INFO  sync - The reference 2474c0429d9ed5822c34cb504357da791bcfbb76 couldn't be translated
2020-01-15 07:51:56,964 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 0 ms
2020-01-15 07:51:57,052 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 0 ms
2020-01-15 07:51:57,147 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 0 ms
2020-01-15 07:51:57,235 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 0 ms
2020-01-15 07:51:57,333 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 0 ms
2020-01-15 07:51:57,949 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 516 ms
2020-01-15 07:51:58,133 MAIN-DEV\<username_redacted> INFO  sync - The reference 8c5eaaa9833c5319c063f97690e9b59baf081c17 couldn't be translated
2020-01-15 07:51:59,873 MAIN-DEV\<username_redacted> INFO  Serialization - Time deserializing TreeNode package 1656 ms
2020-01-15 07:52:00,140 MAIN-DEV\<username_redacted> INFO  sync - The reference 8c5eaaa9833c5319c063f97690e9b59baf081c17 couldn't be translated
2020-01-15 07:52:00,154 MAIN-DEV\<username_redacted> INFO  sync - The reference 0000000000000000000000000000000000000000 couldn't be translated
2020-01-15 07:52:00,155 MAIN-DEV\<username_redacted> INFO  sync - GetForeignChangesets: 21095ms (6) 
PullCommits: 230391ms (104) 
ApplyChanges: 42138ms (104) 
CheckInChanges: 18956ms (208) 
UploadData: 121390ms (104) 
GetTrees: 102376ms (110) 
GetForeignTrees: 2157ms (110) 
UpdateTree: 0ms (104) 
MapRevisions: 0ms (104) 
MapChangeset: 0ms (104) 

2020-01-15 07:52:00,421 MAIN-DEV\<username_redacted> ERROR sync - Error running sync: The revision for the git reference 0000000000000000000000000000000000000000 cannot be found. StackTrace:
   at cy.b(TreeForeignNode A_0, RevisionInfo A_1)
   at qn.a(TreeForeignNode A_0, TreeNode A_1, Boolean A_2, TreeChangedNode A_3)
   at qn.a(b A_0, ml A_1, Queue`1 A_2)
   at qn.a(b A_0, Queue`1 A_1)
   at qn.a(TreeForeignNode A_0, TreeNode A_1, a A_2)
   at qn.a(TreeForeignNode A_0, TreeNode A_1, IList`1 A_2, cp A_3)
   at qn.a(TreeForeignNode A_0, TreeNode A_1, IList`1 A_2, cp A_3, cs A_4, t3 A_5, uy A_6, r1 A_7, ti A_8, ms A_9)
   at dl.a(TreeNode A_0, TreeForeignNode A_1, IList`1 A_2, us A_3, ry A_4)
   at dl.a(GitCommit A_0, b A_1)
   at dl.a(List`1 A_0, b A_1)
   at ki.a(List`1 A_0)
   at og.b(adk A_0, Boolean A_1)
   at og.a(lq A_0, RepositoryInfo A_1)
   at og.a(Object A_0)

 

[calbzam]

Hi,

Are you using a public repo we can try? If you try to sync the same  git repo against a clean repo, is the issue reproducible?

This error normally happens when the Plastic repo involved in the sync with git is not empty.

Regards,

Carlos.

[AaronKOG]

It is not a public repo. I've been syncing this plastic<->git paired repo for some time, only the most recent sync has this issue. I will test with a clean repo soon.  I'm guessing that should run clean, but that won't solve this for me.  Ideally this is something I can address, but if it is not solvable I'd still like to know the cause (perhaps someone on my team used rebase or merge in the way plastic can't handle or something) so that it doesn't happen again after nuking from orbit.  Is it possible git push/pull/commit could run default behavior (based of system settings) that could break things? I only do branch merging on the plastic side to avoid the fast forward merge scenario, but I am wondering if perhaps FF happened automatically some other way.  I have logs I can email you.

Thanks,

Aaron

[AaronKOG]

Fresh sync from my git repo was successful, but again still interested in figuring out what went wrong with my original sync so this doesn't happen again.

Thanks,

Aaron

[calbzam]

Have you removed or renamed branches?

Or somehow rewritten the repo history? delete changeset, rebase, merge-fast-forward...?

https://www.plasticscm.com/documentation/gitsync/plastic-scm-version-control-gitsync-guide#GitSyncrestrictions

Regards,

Carlos.

[AaronKOG]

That is my concern. I'm unsure on how to confirm whether that happened or not (I'd like to send you logs so that you can possibly confirm this). I've read the restrictions, but I'd love it if I could get specifics on what git settings to ensure are in place.

For example since this error occurred I realized that the default "git pull" will do a merge fast-forward if possible by default. Will that be a problem when merging local<->remote on the same branch? Is fast-forward merging only a problem when merging between branches or do I need to make sure everyone has their default pull action do a "git merge --no-ff" instead of "git merge"? If so you should probably mention that in the gitsync documentation as my situation may be common for those with a laymen's understanding of git and rarely messes with settings.

Thanks again for you time,

Aaron

[AaronKOG]

So I started a fresh gitsync to an empty repo to work around this issue. I also had everyone (total of 3 devs) update their default pull behavior to merge with "--no-ff" (the only potential offender to the listed caveats to using gitsync. History has not been touched. Things seemed fine for a month or so. Now I'm presented the same error in the original post above. Something is wrong here. Our workflow details are as follows:

• We have a main branch and a dev branch
• We only ever push commits to the dev branch when using git
• I periodically gitsync and merge dev->main in the plastic client
• I make commits to main branch from the plastic client (only one plastic user touches the repo)

That is it. I'd like to keep this workflow. I believe my client (I'm a contractor for the owner of the plastic licenses) started an email thread with support that I'll be getting recent logs too (proprietary info I don't want to share on the forum).

Another notable fact is that I run plastic while connected to my client's VPN which occasionally has connection issues to the plastic server (which are worked around by vpn disconnect+connect cycle). Perhaps this bad commit hash is potentially generation if I have a connection loss while gitsyncing? That is the only theory my gut has given everything I know.

Any help with this issue is greatly appreciated,

Aaron

[calbzam]

Quote

That is it. I'd like to keep this workflow. I believe my client (I'm a contractor for the owner of the plastic licenses) started an email thread with support that I'll be getting recent logs too (proprietary info I don't want to share on the forum).

You can share the logs via support ticket. I'm not aware of this support thread by your client. Could you open a new one or CC me just in case (calba@codicesoftware.com)?

As I commented, I've seen this error in the past when the repo history is somehow rewritten. Plastic creates the git mappings (shas) for a specific repo structure and it shouldn't be rewritten. I guess your git developers are already aware of this limitation, right?

The connection issues shouldn't be relevant for this error. But it would be great to check the last logs and eventually some access to your serve to try to reproduce the issue.

Regards,

Carlos.

[emil]

Hi @calbzam, I'm the repo owner for the issue above. I just updated our support ticket thread with the latest set of logs. Please let me know what else I can provide. Thank you!

 

-emil