Xlinks: Disable branch auto expansion

[Acren]

Hi there. We've started trying out xlinks to manage our component repos, and it seems to work well apart from one thing:

The branches on the parent repo getting created on the child repo is really undesirable from our point of view, because these branches only make sense in the context of the parent repo and mean nothing to the child, they are also all just empty merges and don't contain anything meaningful.

So we also get all of these automatically created empty branches cluttering the child repo and creating triggers and notifications where we don't want them to, and I can only see this getting much worse when there are more xlinks as well.

Can we disable the auto expansion and keep the xlink writable? The desired behavior would be to always use the /main branch on the child and not create other branches.
Essentially this would be the same thing as having an expansion rule for every branch on the parent repo mapped to /main on the child repo, but I'm not sure how to specify this, maybe I'm missing something because I'm still new to xlinks.

Thanks!

[Acren]

To clarify: The main issue is that when a branch on the parent repo is merged, it appears to also create a new branch and empty merge on the xlinked repo, even though the contents of the xlinked repo was not changed at all.
This creates a lot of confusion and clutter.

After some more research I've discovered this thread, which seems to be the exact problem we're facing.
But the last post was ~2.5 years ago.

Has there been any development to address this? Or any workarounds discovered?

Thanks.

[Wolfram]

We have encountered this problem in the past, whenever we have "long term branches" that keep merging to and fro from /main and/or other branches.

Our (only) solution was to end these branches, merge them back as necessary, and then start new branches from /main (or whichever parent you need to). These branches will then be fine and no longer create empty changesets in the Xlink source repo, UNLESS you start merging or modifying Xlink assets in these branches/in the connected Xlink "client" repos, at which point the whole thing would start happening once again.

So try to find a workflow that keeps the number of long-term branches to a minimum, i.e., keep your branches short (e.g., task-/ticket based etc.).

[Kike]

On November I opened an issue with the Plastic team regarding this. I provided a couple of reproduction paths, and explained the problems they caused (for our team, in particular). The problems are empty changesets in the xlinked repo, and updated xlink changeset ids when merging unrelated changes into main turning things into a spiraling chaos of empty merges and incremented changeset values.

I was told the issue has been communicated to the development team, I was asked for some more info, and things should be moving along. I don't know what the final solution will be, or whether there will be one at all, but I'll try to remember posting here any updates I get.

For completeness sake, I'll say that this matching of changesets between xlink and the parent repo was considered a feature, as the Plastic team thought keeping a clear history matching both repos to be important. However, that's because they see xlinks as a way to develop sub-features of a complete system.

For me, however, xlinks are a way to maintain common libraries between different projects, and for that use case, matching the histories of different projects 1-to-1 in the library repository makes no sense. The library history is unreadable, as it gets cluttered over time with meaningless empty changesets [edit: or changesets and branches that are irrelevant for the library history].

Edited January 19, 2023 by Kike

[Acren]

@Wolfram Thanks for the information but it seems like this happens for us even when using mostly short task branches, although we can't get rid of long running branches completely because they are required for our workflows.

@KikeYeah, I'd definitely agree with your idea of desired functionality there. For us, the outer repo should know about the inner repo that it contains, and not the other way around. The inner repo logically doesn't need to care about the outer repo's changesets, branches, merges, or any other kind of history. That's sort of the whole idea of component libraries in the first place.

I'm not sure I see how the current behavior can be considered intentional at all though. If it were just creating branches and merges for actual changes to the inner repo that were submitted via the outer repo, at least I could sort of understand how that might be intentional even if it's not ideal. But, the current behavior of pushing all of the outer repo's branches and merges into the inner repo I don't think would make sense in any scenario. Of course we can only really speculate...

Take a look at our inner repo's branch explorer:

There are now 45 branches and 156 changesets on the inner repo that were automatically created by the outer one.

How many actual changes are there to the code on the inner repo? Just a single one.

Thanks a lot for pushing this with the Plastic team, hopefully they can fix or improve this.