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

Junio C Hamano [off-list ref] writes:

But both of Johannes's points apply equally well to an empty
bare repository and to an empty non bare repository.  IOW,
bareness does not matter to the suggestion Johannes gave.

He was suggesting to create the initial commit before cloning:

quoted

So you need to populate the repository before starting _anyway_.

To create an initial commit in a non-bare repository, I put files in
it, git add, and git commit.

To create an initial commit in a bare repository, the most natural way
for me is to clone it, create the commit in the clone, and then push.

Bare-ness _does_ matter for that.

I repeat the use-case I mentionned above :

,----
| a typical use-case is when I want to create a new project. I'd
| like to initialize an empty bare repo on my backed up disk, and then
| clone it to my local-fast-unreliable disk to get a working copy and do
| the first commit there.
`----

I find this quite natural, and up to now, no one gave me either a
rationale not to do that, or a _simple_ way to achieve this. As I
said, it's currently not _very_ hard to do, but I have to edit
.git/config by hand, while git clone knows how to do this much faster
than I for non-empty repositories.

-- 
Matthieu

Matthieu Moy [off-list ref] wrote:

I repeat the use-case I mentionned above :

,----
| a typical use-case is when I want to create a new project. I'd
| like to initialize an empty bare repo on my backed up disk, and then
| clone it to my local-fast-unreliable disk to get a working copy and do
| the first commit there.
`----

I find this quite natural, and up to now, no one gave me either a
rationale not to do that, or a _simple_ way to achieve this. As I
said, it's currently not _very_ hard to do, but I have to edit
.git/config by hand, while git clone knows how to do this much faster
than I for non-empty repositories.

Its a goal to redefine git-clone as the following, as that is
really all it does:

	mkdir foo && cd foo && git init &&
	git remote add -f origin $url &&
	git checkout -b master origin/master

So setting up an empty tree is basically that:

	mkdir foo && cd foo && git init &&
	git remote add origin $url

Is that really so difficult?  git-clone is a handy crutch for when
we didn't have things like git-remote.  Or remote tracking branches.
IMHO the above may seem a little low level but it may make it easier
to teach to newbies.  They are more likely to grasp the concept of
their repository being just like someone else's, and that they can
track other repositories beyond just their origin.

-- 
Shawn.

Matthieu Moy wrote:

I repeat the use-case I mentionned above :

,----
| a typical use-case is when I want to create a new project. I'd
| like to initialize an empty bare repo on my backed up disk, and then
| clone it to my local-fast-unreliable disk to get a working copy and do
| the first commit there.
`----

I find this quite natural, and up to now, no one gave me either a
rationale not to do that,

The rationale is that current git just simply cannot do this.
You are welcome to add support for this corner case in git-clone,
or add git protocol extension for symref transfer.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Hi,

On Tue, 13 Nov 2007, Matthieu Moy wrote:

Junio C Hamano [off-list ref] writes:

quoted

But both of Johannes's points apply equally well to an empty bare 
repository and to an empty non bare repository.  IOW, bareness does 
not matter to the suggestion Johannes gave.

He was suggesting to create the initial commit before cloning:

quoted

quoted

So you need to populate the repository before starting _anyway_.

Of course I was suggesting to push into the still empty, bare repository, 
before anybody is cloning.

Ciao,
Dscho

On Tue, 13 Nov 2007, Shawn O. Pearce wrote:

Matthieu Moy [off-list ref] wrote:

quoted

I repeat the use-case I mentionned above :

,----
| a typical use-case is when I want to create a new project. I'd
| like to initialize an empty bare repo on my backed up disk, and then
| clone it to my local-fast-unreliable disk to get a working copy and do
| the first commit there.
`----

I find this quite natural, and up to now, no one gave me either a
rationale not to do that, or a _simple_ way to achieve this. As I
said, it's currently not _very_ hard to do, but I have to edit
.git/config by hand, while git clone knows how to do this much faster
than I for non-empty repositories.

Its a goal to redefine git-clone as the following, as that is
really all it does:

	mkdir foo && cd foo && git init &&
	git remote add -f origin $url &&
	git checkout -b master origin/master

So setting up an empty tree is basically that:

	mkdir foo && cd foo && git init &&
	git remote add origin $url

Is that really so difficult?  git-clone is a handy crutch for when
we didn't have things like git-remote.  Or remote tracking branches.
IMHO the above may seem a little low level but it may make it easier
to teach to newbies.  They are more likely to grasp the concept of
their repository being just like someone else's, and that they can
track other repositories beyond just their origin.

FWIW all my Git tutorials for $work so far always avoided 'git clone'. 
The 'git init' + 'git remote add' + 'git fetch' is what I ask people to 
do.  It is more obvious to give a good name for the remote repo that 
way, and this can be performed into either a new or an existing repo 
when the data is related.


Nicolas