On Sep 21, 2009, at 5:19 PM, Tekkub wrote: > It sounds good in theory, but you're working against git's design. > Clone is going to grab all branches, unless you do a shallow clone, > in which case you don't get the history. Removing branches does not > remove the objects from git, in fact git is very stubborn about > removing objects. They will eventually be cleaned up by GC, but if > you're after saving space, you're going to be fighting with git a > lot. If you're that concerned with space, I would keep the > deployable code in one repo, and all the "supporting docs" in > another. That would be the simplest route, in my opinion.
I think I'm going to use: project-name-assets and project-name-application Which cuts it down to two repos as you suggest. > If you're working with binaries that don't need to be versioned, but > do need to be shared, you might want to use the downloads tab of the > project to upload the files. Keeping binaries out of the versioning > system if they don't need to be versioned is usually a good thing. In this case, it's quite handy. The downloads tab doesn't encourage push-button backup. And there are times when the binaries change, so it's nice to have git inform you of that. -- John Long http://wiseheartdesign.com http://recursivecreative.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
