On Sep 21, 10:11 pm, Sitaram Chamarty wrote:
>> 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 b
in the git source tree, look at ./contrib/workdir/git-new-workdir
On Tue, Sep 22, 2009 at 3:20 AM, John W. Long 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 sha
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
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
e
On Sep 21, 2009, at 4:40 PM, Tekkub wrote:
> Yes, you'll need to clone again for each subdirectory with that
> setup. There are ways to get git to share the space though, check
> out git-clone's docs:
> http://www.kernel.org/pub/software/scm/git-core/docs/git-clone.html
>
> Basically you wou
Yes, you'll need to clone again for each subdirectory with that setup.
There are ways to get git to share the space though, check out git-clone's
docs: http://www.kernel.org/pub/software/scm/git-core/docs/git-clone.html
Basically you would clone the main repo once from GitHub, then clone from
your
