Re: Cloning empty repositories, was Re: What is the idea for bare repositories?

From: Bill Lear <rael@zopyra.com>
Date: Nov 14, 2007, 23:38 UTC
Message-ID: <18235.34578.886521.944550@lisa.zopyra.com>
In-Reply-To: <Pine.LNX.4.64.0711142047170.4362@racer.site>

On Wednesday, November 14, 2007 at 20:58:29 (+0000) Johannes Schindelin writes:

Show 15 quoted lines

>...
>I have a better idea:
>
>[the initial import, on another machine:]
>% mkdir new_repo
>% cd new_repo
>% git init
>[add content]
>% git commit -a -m "Initial stuff"
>% git remote add origin git://host/repo
>% git push origin master
>
>If you do not want to be bothered with setting up the default 
>"remote" and "merge" config variables manually, it is reasonable to ask 
>for support to do that in "git remote".

Um, ok, but the above means that this repo now differs from other repos, in that pushing now involves more than 'git push', i.e., 'git push origin master'. Is there not a way to configure it "as if" I had done a 'git clone' and thereafter could just do 'git push'?

I want to do: 1) point to origin; 2) push; and not have to remember "oh yeah, this is that 'special' repo and I have to tack on 'origin master' or it won't work", or to clone it somewhere else and work there.

>If you really think that this workflow has anything to do with cloning an 
>empty repository, I cannot help you.  I mean, you did not need to clone 
>the big, empty void to do the initial commit, or did you?

I just want to point to it and treat it as if it had been cloned to begin with: it is my future "point of origin". If it is not cloning, then it is "pointing to it as my origin", as if it were created by the clone.

What's wrong with 'git init --mirror git://host/repo'? Is it just another special case that's busy work helping only a few, or does it belong elsewhere in your opinion?

>(I actually think that it is another example of cvs/svn damage, where you 
>_need_ to clone first, or otherwise you will _never_ be able to commit 
>to the repository.)

I think there is a tendency here to blame every shortcoming of git on someone else's supposedly unsanitary past rather than facing up to inherent problems in git itself. We have several very senior, very dedicated software developers who LOVE git, and who loathe CVS, but who nevertheless find many vexing issues in git.

>BTW I am somewhat disgusted by your usage of git:// for pushing.

Whatever. We went through this before on the list and push support was added to git://. We have SUCKY sysadmin support at our company and permissions were getting HOSED using ssh pushes. The git:// protocol makes everything clean on the repo side and no nasty surprises with permissions and no delays begging the support team to clean things up.

Bill