clone --bare vs push

clone --bare vs push

[Levend Sayar]

Hi, all.

We cloned a repo from github on our local server. Say X for this. At
that repo, we did

git clone --bare X y.git

Now y.git is ready for other machines to clone.

To update our upstream repo X, we do

git pull

and then

git push --all

to update y.git.

Now questions:

1) When I compare X/.git directory and y.git directory there are many
objects missing in y.git. What is the reason ?

2) git clone --bare is too fast. My .git directory is nearly 1GB. How
can it be copied that much fast ?

3) Is this more safe then git pull, git push

rm -rf y.git
git pull
git clone --bare X y.git

Namely bare cloning each time when we update our main repo ?

TIA

_lvnd_
 (^_^)

Re: clone --bare vs push

[Ævar Arnfjörð Bjarmason]

On Mon, Jan 3, 2011 at 19:24, Levend Sayar <levendsayar@gmail.com> wrote:

> 1) When I compare X/.git directory and y.git directory there are many
> objects missing in y.git. What is the reason ?

Maybe things were repacked.

> 2) git clone --bare is too fast. My .git directory is nearly 1GB. How
> can it be copied that much fast ?

It will use hardlinks when using the same filesystem. See
--no-hardlinks in git-clone(1).

Re: clone --bare vs push

[Neal Kreitzinger]

"Levend Sayar" <levendsayar@gmail.com> wrote in message 
news:AANLkTi=RNDYrRbyEJXA_c30JEVr=SYUQ01cfA3FyWpLT@mail.gmail.com...
> Hi, all.
>
> We cloned a repo from github on our local server. Say X for this. At
> that repo, we did
>
> git clone --bare X y.git
>
> Now y.git is ready for other machines to clone.
>
> To update our upstream repo X, we do
>
> git pull
>
> and then
>
> git push --all
>
> to update y.git.
>
> Now questions:
>
> 1) When I compare X/.git directory and y.git directory there are many
> objects missing in y.git. What is the reason ?
>
> 2) git clone --bare is too fast. My .git directory is nearly 1GB. How
> can it be copied that much fast ?
>
> 3) Is this more safe then git pull, git push
>
> rm -rf y.git
> git pull
> git clone --bare X y.git
>
> Namely bare cloning each time when we update our main repo ?
>
> TIA
>
> _lvnd_
> (^_^)

you can also use the file:// url format to create a complete copy and not 
use hardlinks.  see git-clone manpage.

e.g. git clone --bare file:///fullpathto/X y.git

v/r,
Neal 

Re: clone --bare vs push

[Jonathan Nieder]

Neal Kreitzinger wrote:

> you can also use the file:// url format to create a complete copy and not 
> use hardlinks.  see git-clone manpage.
> 
> e.g. git clone --bare file:///fullpathto/X y.git

Thanks, that's useful; cc-ing Levend.

[Side note: I wrote in the past:

| In traditional newsgroups it seems to be most common to just reply to
| the author by mail or follow-up to the group, so I wouldn't feel too
| bad.

but probably that was unclear of me.  The convention on _this_ list[1] is
to reply to all participants in a thread, so new participants do not
need to subscribe if they don't want to.  Thunderbird (e.g.) seems to
be good at doing that for what it's worth.]

[1] at least as I perceive it; please feel free to correct me if I
have misunderstood

Re: clone --bare vs push

[Neal Kreitzinger]

On 1/3/2011 10:58 PM, Jonathan Nieder wrote:
> Neal Kreitzinger wrote:
>
>> you can also use the file:// url format to create a complete copy and not
>> use hardlinks.  see git-clone manpage.
>>
>> e.g. git clone --bare file:///fullpathto/X y.git
>
> Thanks, that's useful; cc-ing Levend.
>
> [Side note: I wrote in the past:
>
> | In traditional newsgroups it seems to be most common to just reply to
> | the author by mail or follow-up to the group, so I wouldn't feel too
> | bad.
>
> but probably that was unclear of me.  The convention on _this_ list[1] is
> to reply to all participants in a thread, so new participants do not
> need to subscribe if they don't want to.  Thunderbird (e.g.) seems to
> be good at doing that for what it's worth.]
>
> [1] at least as I perceive it; please feel free to correct me if I
> have misunderstood

This is a "reply all" from thunderbird.  This looks like it is doing the 
cc correctly...

v/r,
Neal