Make a non-bare repo bare.

Make a non-bare repo bare.

[Tim Visher]

Hello Everyone,

I recently had occasion to make a previously non-bare repo bare.  Is
there any way to do this?  It will not allow me to delete a branch
that I'm on so I wasn't sure how to proceed.

Thanks!

-- 

In Christ,

Timmy V.

http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail

Re: Make a non-bare repo bare.

[Paolo Bonzini]

On 07/15/2009 11:43 PM, Tim Visher wrote:
> Hello Everyone,
>
> I recently had occasion to make a previously non-bare repo bare.  Is
> there any way to do this?  It will not allow me to delete a branch
> that I'm on so I wasn't sure how to proceed.

Just do "mv repo/.git repo.git; rm -rf repo" (with care!).

Paolo

Re: Make a non-bare repo bare.

[Tim Visher]

On Wed, Jul 15, 2009 at 5:48 PM, Paolo Bonzini<bonzini@gnu.org> wrote:
> On 07/15/2009 11:43 PM, Tim Visher wrote:
>> I recently had occasion to make a previously non-bare repo bare.  Is
>> there any way to do this?  It will not allow me to delete a branch
>> that I'm on so I wasn't sure how to proceed.
>
> Just do "mv repo/.git repo.git; rm -rf repo" (with care!).

Thanks, Paolo.

-- 

In Christ,

Timmy V.

http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail

Re: Make a non-bare repo bare.

[Jeff King]

On Wed, Jul 15, 2009 at 11:48:42PM +0200, Paolo Bonzini wrote:

> On 07/15/2009 11:43 PM, Tim Visher wrote:
> >I recently had occasion to make a previously non-bare repo bare.  Is
> >there any way to do this?  It will not allow me to delete a branch
> >that I'm on so I wasn't sure how to proceed.
> 
> Just do "mv repo/.git repo.git; rm -rf repo" (with care!).

That used to work, but these days there is a "core.bare" config variable
so that git doesn't have to guess whether you are in a bare repo. So you
should also do:

  $ git config core.bare true

in the resulting repo (or just before, since your "mv" is obviously not
a git command that would care).

-Peff

Re: Make a non-bare repo bare.

[Junio C Hamano]

Tim Visher <tim.visher@gmail.com> writes:

> Hello Everyone,
>
> I recently had occasion to make a previously non-bare repo bare.  Is
> there any way to do this?  It will not allow me to delete a branch
> that I'm on so I wasn't sure how to proceed.

Funny.

    http://article.gmane.org/gmane.comp.version-control.git/123303

It is posed as a question but describes the correct (and officially
supported) procedure.

Re: Make a non-bare repo bare.

[Graeme Geldenhuys]

Junio C Hamano wrote:
> 
> Funny.
> 
>     http://article.gmane.org/gmane.comp.version-control.git/123303
> 
> It is posed as a question but describes the correct (and officially
> supported) procedure.


Now it deserves to be in some Git FAQ. It seems the issue is more common 
than I thought. :-)


Regards,
   - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/

Re: Make a non-bare repo bare.

[Mike Ralphson]

2009/7/16 Graeme Geldenhuys <graemeg@gmail.com>:
> Junio C Hamano wrote:
>>
>> Funny.
>>
>>    http://article.gmane.org/gmane.comp.version-control.git/123303
>>
>> It is posed as a question but describes the correct (and officially
>> supported) procedure.
>
>
> Now it deserves to be in some Git FAQ. It seems the issue is more common
> than I thought. :-)

It already is

http://git.or.cz/gitwiki/GitFaq#HowdoImakeexistingnon-barerepositorybare.3F

unless that's new?

Re: Make a non-bare repo bare.

[Sitaram Chamarty]

On Thu, Jul 16, 2009 at 8:03 AM, Junio C Hamano<gitster@pobox.com> wrote:
> Tim Visher <tim.visher@gmail.com> writes:
>
>> Hello Everyone,
>>
>> I recently had occasion to make a previously non-bare repo bare.  Is
>> there any way to do this?  It will not allow me to delete a branch
>> that I'm on so I wasn't sure how to proceed.
>
> Funny.
>
>    http://article.gmane.org/gmane.comp.version-control.git/123303
>
> It is posed as a question but describes the correct (and officially
> supported) procedure.

