Jashan Chittesh Posted October 4, 2022 Report Share Posted October 4, 2022 I have read Git sparse checkouts and partial clones, nodata: the secret sauce of lighter clones, Xlinks: Reusable components and Xlinks Guide ... but I'm afraid none of these have answered my question in a satisfying manner. What we're trying to solve: We have a Unity project repository (centralized, so no replicas or anything distributed and we'd prefer to keep it that way) and want to add a folder for the art team. For the art team, this needs to be one workspace / repository with everything because we don't want to make things complicated for them by requiring two different workspaces or even worse, two different repositories. Some other team members may want to opt in to the art-folder but by default, they don't want to get those updates. So this very much sounds like what Git sparse checkouts and partial clones wants to offer (and it is in fact trivial to set up with Git sparse checkouts) - except we don't care about changesets at all for this use case. We only want to say "include this folder for me" or "ignore this folder for me" (basically, a workspace setting that locally ignores folders and pretends that they don't exist in the repository). So Xlinks kind of looked like it may solve the issue, even if in a more complicated way than we'd like: We could make a UnityAndArt repository, Xlink into the Unity repository from there and also have the art folder in there. Most people would just use the Unity repository, art would use UnityAndArt. My concern is that Xlinks seem to be designed to link to a specific changeset in a different repository (which makes sense for the use case it was designed for) but our workflow needs to be "Get latest for everything" or "switch to that other branch of everything" or "switch to that specific changeset for everything" (again, we don't want to have art to jump through additional hoops). In other words, we can't have separate changeset histories and from what I've seen, this doesn't seem to be possible with Xlinks because it's different repositories (because it's actually designed for a different use case). Even worse: It looks like every time art would want to change the version of the Unity project, they'd have to change the Xlink, which is too cumbersome to work. In Git sparse checkouts and partial clones, there's one interesting paragraph: Quote There's one great thing about Git partial clones that we don't have yet, though; they can hydrate a given path inside the repo, while we operate on a changeset basis. This is definitely something we have to add because it is very useful. Instead of hydrating from the root path, you can do it just from a sub path. While from what I understand, using this (if it is already implemented) would require switching over to a distributed model, it could solve the actual use case we have in a comparatively straightforward manner. That posting is more than 2 years old, so maybe we're lucky? Or is there another way to solve this in an easy-to-use way? Link to comment Share on other sites More sharing options...
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!Register a new account
Already have an account? Sign in here.Sign In Now