AaronKOG

I've been gitsyncing with the https+username+password or some time. Due to https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ I need to change this pretty soon to ssh. I see that SSH support was added late last year, but it isn't clear how to switch to using it. I'm on plastic version 9.0.16.4421. I have my ssh setup properly to clone from my git repository (I have always used ssh protocol via cmd.exe for my github repos). When I attempt to switch to the ssh url in the UI I hit this: Should I do as the prompt says and delete the mapping manually? Maybe I need to update the client/server? Don't want to do the wrong thing when it comes to anything gitsync 😉 Thanks, Aaron

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

Okay so my impression of how the email mapping worked was incorrect then. I thought that it would convert the author of matching email to the plastic username. So by having that mapping I expected that when I got a author with the email aaron@xxxx.co its username would be changed to aaronm when the changelist pulls into plastic (converted from "Aaron Mxxxx"). Was mainly trying to use the mapping to lower the license usage. That's fine. The described intended effects sounds good to me. So I need to deactivate the git user by running: cm deactivateuser "Aaron Mxxxx" Correct? Is it also good to assume that it won't get reactivated as I pull new CLs from git? Thanks, Aaron

Also, not sure if it is related, but for the last month or so when I make a commit on Plastic and sync to plastic on git I get aaron@xxxx.co as the email for the commit: Prior to that the email was left out: Wonder if the mapping is the cause or maybe a plastic update? Would like to also sort that out so that I can not have both aaronm+noemail and aaronm+aaron@xxx.co in the history. Thanks, Aaron

How do I know that the gitsync.conf is in effect and debug it if I've made a mistake in placement/format etc? Also curious about getting full details of options and placement of the file. I have my email mapped in the file like so [email-mapping] aaronm = aaron@xxxxxxxx.co I put the file in "C:\Users\username\AppData\Local\plastic4" and "C:\Program Files\PlasticSCM5\client". But when I sync (this is a fresh sync of a remote git repository, previously I tried adding a gitsync.conf then rerunning gitsync for an existing repo and it didn't seem to do anything either) the changesets author isn't aaronm like I would expect: This is the info of the commit from git: "Aaron M" also seems to be taking up a license for some reason which I'm trying to resolve by mapping. Any help with fixing this would be appreciated. Thanks, Aaron

Yes it is clear how it happened. I ran gitsync form another machine like the the person from the thread referenced. I stopped doing that after this occured. I attempted to remove the sub-branch merge towards the end of those parallel branches in the pictures. Here is a zoomed in shot at the point where I went back to using the original machine to sync: Any changeset I attempt to delete presents the error dialog in the original post. The arrows represent the duplicate changesets generated from running gitsync on an alt computer. The red circle indicates the changeset I'd think I would need to delete first to allow the others to get cleaned up. I suppose another alternative would be to remove the duplicate changes in the git history and sync from another fresh plastic repo... Would prefer to just fix this plastic repo up though if possible. If you want logs I am happy to email or send them some other private way. Thanks again, Aaron

Hello again, I saw this recent thread: I actually made the same mistake a year ago or so with my repo. My work around at the time was to just merge all the duplicate changesets and get back to work: Reading that thread gave me a little hope that I could actually go back and correct this by deleting the changelists (something I hadn't considered at the time). So I gave it a shot and... I tried the command line: Is there no cleaning this up since I actually went ahead and merged the subbranches that syncing from two machines created? I tried deleting the last duplicated, first duplicate and the sub branch merge changesets with the same results. What do you advise? Thanks, Aaron

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

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

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

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)

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