The linked procedure uses git clone --bare.  It is my belief (and
please correct me if I'm wrong) that only a git clone --mirror
actually does what you want here -- a mere "bare" clone would lose
your remotes and their tracking branches would it not?

If I'm wrong please correct me...

Re: Make a non-bare repo bare.

[Tim Visher]

On Thu, Jul 16, 2009 at 8:03 AM, Junio C Hamano<gitster@pobox.com> wrote:
> Tim Visher <tim.visher@gmail.com> writes:
>
>> Hello Everyone,
>>
>> I recently had occasion to make a previously non-bare repo bare.  Is
>> there any way to do this?  It will not allow me to delete a branch
>> that I'm on so I wasn't sure how to proceed.
>
> Funny.
>
>    http://article.gmane.org/gmane.comp.version-control.git/123303
>
> It is posed as a question but describes the correct (and officially
> supported) procedure.

Thanks.  That's what I was looking for.  I wish I didn't have to
actually clone the repo anew but if that's how it is, oh well. :)

That wiki response seems to contradict what Junio said

On Thu, Jul 16, 2009 at 7:39 AM, Sitaram Chamarty<sitaramc@gmail.com> wrote:
> The linked procedure uses git clone --bare.  It is my belief (and
> please correct me if I'm wrong) that only a git clone --mirror
> actually does what you want here -- a mere "bare" clone would lose
> your remotes and their tracking branches would it not?
>
> If I'm wrong please correct me...

The linked wiki article seems to contradict what Junio said.  I guess
I'd go with Junio being somewhat authoritative on normative
prodecudures in the git world. /me shrugs.

-- 

In Christ,

Timmy V.

http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail

Re: Make a non-bare repo bare.

[Junio C Hamano]

Mike Ralphson <mike.ralphson@gmail.com> writes:

> 2009/7/16 Graeme Geldenhuys <graemeg@gmail.com>:
>> Junio C Hamano wrote:
>>>
>>> Funny.
>>>
>>>    http://article.gmane.org/gmane.comp.version-control.git/123303
>>>
>>> It is posed as a question but describes the correct (and officially
>>> supported) procedure.
>>
>>
>> Now it deserves to be in some Git FAQ. It seems the issue is more common
>> than I thought. :-)
>
> It already is
>
> http://git.or.cz/gitwiki/GitFaq#HowdoImakeexistingnon-barerepositorybare.3F
>
> unless that's new?

Somebody needs to promise to keep that entry up-to-date, or we should
rewrite it so that we do not expose such an implementation detail.

Even today core.bare is not the only difference between a repository with
a work tree and a bare one.  We also set core.logallrefupdates these days
for a repository with a work tree, so the procedure described there is
already stale.  And this kind of implementation details are bound to
change.

Asking git what to do is the only reliable "cut-and-paste-ready" recipe.

Re: Make a non-bare repo bare.

[Junio C Hamano]

Sitaram Chamarty <sitaramc@gmail.com> writes:

> On Thu, Jul 16, 2009 at 8:03 AM, Junio C Hamano<gitster@pobox.com> wrote:
>> Tim Visher <tim.visher@gmail.com> writes:
>>
>>> Hello Everyone,
>>>
>>> I recently had occasion to make a previously non-bare repo bare.  Is
>>> there any way to do this?  It will not allow me to delete a branch
>>> that I'm on so I wasn't sure how to proceed.
>>
>> Funny.
>>
>>    http://article.gmane.org/gmane.comp.version-control.git/123303
>>
>> It is posed as a question but describes the correct (and officially
>> supported) procedure.
>
> The linked procedure uses git clone --bare.  It is my belief (and
> please correct me if I'm wrong) that only a git clone --mirror
> actually does what you want here -- a mere "bare" clone would lose
> your remotes and their tracking branches would it not?

Depends on "what you want here".

I assumed that the request was to set up the most typical use of a bare
repository, that is to prepare a distribution point, separate from your
primary working repository with a work tree, from which you push your
updates into this new bare repository.

And in such a distribution point, you do not need nor want remotes.  The
point of remote tracking branches is to let you peek what others are doing
and merge with them, and that is done while you advance your history in
your primary working area with the work tree.  It does not happen in your
distribution point.

Re: Make a non-bare repo bare.

[Sitaram Chamarty]

On Fri, Jul 17, 2009 at 2:21 AM, Junio C Hamano<gitster@pobox.com> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:

>> The linked procedure uses git clone --bare.  It is my belief (and
>> please correct me if I'm wrong) that only a git clone --mirror
>> actually does what you want here -- a mere "bare" clone would lose
>> your remotes and their tracking branches would it not?
>
> Depends on "what you want here".
>
> I assumed that the request was to set up the most typical use of a bare
> repository, that is to prepare a distribution point, separate from your
> primary working repository with a work tree, from which you push your
> updates into this new bare repository.
>
> And in such a distribution point, you do not need nor want remotes.  The
> point of remote tracking branches is to let you peek what others are doing
> and merge with them, and that is done while you advance your history in
> your primary working area with the work tree.  It does not happen in your
> distribution point.

I agree, bares dont have remotes, normally.

I was speaking purely from a technical point of view.  Contrast, if
you will, with the other method seen in the thread and elsewhere (the
mv repo/.git repo.git, rm -rf repo, git config core.bare in repo.git
stuff), which does preserve all this.

Anyway, you confirmed my _understanding_ of clone bare versus clone
mirror, which is what I was looking for.  Thanks!

Sitaram

Re: Make a non-bare repo bare.

[Sitaram Chamarty]

On Fri, Jul 17, 2009 at 2:17 AM, Junio C Hamano<gitster@pobox.com> wrote:
> Mike Ralphson <mike.ralphson@gmail.com> writes:

>> http://git.or.cz/gitwiki/GitFaq#HowdoImakeexistingnon-barerepositorybare.3F

> Somebody needs to promise to keep that entry up-to-date, or we should
> rewrite it so that we do not expose such an implementation detail.
>
> Even today core.bare is not the only difference between a repository with
> a work tree and a bare one.  We also set core.logallrefupdates these days
> for a repository with a work tree, so the procedure described there is
> already stale.  And this kind of implementation details are bound to
> change.

I wonder why core.logAllRefUpdates is not the default for bare repos.
I have taken to making that the _global_ default on any git/gitosis
server I install, so all my bare repos have it turned on.

My reason is that I do want to allow "push -f" (it _is_ sometimes
needed), but I also want to protect against such push happening in
error, and the reflog has always seemed like a good safety net to run
to when that happens.

Other than space (due to garbage collection delay until reflog expire)
what are the downsides?  Could someone enlighten me if I'm doing
something stupid here?

Thanks,

Sitaram