in the git source tree, look at ./contrib/workdir/git-new-workdir
On Tue, Sep 22, 2009 at 3:20 AM, John W. Long <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
