Question Git Sync Error: Branches have more than one head

Hello,

I am currently having issues with several branches when syncing our main branch from Git to Plastic. This is similar to this thread on the old forum. However, although there is reference to a solution, it does not actually detail how to resolve it in the thread.

I've attached a screenshot of what one of the branches looks like in branch explorer, and I can see the two heads, but from the git side these are old branches that have since been merged in elsewhere. How do I rectify this so I can resume syncing?

Thanks,

A

 

I am attempting to set up a sync between plastic and git so that we can trial having artists/animators and similar use gluon and modify the content folder, then sync back to git on a regular basis. This has not started yet, so all I am trying to do is pull from git and keep the plastic repo up to date in advance of that effort kicking off, but now I am blocked by these errors on a large list of branches.

Obviously our current git workflow is creating these multi-head branches from Plastic's perspective, though I am unsure why this has only cropped up now given I successfully synced the project several times previously (not since roughly March however). Have I misunderstood the intention of the git sync and this sort of hybrid approach is not possible? Is it a case of having to migrate fully to Plastic instead?

I've looked at a couple of the example erroring branches from the Plastic perspective, and as an example, one branch was forked, worked on, then that was used to create a new branch, but those changes were never merged back into the original branch. I don't think this is particularly unusual or unexpected, nor do I think this is something recent that has changed in behaviour - has Plastic altered the way the git sync operation works recently?

 

It seems the magic I am looking for is the

--dontcheckmultihead

option on the command line...

Trying it now

 

The error prone nature is disappointing, but good to know before we go too far trying to make it work. Our current workflow is entirely Github based, including our entire CI pipeline, and migrating it all to Plastic would require significant effort, and likely it would require a different CI, because CircleCI is tightly integrated with Git

Hence, our intent was to segregate the work somewhat artificially, have the content folder in Plastic where artists and creatives primarily operate. The could then use Gluon to achieve a workflow more suited to their needs. Engineers would work in Plastic if they need to make change to the content folder, but otherwise would continue as usual, and we would then create tooling/automation to sync back the changes from the content folder in Plastic to Git as needed (and hence trigger our CI process as before).

We could have the content folder work mentioned on a separate branch if needed, that would just alter how the automation/tooling would need to work, but if this is a bad idea as a general use case it would be good to know now before we expend a lot of effort attempting to make it work

 

> GitSync was conceived as a tool to import/export content for git without needing to use the "fast import/export" tool. You can sync back and forth several times, but when working on both ends, errors are likely to appear unless the work is done in different branches.

Depending on the implications here, we might be able to work around the issues. Could we (for example) have a set of branches where the work is done on the "Plastic side" - i.e. primarily changes to the content folder, binary assets etc. and then the rest of the branches being worked on in Git as usual?

It would still have to be a two way sync, we would need to have work merged from the Git branches into the Plastic branches so they are up to date and usable, and we would similarly have to merge the work done in plastic into various branches in Git. However, we could do all that syncing separately and only merge in Plastic or Git respectively for their designated branches.

> Furthermore, the sync must always be done from the same machine, as it needs to use the mappings created during the first sync or it will duplicate the whole repo.

I don't really understand what this means - we will have to have this be possible on multiple machines, though we could potentially have the major sync operations happen on a single machine and ask individuals not sync to/from git themselves, but that very much complicates things and is counter intuitive for something that is supposed to be a distributed version control system

 

Understood - we'll have to take a different approach and create our own tooling here I think, even if we used submodules and used something like you describe, we'd still have a need for co-ordination of commits/merges because of dependencies, and we want that to be automated, not reliant on a person or team.