Use git sparse checkout instead of a sperate branch for config

[bricewge]

Is it possible to use git sparse checkout instead of a separate branch for the config?
I don't see the point to have duplicated information in a wheel repo, the config folder. Furthermore keeping it in sync can be tedious and lead to inconsistency between dynamic and static images.

[clemtibs]

The reason for this redundancy is that the user is free to use one method or the other depending on which suites their work-flow best. They are both baked into my wheel repositories here mainly for demonstration, and also because I have to put them all somewhere initially. At least that's how it has occurred to me to use these images. Usually as I'm hacking, I like to do all static builds of my hub just because I'm already right there in vim and can build it easily using fig. But once I get a configuration set together and tweaked just right, I'll commit it to a "config" branch in a git repository made just for my configuration (not my entire wheel like how they are displayed here on github) and grab it that way. Eventually, I like to use dynamic builds for everything and grab the config during build time. Even if though, one would prefer to use the static method of building a hub, the small size of the busybox image makes it very easy to push/pull the image around a network.

So the short answer is that if you only use one method, then you won't have to worry about the other and the possible inconsistency between the two and the extra maintenance.

...if you DO however use both, then my answer is mostly centered around that fact that I have never really used git sparse checkout and it didn't occur to me to use when I was putting it all together. After reading into it some more, I think some reasons against it would be:

1. Sparse checkout downloads entire repo, then just selects the files to display which could introduce a lot of bloat in the hub if wheel repositories contain source code, media, or other artifacts that are not related to configuration. Even if we delete it all, it still slows down the cloning and startup process which is very fast right now since all it's handling is text files.
2. By the same token, it seems very comforting to me to segment my configuration from my wheel via a fresh and clean branch. Just feels cleaner/leaner/safer/easier to fork and modify configs etc.
3. Additional complication of the setup/entrypoint scripts would be needed to get sparse checkout working. Not a big deal of course, but might be limiting.

The upside is what you mentioned, but like I said at the top, nothing in the hub design is forcing you to use both. Let me know if that gives you something to work with.